Reading Up On HTML5 - A Rant

I've been reading up on HTML5 lately, feeling that I should brush up my web development skills before I attempt an upgrade of a personal web page. Every other web page these days seems to be taking its design cues from some for me yet unknown source and I figured HTML5 is probably the place to look.

I've come across it before, of course, both in my day-to-day work and at markup conferences. We've been doing various web solutions and mobile apps involving HTML5 for some time now, and this year's Balisage, to pick the most recent markup conference I've attended, started with a one-day symposium on HTML5 which was both interesting and illuminating. There's a lot of it going on, right now.

And the other day, I came across HTML5 - The Missing Manual and have been reading it on and off since. It seems to be quite comprehensive and more or less what I need right now, but it is not a book primarily written for markup geeks. Don't get me wrong; it is well written, as are all of the Missing Manuals I've read, and it seems to do a reasonably good job explaining its subject.

But--and there's always a but, isn't there?--there's stuff in that book that makes me cringe. Or rather, it's not the book itself but what the book represents. See, the book seems to define that moment in time when I am no longer able to selectively ignore the HTML5 crowd.

There are a couple of terminology issues, of which the most annoying to me right now is that empty elements are apparently called void elements these days. This is not the author doing a reinterpretation of anything, this is the W3C working group talking--I just checked--but it is a symptom of what I am talking about here.

Another symptom, and one known to everyone who's done any web-related markup since the inception of the web, is how markup errors are frequently shrugged at. Nesting errors are the most glaring, of course, and the way they are ignored is to say that everybody does them but the browsers can all handle them, so while you may decide to be anal and actually validate your HTML, the message between the lines is that it's OK and you shouldn't worry about it since the browsers can handle it.

Coupled with this lax attitude towards draconian error handling (actually any error handling that is not related to browser-based limitations) in the book is the not-so-subtle hint that this is all the fault of the oh-so-obviously failed XHTML attempt from a few years back, when W3C tried to introduce XML syntax rather than fix HTML.

And there are the usual mentions of missing end tags (but no recognition of the fact that this was actually an SGML feature, once upon a time) and how that's really not such a bad thing after all because modern browsers can handle it, and the closely related ignorance towards empty (sorry, void) element syntax. It's OK, no need to be anal about it, because modern browsers can handle it. It's a question of style.

The HTML DOCTYPE declaration is explained, of course, and its lack of any kind of versioning indicators, SYSTEM or PUBLIC identifiers, etc, declared to be a good thing. Again, the motivations are browser-based and basically about doing it in this way because the browsers can handle it. The DOCTYPE declaration's existence is only important because of legacy reasons.

And the whole concept of well-formedness is explained as a matter of good style but really not much more than that (since yes, the browsers can handle it), and the benefit mainly the ability to include a couple of attributes in the root element.

And on and on it goes.

I don't mean to say that HTML5 is a bad set of standards--I know far too little about it to have an informed opinion--but much of the attitude I'm seeing in the wonderful world of HTML5, both now in this book and earlier in the various presentations and discussions I've witnessed or been a part of, seems both frivolous and dangerous. It seems to me to be a combination of reinventing the wheel and ignoring the lessons learned by others, and I can't help wondering what damage it will do to other markup technologies.

The Balisage symposium from earlier this year did give me hope--the people present were both smart and reasonable, more than willing to listen and learn from each other, and the discussion that ensued was informative and balanced--but most people do not go to Balisage, or any other markup conference, for that matter. They learn by doing, and some by reading, and quite a few sources now are like HTML5 - The Missing Manual, well written, comprehensive--and potentially dangerous to anyone with no experience of markup technologies outside their immediate needs, because they reinvent, reinterpret and redefine what they need and ignore everything else.

The result, I fear, is a more complex situation than ever in the world of markup, a situation where different sets of standards apply depending on the context and where XML, while sorely needed by some parts of the community, is ignored by others.

End of rant. Thanks for reading.