The W3C designed the web and HTML standards to accomplish a noble goal: the semantic organization and cross-indexing of human knowledge. Large parts of the HTML standard are oriented towards this somewhat academic goal: tags such as <cite>, <acronym>, and <address> have been around a long time, and yet 99% of web designers never use them. Why not? Because 99% of web sites don't give a damn about the W3C's ivory-tower objectives. They have a completely different objective, and the W3C objectives are actually an impediment to them. Fortunately (for them), HTML is flexible and tolerant enough that it is easily subverted to their own purposes.

The objective of most web sites and designers is to deliver digital media and services as cheaply and efficiently as possible. They don't care about (or even understand) the concept of the semantic web, and even if they did, they don't have the time, inclination, or sophistication to restructure their marketing materials to give them an appropriate semantic structure. (And if they did, the marketing department would undoubtedly complain about the unattractive consequences of it.) The perceived benefit to most website owners is near zero. And yet a substantial portion of their web designers have nevertheless bought into the line that strict adherence to W3C standards is somehow a Very Important Thing.

But why is it important? To give a specific example, why should we use HTML 4.01 Strict, instead of 4.01 Transitional? From a purely functional standpoint, Transitional is more tolerant, provides better support for legacy browsers. and for most pages offers no perceptible performance penalty. In any other field it would be considered a superior choice for the vast majority of cases, so why is it perceived as inferior by web geeks?

If you want to take the argument to the extreme case, why is XHTML considered superior to quirks mode? Why would anyone rationally choose a mark-up standard that is highly intolerant of errors, and requires extra pedantry in its mark-up, over one that is simple enough to be encoded by one's mother in Notepad, and which is supported to some extent by every browser ever made? Especially if their output is indistinguishable?

Web geeks have lots of answers to this. Unfortunately, most of them boil down to this: stricter standards make more sense to computer geeks. XHTML is awesome because it follows rules. Quirks mode sucks because it's full of ambiguity. (Similarly, 4.01 Strict has better rules than 4.01 Transitional, which tolerates older, sloppier rules.) But the computer geeks are wrong on this score for two reasons that most of them will refuse to acknowledge.

Firstly, tolerance of ambiguity is a Good Thing. It is a vital aspect of any system that attempts to be truly expressive. Computer geeks like to think that you can be as expressive as you want, as long as you follow the rules. (And since they understand the rules, you can always come to them if you need help, for a mere $75 per hour.) But in fact, expressiveness often requires breaking the rules. The early web used tables for doing layout because the early rules did not take advanced layout into consideration. The W3C conceived tables as a way of presenting structured data, not as a way for presenting entire documents. It is still necessary to use tables today to accomplish some layout tricks that modern HTML standards still don't support well. If we were required to follow the W3C's recommendations strictly, the web as we know it would have been stillborn. It would have remained stuck in its original role, as a cheap way to distribute academic papers and reports.

Secondly, the computer geek's respect for rules is not shared by the rest of the world. Overly strict rules are evidence of overly stupid computer programs that lack the intelligence to make reasonable decisions. But the web has evolved to the point where browsers are actually pretty clever. They can encounter all kinds of messed-up code, and still present useful information. So if our browsers have gotten so smart, why do we need to change our web documents to make them more computer-friendly? For most website owners, it stinks of gatekeeping, of a scam to make things more complicated so that expensive salaries and consulting fees are justifiable. If the web site looks okay and everything works, why do you need to spend thousands of dollars to convert everything over to a slightly different flavour of HTML?

Now, I happen to be a web geek, so I already know that there are good reasons why you might want to do this. But I also know that there are also good reasons why not. The mere fact that the latest flavours of HTML are "better" in some geeky way than the previous flavours is not a good reason to change. It's not even a good reason to choose the new flavour for future projects. Geeks tend to like new stuff as a matter of principle, so they might chafe at this suggestion. But unless the new flavour provides a specific feature or function that you really need, don't bother.

X Files

XHTML sounds cool and cutting edge, probably because 'X' is a hip marketing letter. In this case the X stands for XML, and in that acronym it stands for "extensible". So really it should be an E. But EHTML sounds kind of wishy-washy, doesn't it? We probably wouldn't be so eager to convert to EHTML. But XHTML sounds better. X-treme. X-ray vision. X-rated. We want it.

But XHTML is actually pretty lame. For reasons that have nothing to do with web productivity, and everything to do with inheriting arbitrary lexical rules from difficult markup systems like SGML, XHTML will not accept all kinds of perfectly legal HTML markup. So it's basically crippled compared to its predecessors. Seriously crippled, if ease of content manipulation is one of your requirements (and surely that's a major requirement for most web publishers). Furthermore, most XHTML documents are served up as HTML, not as XML, so so you aren't even getting the the purported benefits of that X. Why the heck would anyone choose such a markup standard?

Well, there's one good reason. XML allows you to unambiguously define your DOM (document object model). That's a pretty important feature, in some applications. Repeat: in *some* applications. Is your application one of those? (Hint: if you're not sure, then it isn't.) If not, then by choosing XHTML you have gained a feature you will never use, at the expense of features that are important and useful for maintaining regular websites. If very precise DOM parsing or manipulation is mission-critical for you, then XHTML is the ticket. Otherwise, it may very well be an albatross.

And there's the rub. Web standards exist to make *some* things easier. It's important to know what those things are before you jump on one bandwagon or another. In other words, what are the web standards trying to accomplish, and is it the same as what you are trying to accomplish? Do you even know what the web standards are trying to do? Bearing in mind that the W3C's vision of the web does not match the vision of the vast majority of website owners, odds are that the web standards are only tangentially related to your own objectives.

Alternatives

An illustrative example of how the W3C's vision of the web diverges from the reality can be found in its treatment of images. The modern web is rich with graphics, but from the perspective of the web's big thinkers, this is a problem. Images are really hard for computers to understand, and this creates a pretty big chink in the armour of the semantic web. As more of the web's content is represented by images, the web becomes increasingly opaque and difficult to comprehend, except by direct application of eyeballs to screens. It's more than just an academic problem, because some web surfers are visually impaired and even the eyeballs-to-screens method of understanding images does not work. And yet images are undeniably important, even in the original academic conception of the web, where they were used for graphs and figures.

It is such a serious problem that it was dealt with some time back by the simple expedient of requiring web designers to tag their images with an ALT attribute, giving a brief text description of the image. This is a simple and effective solution. The W3C validator will find all of your images that are not appropriately described, and flag them with a big error message that says you must provide an ALT tag. Unthinking web designers obediently add descriptions of their images, the errors go away, and everybody is happy that their pages are now "certified" good quality by the W3C validator, allowing you to add their badge of approval to the page.

Except they're not good quality. The vast majority of images on a modern web page are cosmetic, and serve no semantic purpose. They are fluff, meant to instill good feelings in the viewer, or provide a bit of visual assistance in delineating parts of the page. Some are not even visible, being spacer graphics or struts that push stuff around for a more pleasing layout. In the W3C conception, images are (or ought to be) real content. In the real world's conception, most images are lipstick for the pig. When these two world views collide, you get web pages with dozens of spacer images all marked up with "spacer image" ALT attributes, and various cosmetic feel-good images with little semantic value marked up with informative alt tags like "image" or "photo". You also get senseless repetition, as cosmetic images carry ALT tags that simply repeat something that is already stated in regular text. This is not what the W3C was hoping for. This is not the intent of the standard. But it's exactly what blind adherence to standards has produced.

Considering how images are actually used in the real world, they should not be required to carry an ALT attribute. The W3C's assumption is that images are content, when in fact they often merely style. CSS allows you to push a lot of this stuff out to your stylesheet, but in practice this does not eliminate the problem, only keeps it down to a dull roar. Once you understand the W3C's intent, you can work around their faulty assumptions in the real world by setting ALT="" for cosmetic images. This effectively expresses that the semantic value of the image is nothing. But this is a silly thing to require, since it should obviously be the default, and it just adds a bunch of unnecessary data to the page, and unnecessary work for the developer.

Web purists might now be thinking, "Put your cosmetic images in CSS, where they belong." For example, say you want to pop a big splashy stock photo in the heart of your page, but you know in your heart that it has zero semantic value. If the image is more style than substance, perhaps it does belong in CSS. So we create an empty DIV in the heart of our page, and then we modify our stylesheet to give this DIV appropriate dimensions, and a background image (which is our stock photo, of course), and this appears to get the job done. Viewers of the page see the stock photo in all its glory, but in the document markup, it is nowhere to be found. As far as the W3C is concerned, the photo is semantically irrelevant, which is precisely the case.

But this supposed solution is in many ways worse than a regular image with blank ALT text. For starters, it's a hack, no matter how pure it seems to CSS fans. You are using an attribute explicitly intended for backgrounds to render an element that for all intents and purposes is a foreground image. It's also a content management nightmare. Instead of simply placing an image tag where the image goes, you have to place a much less intuitive DIV tag and give it a unique ID. Then you have to edit your stylesheet (which is written in an entirely different language) to specify the exact dimensions of this DIV, and also specify the URL to the image. This will be well beyond the capabilities of many casual web authors whose understanding of HTML and CSS does not go beyond the WYSIWYG HTML editor that they interact with.

Using your Head

Another very common mistake by developers is using headings inappropriately. HTML provides a convenient set of 6 headings, H1 through H6, to help you mark up your documents. But most web authors use these quite inappropriately.

Because most style sheets scale the size of headings down as you increase the heading number, it is widely assumed that heading number it is just a convenient shorthand for visual prominence. But in fact, the heading number corresponds to the document subsection. An H1 begins a top-level section, an H2 begins a sub-section (section 1.1 of the document, for instance), and H3 begins a sub-sub-section (1.1.1), and so on. This means that heading numbers are actually a powerful semantic tool for defining the structure of large, complex documents.

That makes perfect sense when you understand what the W3C is all about. But once again, it's nearly useless when you see how the tags are actually used in the real world. Very few sites even conceive of their pages as having sections and subsections, much less use their heading tags to delineate these correctly. Few sites publish documents long and complex enough to make effective use of heading levels, and the majority of those that do, prefer to paginate the document so that it's broken into easy-reading chunks with more advertising opportunities. Needless to say, the pagination does not conform to W3C expectations about section structure.

Validation

Headings and images are good examples of how we're all using HTML incorrectly and contrary to the W3C's intent. And these are basic tags; it doesn't get much more fundamental than these. What hope is there that will we make proper use of the more interesting semantic tags, such as CITE, ACRONYM, ABBR, and DFN? Fortunately, the question is moot, because we don't really use those tags at all. They just go over most of our heads, which alone should convince us that we may not be using the web the way the W3C intended.

And yet, despite the fact that we're basically doing it all wrong, we still have a mad desire to get the W3C to validate our pages. The W3C even encourages us to do so, by offering cute little merit badges that we can place on our pages if they pass their validator.

Since the validator only checks syntax, not semantics, the big question that nobody ever seems to ask is: who cares if your syntax is correct if your semantics are incorrect? In other words, why are we obsessing about our spelling, when our sentences are gibberish?

The Purpose of Standards

Ask an average techie about the importance of web standards, and you will probably get an answer that talks about compatibility and interoperability. Standards allow you to maintain a working relationship with a range of vendors, operating systems, browsers, legacy software, future software not yet conceived, and with alternative devices for the disabled, without ever needing to test directly against those devices.

The trouble is, this answer is wrong. It is correct for most fields of software, which is why we think it is right. But we're talking about the web, and the web is different. The HTML specification is forwards- and backwards-compatible by design, and all the more so in quirks mode. Unknown tags and attributes are simply ignored, while their content is not. The compatibility is implicit; you don't gain it by declaring a hard spec to adhere to. If anything, forcing the use agent into a hard spec should reduce interoperability, since some agents won't support the spec.

The test of this is simple; invent a new tag that you imagine (wrongly) will be in a future HTML 6.x specification, and go ahead and insert it into all of your web pages in anticipation of this happy day. For example:

The "wow" tag makes everything inside it <wow>more exciting</wow>!

Not only do your pages not break, the content inside your imaginary tag still renders in a reasonable way. And there isn't even a detour into quirks mode. So the compatibility rationale is basically bogus.

There is a a slight theoretical compatibility benefit to declaring a specific standard, which is to announce your intention for how ambiguous or evolving elements should be understood in the context of your document. For example, say you have documents containing old HTML 3 markup like <FONT> tags, which you don't want to support anymore, but nor do you want to edit all of those files simply to remove the offending tags. It would be nice to just redeclare the documents as HTML 4.01 Strict, which does not support FONT tags. Since unsupported tags are ignored (as in our test above), the FONT elements should effectively disappear from our documents, right? Well, no. This doesn't actually work. Browsers will actually implement the FONT tag that does not exist in your declared specification, by borrowing silently from another specification that does support the tag. And they will claim to do this while remaining in "standards compliance mode".

So much for standards.

The Real Purpose of Standards

It's not that standards are poorly supported on the web (although arguably that is the case). The real issue here is that most of us don't understand what purpose the standards are really serving, which is machine readability. The architects of the web want machines to be able to comprehend what they are reading--not in the sense that you and I comprehend it, but in the sense that they could index and search it better, and do Wolfram Alpha-like information processing and distilling for us, rather than just show us a bunch of links with better-than-average chance of being relevant to the search terms we typed in.

Of course, since we content creators haven't actually written the web to allow for this, and show no real inclination to start despite our misdirected obsession with web standards, the machine readers really don't have much to work with. And that's why Google is still showing us a bunch of not-quite random links, and why the first attempt at a true knowledge engine, the aforementioned Wolfram Alpha, ended up not being a web search at all.

So should we care about our HTML standards as much as we think we should? Lets just imagine for the sake of argument that we have a web document that is semantically marked up to convey maximum meaning in exactly the way the W3C intends. And then we run it through the validator to ensure that the markup is syntactically perfect. What have we gained from this exercise, practically speaking?

Hard to say, really. We wouldn't really know until enough people did it and it started to become possible to build semantic search engines to make use of all that latent potential. But nobody really knows when that latent potential will attain critical mass, and until it does there is a large amount of effort to play along that has no immediate tangible benefit. And that's just considering the semantic tags already available to us in lil' old HTML. When you take a look at the other markup technologies that the semantic web gurus want to throw into the mix, it's positively monstrous.

Which means, if you work in the real world where people don't like to spend their money (in other words your time) without an immediate payoff, it's just not going to happen. The web will continue to be an organic, unpredictable medium that fails to do what it's engineers want it to. But fortunately, it will continue to surprises us by doing things we never expected it to.