When is a standard not a standard? When it’s XHTML.

What happens when an *actual* standard fails

You’ll hear a lot of chest-beating from some quarters about how they develop ‘standards-compliant’ HTML or CSS code. The really clever ones up the ante by saying that what they produce is XHTML, on the basis that HTML is a subset of XML and the HTML is structured that it will allow an XML parser to read it without error and that means you can stick an X in front of it or something. Of course, anything that brings sites into line with each other quality-wise and attempts to improve the experience of downloading porn is to be welcomed.

All well and good, but does that make it a proper technical standard? Not on your nelly.

What does a technical standard look like?
A true technical standard has to break anything that doesn’t comply.

We needn’t look to the world of three letter acronyms to provide an example. If you take your narrow gauge train onto a broad gauge track, it falls over and the passengers die. Narrow Gauge is therefore a technical standard – and if you want your train to ferry people safely between Points A and B then you’d better make sure you follow that standard. There’s a simple, clear definition of the standard available to all and it’s pretty much tough shit if you want to build a train that’s 40ft wide.

The equivalent test for HTML just doesn’t exist. Since almost the very inception of the internet, the tools that people have used to read the code have allowed for error. Because the nature of the web is/was based on self-publishing, developers of early browsers were extremely liberal about what they would accept. All those Geocities pages commemorating dead dogs were just packed with low-grade code, empty tags, redundant markup and a million other sins. The browser manufacturers had a simple choice to make:

1. Try to interpret this mess or 
2. Stop people from viewing poorly coded sites by showing an error message.

En masse, they chose option 1, and doomed the idea of effective web standards forever.

Because the early browsers made huge allowances for what they were prepared to accept the web was built on rickety foundations and has never recovered. Major sites were riddled with questionable markup – hell, even Google doesn’t validate to this day – and anyone bringing a new browser to market has to face up to the reality that if they strictly enforced ‘standards’ then anyone viewing Google would just get an error message. What would happen if they did? Well, my Auntie Barbara would just think “hmm – I know that my nephew Paul is up to date with all this internet stuff, but this thing he told me to download is rubbish. I can’t even look at Google.” And then she’d go back to using IE5.5 and we’d all be one step closer to the stone age.

So by necessity, no-one is ever going to actually release a browser that enforces standards in the way that standards should be enforced.

Enter the W3C…
The W3C and it’s supporters are trying desperately to create some kind of standard for website code to follow. While I think the horse has bolted, they’re still heroically trying to lock the stable door and get everybody writing code to a certain standard.

They’ve got 2 main problems. No-one has to listen to them and many of those that do can’t understand them.

Here’s the thing: HTML is pretty simple as far as ‘languages’ go. Shorn of functionality and concerned purely with visual presentation, there’s not a whole bunch it can do. A paragraph tag is, at the end of the day, a paragraph tag. That makes creating ‘valid’ code pretty trivial. Make sure your tags are properly nested and closed, and that you’re not using <blink> and hey presto! “Validity” is yours! Be sure to whack a smug little notice at the bottom of your page saying “XHTML compliant” to win Brownie points with the people who care about such things and go proselytise about it at SXSW.

That means the whole thing is treated with a little bit of disdain by programmers who are trying to do the database-driven stuff that makes websites work. To them, it’s kiddy-stuff not worthy of their attention. They have to get this fucking site integrated with the client’s 14th century in-house accountanting software by friday and they’ll be damned if they’re going to pay attention to a missing paragraph tag. So the problem perpetuates even in the most forward-thinking companies: it’s life, get used to it.

So where does the real complexity lie? There’s no denying that making a website work across all the browsers is an art all of its own. That skill lies in mastery of CSS which is where the W3C spends much of its efforts. Unfortunately, the documentation leaves plenty ’nuff room for interpretation. People got awfully sniffy about the way that IE6 used the box model to determine widths of block-level elements but reading a lot of the specifications is like deciphering the Voynich Manuscript and I’ve got shedloads of sympathy for anyone trying to write a browser that interprets every aspect of these specs properly. Even Microsoft.

Progress is also glacially slow. In the same time that PHP has gone from one man’s homegrown homepage generation code to a fully implemented object-orientated programming language, the W3C have managed to get to a working draft of CSS2. Nice work guys! In the meantime, the uses of the web have exploded and endless debates about whether there should be a ‘nav’ tag seem quaintly Socialist. With AJAX and a raft of existing attributes and tags that can be messed around with on the fly, discussions of semantics seem… well… semantic.

So what we have is a standard that has no legal force and plenty of religious argument about how it should be interpreted, a vast, sprawling, unmanaged network of documents that don’t conform to any kind of the standard anyway, and a load of software that *could* be used to enforce the standards but would never get used as they did.

Pick the bones out of that!