Sacrificing the validation goat to the browser gods

As a web developer, much of my working day is spent at the mercy of browsers. Sometimes it feels like I spend all my time coaxing useful work from bratty children who don’t like to get along. One of the important tools available for convincing the browsers to play nice is HTML and CSS validation. It is the way to check that the markup I’ve written is correct. It’s like compile time error checking for webpages.

But isn’t that the browser’s job?

Sort of, but the browser will try to render the webpage even if it’s not syntactically valid.

Torturing of web developers aside, modern browsers actually do a pretty amazing job of trying to guess what was meant by HTML that isn’t quite right. They can take a webpage that has pretty severe problems and have a good go at displaying it in a sensible way. For pages with small syntax errors you probably will not even know from looking at it in a browser.

This is a Good Thing. The last thing I want is some who looks at my page to see a compile error just because something went wrong in my CMS and I’m missing the quotes from an attribute on an image tag. Short of catastrophe (which is usually quite easy to spot) I would prefer a slightly malformed page with information that is still accessible than no information at all.

The problem is that there isn’t a standard for dealing with the millions of different ways that a document can be malformed so browsers often won’t handle the errors in exactly the same way. The results might or might not be exactly what you meant and they probably won’t be consistent.

By creating pages with valid HTML, the odds in the browser roulette game are increased in your favour. Think of it as sacrificing the sacrificial goat to the browser gods. If your webpages are syntactically valid, you will at least have the W3C standards on your side so you can feel righteous anger when your pages fail to render the way you’d expect.

(The goat is just a metaphor)

What needs to be validated?

  • HTML – the most important things to validate. It’s easy to make small mistakes in HTML markup that can be really hard to spot.
  • CSS – if you’re creating a new page layout or if you’re having problems with your CSS it’s a good idea to validate that as well. The same arguments for HTML validation apply to CSS as well.

When does validation matter?

Writing valid webpage is always important because it will make your life as a web developer more predictable.

Public websites vs intranet

You will see the benefit of this immediately if your site is a public website that is visited by people using every sort of browser. Websites with validation errors are much less likely to work well in the browsers you couldn’t test.

I’d still recommend checking for validation even if you are in an intranet environment where everyone has to use the same browser. Pages that validate are less likely to run into strange browser bugs that eat up your time than ones that don’t.

Content websites vs web applications

With content websites, using valid HTML will make it easier for unusual user agents like search engines or mobile phones to understand your site.

For web applications, the more complex the web application and the further you are pushing the browser, the more you need to play nice. It’s hard enough to find and debug weird edge case browser behaviours in pages without introducing the unpredictability of validation errors.

Posted on 27 Dec 07 by Helen Emerson (last updated on 27 Dec 07).
Filed under ASP.NET