Navigating HTML5 Standards

Dueling standards bodies mean that the future of HTML isn't what it used to be. Here's how to figure out which browsers and features to support.

Two standards bodies with different aims, working on different timescales, cloud the future of HTML. Here's a guide for those who test, deploy, and support browsers and systems.

The World Wide Web Consortium, W3C, which defines many of the standards that make up the Web, does not operate on Internet time. After standardizing XHTML 1.1 in 2001, the body took 5 years to produce 8 drafts toward the definition of XHTML 2.0. Not nearly agile enough.

Engineers from companies making Web browsers (Apple, Mozilla, and Opera) got together on a faster track and in 2003 the Web Hypertext Application Technology Working Group (WHATWG) was born. They started working toward the definition of HTML5, intended as the evolution of HTML that would support Web applications in a robust way. They had an advantage over the W3C in that they could base their work on actual implementations in living browsers.

In 2007 the W3C endorsed the WHATWG's work on HTML5 by adopting it as the basis for the W3C-sanctioned working draft of HTML5. By 2009, the W3C had abandoned work on XHTML 2.0 in favor of HTML5.

The WHATWG is now pushing to drop the "5" (wonder what will become of that spiffy logo?) and stress that what they are working is on simply "HTML" -- a collection of evolving features rather than a completed specification. HTML itself becomes a "living standard," where implementations trump standards.

The result of this fluidity: the only reliable way to implement HTML going forward will be to target specific browsers, and specific versions of specific browsers, not some particular version of a standard. Which of the many features of HTML5 you implement, for internal or external use, will depend on what browsers and versions you need (external) or choose (internal) to support.

Here are specific suggestions to keep your HTML development and browser deployment and support on the right track in this fast-changing environment.

Decouple the browser from the desktop. This is especially important if you are internally supporting browsers (such as Chrome) developed on a rapid update cycle. You can accomplish this decoupling via remote virtualization or self-contained app deployments. The result will be that the IT department, not the browser maker, dictates the upgrade cycle.
Separate HTML5 development from HTML4 / XHTML. The latter are stable and based on settled standards, while HTML5 is a swiftly moving target. IT shouldn't formally add support for HTML5 elements until the majority of browsers embrace it, in as consistent a way as possible across browsers.
Use analytics to help you pick the proper timing. This is particularly important for IT shops involved in developing externally facing apps. Find out what browsers and versions your visitors are using -- use your own analytic data, don't rely on third-party numbers. Use that information to guide which features of HTML5 you will implement when.

Many more details and links can be found in this Computerworld article, which will repay your close reading.