The Case For Validators
Remember when we used to all have pretty W3C badges to prove to our users that we adhered to code standards? We proudly proclaimed “My site is valid HTML 4.01 Strict!” Our new badges of honor come from our GitHub pages with our newer “build passing” badges. It’s still proof of our efforts to follow good coding standards, it’s now only visible to those that would actually care: those looking at the code.
Great - we’ve moved our trophy case from the footers of all our pages to the more nerdy areas. But is this all that’s changed? We have tests that make sure you don’t have syntax errors, you’re not polluting the global namespace and all kinds of assertions specific to our applications. But I’ve found the use of any markup validators to be far less common now. We’re testing every bit of code except the ones that we tested exclusively in the past. Maybe we’re just so confident that we’ve got it right after all these years.
I doubt it.
Let’s use CSS!
I’m still very interested in good quality (X)HTML and have been working to make getting a quick smoke test for pages as painless as possible. Thankfully, we have an incredibly powerful tool that can be used to check for common errors. The portability of CSS3 and it’s great additions for selectors makes it an excellent tool for testing. With help from more people than I can list, I’ve gotten together a list of CSS selectors that check for things that are clearly out of spec, things that look a little fishy and a few things that might be ok - but you should double check that you’re using them right.
So What’s It Check?
Did you know you can have a class name with a “.” in it? It’s not valid, it’ll cause all kinds of issues, but it’ll work in most browsers. Did you know that if you left your image’s “src” attribute empty, some browsers will try and grab the page again, causing performance issues? Did you know that you can’t have a number as a leading character in a class or ID? DebugCSS will look for these coding errors, but also look for issues such as over zealous use of the <br> tag (and offer the suggestion that you should use a paragraph tag instead) - or politely ask if that <table> with a single <tr> is being used for layout.
Running CSS On The Server
So You Can Debug Using CSS…Show Me.
- You can download a copy of the CSS on GitHub
- If you want to run it quickly in your browser, you can install the bookmarklet
- And if you want to run it on the server, it is now part of Arrow (an open source node.js powered testing suite)
So Why Not Just Use Tidy Or OpenSP?
Please do! They are both great validators and the more testing done for valid markup, the happier I’ll be. They also will fill in areas that debugCSS will miss. However, debugCSS also points out things that aren’t necessarily “wrong”, but are bad form or have repercussions in regard to performance or accessibility. It just has the added convenience of being able to be run from a bookmarklet, works on mobile - and adds super helpful visual cues to the problems in-page.
How Can I Help?
Well, I’m glad you asked. DebugCSS and Arrow (the framework it’s built into for running on the server) are entirely open source. Fork away on GitHub and send me a pull request for any neat changes you make. If you’re interested in doing this kind of thing and getting paid for it, I should let you know that Yahoo! is hiring - just send an email to any of the friendly purveyors of this blog if interested.