Last week a friend brought to my attention that the XHTML2 working group will close at the end of the year, with resources being switched to focus on HTML5.
About time, too – it was this post, back in April, by Dave Shea that got me thinking how XHTML had been a false dawn, one which web developers – myself included – adopted with too much eagerness and without any real justification for switching from HTML4.1.
I remember six years or so ago, when semantics were all the rage and elitist developers would look down their noses at people who had the gall to stick with HTML4.1 and its woolly allowance for unclosed tags. XHTML seemed like the perfect solution to the problem of sloppy code because you had to be strict about structure and tag nesting. The premise was good – if we all wrote perfect code then the browsers stood more chance of uniformly displaying the pages as intended. A sort of meet-them-in-the-middle approach to achieving the Utopian web standards we all dreamed of.
But then people started over-thinking the issue. Web standards evangelists started saying stuff like “navigation is a list of options, therefor all navigation should be contained within a list!” Which is all well and good, but then radio buttons are lists of options… which meant they should have lists wrapped around them, too, if you were really taking semantics literally. And a lot of people did that and more.
Suddenly there were reams of Web Standards best practices articles sitting, somewhat uncomfortably, alongside the articles telling you how to hack and glitch your way to certain presentation effects because the browsers weren’t actually ready for the things we were trying to do. The evangelists were telling us that, when the dawn of the new age came, those of us who had put the effort in could stand back with a sense of satisfaction while the rest of the web collapsed. Yet at the same time they were turning a blind eye to the blatantly non-standard things going on in the CSS to arrange the smoke and mirror show because, well… CSS is just presentation, so it’s okay to build that like a house of cards.
Essentially, we were coding for the anticipated standards and browsers of the future using primitive tools in unintended ways.
And, after all the effort, XHTML didn’t do anything other than allow a bit of willy waving for folk who took the time to ensure their code was semantically correct. Sure, you got to slap a little “standards compliant” badge on the footer of the site and feel smug about it – WordPress even does it by default, a sort of auto-smugness that you shouldn’t really take any pride in because you have nothing to do with it.
Unfortunately, the little badge is about the only tangible benefit of all the fuss. XHTML didn’t equip us with any rich new features to speak of – it just hammered home the point about style and structure being separate, which was something that was possible to achieve with HTML4.1, if you had enough discipline.
I’m currently working on a site that I’m trying to code in HTML4.1. I say trying because, after many years of forcing myself to close input and line break tags, for example, it’s a tough habit to break. However, in undoing those “good” XML habits, the work is coming along quite nicely and I’m rekindling the notion that HTML is a creative language. Not every line of code should need to stand up to clinical scrutiny.
And HTML5, unlike XHTML or XHTML2, actually does equip us with new tools and techniques to enrich the web, which I’m really looking forward to. Except this time I’ll be waiting until it is actually a standard.
