HTML: The standard that failed?

HTML is officially whatever the top browser vendors say it is at the moment. You call that a standard?

HTML is a standard dictated by browser vendors -- not an independent body.

That seems to be the message from the Web Hypertext Application Technology Working Group (WHATWG), which last week announced that it would be dropping version numbering from the HTML specification once work on HTML5 is complete. Henceforth, HTML will become a "living standard," with the most current version of the specification being the one maintained on the group's website. In other words, the standard is whatever WHATWG says it is this week.

HTML5 Deep Dive
[ Get your websites up to speed with the draft HTML5 today using the techniques in InfoWorld's HTML5 Deep Dive PDF how-to report. | Learn how to secure your Web browsers in InfoWorld's " Web Browser Security Deep Dive " PDF guide. ]

Technically anyone can participate in the HTML standardization process, via WHATWG's mailing list. But those who do so are known as "contributors," and their role is much like that of concerned citizens at a city council meeting. Actual membership in the WHATWG is an elite affair, however, and is by invitation only. Currently the total membership consists of three representatives from the Mozilla Foundation, two from Opera Software, two from Apple, one from Google, and one independent developer.

In effect, that's who's deciding the future of the Web: four of the leading Web browser vendors, all of whom have incentive to pile ever more features into their products to compete with alternative RIA (rich Internet application) platforms such as Adobe Flash and Microsoft Silverlight. (If you're wondering where Internet Explorer fits into all this, notice that Microsoft is not a WHATWG member.) What's more, Apple and Google are both prominent providers of Web content. But hey -- surely they all have our best interests at heart, right?

HTML5: A long time coming

WHATWG was founded for good reason. The last formal HTML specification from the Worldwide Web Consortium (W3C) was XHTML 1.1, published in 2001. XHTML was intended to be the natural successor to HTML, with an XHTML 2.0 standard to follow soon after. But that effort became mired in committee, and the W3C was effectively silent for three years -- a virtual lifetime by IT standards. WHATWG began as an ad hoc consortium of Web technology companies aimed at breaking that silence.

By 2008 the W3C, still unable to move forward on XHTML 2.0, accepted WHATWG's independent work as a new draft specification, to be known as HTML5. The main goal of the new standard was to evolve HTML from a simple hypertext document format into a standard better suited to modern Internet applications. That sentiment resonated with the broader Web development community, and by 2009 the W3C decided to drop its work on XHTML 2.0 and concentrate on finalizing HTML5 as the next major iteration of the Web standard.

But for the W3C to say it's doing something and to actually do it are two different things. Work on HTML5 has continued ... and continued ... and still goes on to this day. The standard is not expected to be finalized until next year at the earliest.

Nobody ever said drafting industry standards was easy. But in the meantime, browser vendors -- eager to showcase the most talked-about features of the new spec -- have resorted to implementing half-baked ideas and incomplete specifications, often in inconsistent ways. Most famously, the HTML5 committee gave up trying to specify codecs for the much-anticipated <video> tag when no consensus could be reached, leaving each browser vendor to support whichever video formats it saw fit.

No version control

That's exactly the point of giving up version numbering for HTML, says Google's Ian Hickson, a WHATWG member and current editor of the HTML5 specification. "Most of the [objections] seem to be based on the misconception that browsers target a particular version of the spec, possibly even targeting one version before moving on to the next," Hickson wrote in a comment posted to the WHATWG blog. "That's not the case. Browsers always follow the latest draft, because that's where all the bugs have been fixed."

Doubtless that's true. If I were implementing a browser today, I'd concentrate my efforts on supporting the latest version of the standard. I'd have to if I hoped to compete with Apple, Google, Mozilla, and Opera Software. What Hickson seems to be ignoring, however, is that not everybody who has a stake in HTML is a browser vendor.

Browser vendors might aim to support whichever version of the standard is current, but they have to ship their products sometime. Once they do, their customers will end up with a browser that supports some form of HTML as it was specified at some point in time. Without so much as a version number to go by, it will be virtually impossible for the customer to understand -- or even express -- just what form of HTML that actually is.

Furthermore, assuming browsers always track the latest version of the HTML spec might be fine for Google, because its Chrome browser regularly auto-updates to the latest version. That's not the case for most browsers, and enterprise environments in particular are known for their slow upgrade cycles. (Witness how many users are still stuck on IE6.) Without a version numbering scheme for HTML, there will be no easy way to measure what has changed between the browser I'm using today and the browser I could upgrade to -- which, perversely, could make upgrades even harder for IT departments to justify.

But hardest hit by this change will surely be independent Web developers, who now face the prospect of coding to a standard that, by WHATWG's own admission, will never be finalized. Companies who contract developers to build Web pages don't much care about Web specifications or version numbers; they want their sites to look good and to work well on as broad a range of browsers as possible. But how do you set a scope of work and specify coding standards for a project when you can't even express which version of the HTML specifications you're coding to? And what happens if the specification arbitrarily changes before the project is finished?

Throwing the baby out with the bathwater

Hey, WHATWG: We get it. The W3C standardization process for HTML is too slow. Browser vendors and content providers are eager to pile on features to support the new generation of Web applications. HTML has to change and grow in at a pace more in keeping with that of the broader IT industry.

Still, the decision to drop version numbers from HTML is a mistake. A "living standard" is essentially a dead standard, because it amounts to an admission that WHATWG can't really agree on anything, except in the most incremental and revocable fashion. That's not a standard; it's a handshake agreement among a few of the Web's most prominent vendors, and an entire industry is expected to follow along.

A standards body that can't set genuine standards is a failure. In that respect, I fear WHATWG may be heading down the same road as the W3C before it. Say it ain't so.

This article, "HTML: The standard that failed?," was originally published at Track the latest developments in programming at, and for the latest business technology news, follow on Twitter.

Copyright © 2011 IDG Communications, Inc.