How to cope with HTML5's dueling standards bodies

Often the WHATWG's quicker actions spur the larger W3C to adopt a de facto standard more rapidly than it otherwise would, he says.

One significant case in point: The WHATWG's work with HTML5 was adopted by the W3C in 2007 as the basis for the current W3C-sanctioned working draft of HTML5. Moreover, by 2009, the W3C had abandoned work on XHTML 2.0 in favor of HTML5.

"W3C is certainly the more presidential and regulated master of Web standards, but WHATWG is more progressive and focused more on the delivery [of] HTML and related technologies," says Christian McMahon, former CIO of GoIndustry DoveBid and current managing consultant at Web development firm Jamaza.

In the end, McMahon and other industry watchers agree, the two standards groups are best off collaborating and not competing. "Working together is the only real way to create stability in recommended standards."

Related reading: Three HTML5 animation tools: Adobe Edge, Sencha Animator, Tumult Hype (Insider: registration required)

The current state of HTML

Because of this back-and-forth between the WHATWG and the W3C, we've ended up in a peculiar place as far as Web standards go. Let's take stock:

HTML is a "living standard."

The most confusing and potentially distracting aspect of the current state of Web standards, especially for IT managers, is that HTML5 exists not as a single cohesive specification but as a collection of different features under the general umbrella of "HTML5" (or just "HTML," without the numeral, if you're on board with WHATWG's campaign to drop version numbers going forward). Support for any one of those features (e.g., the video tag, native drag-and-drop, the file-manipulation API, or websockets) depends entirely on the browser (see a list of variations here).

Consequently, it's that much harder to pick any one of those features and support it consistently. Any long-term planning has to be done in terms of a specific product -- a browser -- rather than a specific feature. This can drive IT people crazy, especially the most sophisticated ones: Shouldn't it be the standard, not the product, that dictates their choices?

The timetable is uncertain.

It follows that if HTML is a collection of evolving features rather than a completed specification, it's not easy to predict when a given feature will be available. Different browsers have different incremental levels of support for HTML5, which means gaining access to many of the individual features in HTML5 is entirely a matter of which browser you're using and what revision you're on.

It's also not clear when a given feature may show up in a given browser, or in what form: You can only count on what's there now, or what's been there for a few revisions, or what's rumored to be on the way.

The browser has become the standard.

The end result of all this is that specific browsers -- and sometimes specific versions of specific browsers -- have become the only reliable way to implement HTML5, and sometimes HTML generally. Chrome, for instance, has historically been a good supporter of HTML5, with Firefox, Safari and Internet Explorer in rough order after that.