Why XHTML?
15 October 2004
A recent discussion with one of my favorite friends and co-workers about building websites has made me decide to publish my repsonse here to a very specific question he asked me: why use XHTML when developing websites?
The case for XHTML has certainly been made many times before, by people more expert than I. Yet time and time again I'm asked, why use XHTML at all? The question is often posed by engineers rightly concerned about the extra bandwidth costs incurred by always quoting attributes and closing tags, as XHTML demands. Why not shave off extra characters from our code by using the looser syntax of earlier HTML versions?
The reason to use XHTML in fact is that its syntax requirements are much more explicit than those of earlier HTML versions, and that these requirements can be tested (and violations of them pinpointed) by a validator. Elements must be properly closed; element attribute values must be quoted; and so on. Why does this matter, particularly when it adds extra characters to a site's markup? Why should we do this, when if you scale up that extra data on a high traffic site, you're looking at a significant extra cost?
Here's why. Easily finding structural errors in our markup (not to mention keeping the markup small, simple, and structurally meaningful) makes it enormously more possible to rely on CSS for presentation. And that let's us strip out all those old-school tables and spacer gifs and font tags and <br> tags from our markup. The character savings we earn by doing that will far outweigh the character costs that result from quoting our element attributes and properly closing all our elements. True, our CSS will get a little bigger, but the benefit of putting our presentational code there is that we put it there once and re-use it across all our pages. The bandwidth cost savings can be dramatic: a recent analysis of Microsoft's homepage showed they could save 329 terabytes per year on homepage views alone by doing this.
But, you might ask, couldn't we do the same thing with HTML 4.01? Why exactly does XHTML's strict syntax make it more feasible to move our presentational code from our markup to our stylesheet? The answer is that once we start relying on CSS for more of our presentation, we'll need to take advantage of certain features and characteristics of CSS that require we have markup that's structurally sound. For example, we can use CSS to specify that our H2 elements should be rendered one way when they're contained within an element we've tagged with a class of "sidebar" and another way all other times. Considering the increasingly sophisticated effects we can achieve with CSS, this will allow us to produce some visually compelling site elements with minimal markup. And they'll be re-usable: after the first page load, all we have to do to render them again is send that tiny bit of markup -- the CSS is already cached.
But for this to work, our CSS has to be able to know an element's place in the structure of the document that contains it. If, for example, we fail to close that "sidebar" element I just mentioned, what happens to any H2 elements after it? Should they be rendered according to the "sidebar" rules or not? Well, are they contained within a "sidebar" element? Now that we've corrupted our document structure, it's hard to say. Is everything after we open that "sidebar" contained within it, since we never closed it? Or is nothing contained within it, since, lacking closure, it's not really a container at all anymore. Our site's presentation starts to crumble.
We could try to hack around the mess by relying less on these sorts of descendent selectors, but then we'd need to add more "hooks" to our markup in order to apply the right style rules. We could give each H2 a class or id in the markup and reference those in our CSS to specify how they should be rendered. But then our markup and stylesheet get bloated and complicated again. We've lost one of the important benefits that sent us down this path in the first place.
So, we need valid, well-formed pages in order to gain all the advantages of separating presentational code from our markup (and I've mentioned only some of the advantages). Yes, we could develop pages this way in earlier versions of HTML, but it is just so much easier and more efficient to code to a standard with explicit syntax requirements that can be validated. That way, we can know that our pages are structurally sound and valid while we're building them, and we can quickly identify mistakes and fix them before they're propagated across a sprawling site.
In short, it's a way to enforce the standards we need to rely on when developing sites with CSS -- and thereby gain all those advantages of "standards-based development" everyone keeps shouting about.