How to cope with HTML5's dueling standards

The nice thing about standards is there are so many of them to choose from.

That old chestnut, attributed to any number of different parties, has been in circulation since long before there was an Internet, but it still speaks volumes to the curious situation developing today:

With multiple, parallel versions of HTML in use; a slew of different browsers in play, all of which implement those HTML versions slightly differently; and two separate standards-setting bodies directing traffic, the World Wide Web looks to have any number of possible futures. The decisions of the World Wide Web Consortium and the Web Hypertext Application Technology Working Group are more than just academic, and they raise some sticky questions.

How should we go about supporting browsers that are becoming more fluid, with point revisions every few weeks instead of every several months to a year? And how do we tap all of HTML's new, evolving functionality without breaking existing designs or compatibility?

To answer those questions -- and chart a course for HTML evolution in murky waters -- it helps to know a bit of background about these august institutions.

In this corner, W3C

The World Wide Web Consortium (W3C), the standards-setting body most directly responsible for the Web as we've come to know it, was formed in 1994 as a way to corral together a single, consistent version of HTML. This it achieved, at two costs.

The first involves enforcement, or the lack thereof: The W3C's standards are Recommendations (they insist on the capital R), which aren't backed by any enforcement. That's because attempts in the early 2000s to provide official conformance testing for W3C recommendations fizzled out amid concerns that the group would become too authoritarian or too commercial.

The other cost is the speed of decision-making. The W3C, whose membership is a broad and diverse mixture of companies, educational institutions and individuals, has been consistently criticized for being stodgy and hidebound. After XHTML 1.1 was published in 2001, it took the W3C until 2006 to release eight working drafts for XHTML 2.0. Such a pace just wasn't working for a Web that was becoming more consumer-focused and commercially driven.

In that corner, WHATWG

In retrospect, it's no surprise that another group -- the Web Hypertext Application Technology Working Group (WHATWG) -- arose in 2003 to tackle "the development of HTML and APIs needed for Web applications." WHATWG is a conglomeration of engineers from Apple, Mozilla and Opera; all three have a hand in the browser market, and that's how WHATWG drives progress -- from the browser side.

"The WHATWG is faster-moving and able to take direct action on standards because many of the members own the browsers that users rely on," explains Forrester researcher Jeffrey Hammond. "The WHATWG follows the golden rule: He who has the gold -- browsers in this case -- makes the rules."

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."

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.

How to cope

Wait until a given feature is uniformly supported by the major browser share using your application, then add it. Derive actual usage statistics from your site logs; don't rely exclusively on user feedback to decide which browsers to support, as the loudest voices don't always represent the lion's share of actual users.

Whenever you can, keep development on HTML5 discrete from development for HTML4 and XHTML. The latter two are stable, known quantities. HTML5, on the other hand, has a lot of elements that are still protean, and therefore you shouldn't formally add support for any of those elements until, one, the majority of browsers have it and, two, the features in question are implemented as consistently as possible across browsers.

There's no denying the evolution of HTML5 is a mess but also unavoidable at this point -- and on the other side of that mess is a whole new kind of Web. "We're in a period of short-term pain in order to get long-term gain," says Hammond. "It's platform fragmentation, which is driving browser fragmentation, which is driving innovation. As a result, the level of support for standards and proposed standards is all over the place."

Once those standards are adopted, things should settle down, Hammond predicts. "We'll see greater pressure from all to support them."

In the meantime, hold on tight and enjoy the ride. "Evolution is messy during periods of punctuated equilibrium. That's the kind of era we're in right now."

Elsewhere on IDG sites

Read Next...