HTML5 Jumps Off The Drawing Board

After several years spent trying to persuade Web site developers and browser vendors to move to XML-based documents, the World Wide Web Consortium has resumed development of HTML, announcing in mid-January the first public working draft of the HTML5 specification.

The consortium, known as W3C, hasn't given up on XHTML 2.0, which strives for elegance and insists on correctness. But those developing HTML5 take a more pragmatic approach: Consider the problems plaguing Web developers today and try to make their lives easier--without rebuilding the core of the protocol.

HTML5 detractors say the spec is not a step forward; they prefer the more elegant design of XHTML2, which is still under development. At some point, they argue, Web designers must be held to a stricter standard when developing sites. Yet the reality is that wide browser support is crucial for any Web standard to be useful, and XHTML2 is a more significant change for browser developers than HTML5.

And with no support for XHTML promised by Microsoft, elegance is proving a difficult sell.

For Web developers, this day has been a long time coming. HTML 4.01 was introduced in December 1999. The W3C released XHTML 1.0 as a successor to HTML 4.01, and followed with its latest standard, XHTML 1.1, way back in 2001. The intent of the W3C was to continue down the XHTML path with a release of XHTML 2.0, but the spec wasn't moving in the direction that several major browser vendors expected.

As a result, Apple, the Mozilla Foundation, and Opera formed the Web Hypertext Application Technology Working Group (WhatWG) in April 2004 to work on Web Applications 1.0, citing concerns regarding the W3C's progress with XHTML. Web Applications 1.0 was eventually renamed HTML5, and in April 2007 the WhatWG approached the W3C and offered its work as a basis for a new HTML standard. The W3C agreed.

There are significant changes within HTML5, including updates to ease interactive Web development. New elements include header, footer, section, article, nav, and dialogue capabilities to divide sections of a page more clearly, while advanced features include a "canvas" with a corresponding 2-D drawing API that allows for dynamic graphics and animation on the fly. HTML5 also eliminates some elements, such as frames and framesets, that have caused more usability problems than they were worth, although browsers are still required to support them.FEATURE PRESENTATION

While most developers have adopted Cascading Style Sheets, or CSS, as a better way of handling presentation of Web documents, HTML5 codifies this by eliminating most presentational attributes. To earn its Web Applications 1.0 moniker, HTML5 also adds APIs that include direct provisions for audio and video content; client-side persistent storage with both key/value and SQL database support; offline-application, editing, drag-and-drop, and network APIs; and cross-document messaging. While much of this is possible today through browser plug-ins, standardizing on these features and building them into browsers will make it much easier for developers to add advanced functionality that will work across platforms.

In contrast to XHTML2, supporting existing content is a key HTML5 design principle. Other design goals center on compatibility, utility, interoperability, and universal access. Compatibility means not only that existing Web pages should still render properly, but that new functionality introduced with HTML5 should degrade gracefully when an older browser is used.Another key conviction: Browser implementers should do their best to render pages that may have incorrect markup, and do so in a consistent manner. In stark contrast, XML is supposed to "error out" when a fault is reached, so a single mistake on a developer's part may create an unreadable Web page. Considering the number of pages that don't properly validate, that's a real burden to put on Web developers. "The HTML5 specification is a good step because it's a fairly realistic one," says Charles McCathieNevile, chief standards officer for Opera Software. "It doesn't aim to change the world in a radical way."

Internet Explorer doesn't support XHTML, and at press time Microsoft hadn't released plans to support it in future versions, instead saying it's concentrating on fixing more pressing issues, such as CSS and rendering errors in versions through IE7 and IE8 betas.

Fortunately, HTML5 makes concessions for phased adoption.

The W3C predicts that the full HTML5 recommendation will be ratified in the third quarter of 2010. You won't have to wait that long to take advantage, however; among the four most popular browsers--Internet Explorer, Firefox, Safari, and Opera--bits of support for HTML5 already are available. For example, all but Internet Explorer have implemented the Canvas element, and Opera includes Web Forms.

THE ACID TESTAt the same time, however, developers of the two most popular browsers, Internet Explorer and Firefox, are still struggling to come closer to full compliance with existing standards. The Acid2 test, developed by the Web Standards Project in 2005, was created to cajole browser developers into complying with current CSS specs, for example. On Dec. 19, Microsoft said its latest IE8 beta passed the Acid2 test, and on Dec. 7, changes to Firefox's Gecko layout engine that make this version pass as well were submitted. Both IE8 and Firefox 3 are expected to pass the Acid2 test.That's encouraging, but the bar keeps being raised. The Web Standards Project released Acid3 on March 3. Acid3 rates browsers' capabilities with ECMAScript (JavaScript) and the Document Object Model (DOM), which are important for Web-based applications. As of March 26, WebKit (Safari's rendering engine) achieved 100 on Acid3 for a public build, and Opera reports scoring 100 on an internal build. While Acid tests don't confirm that browsers are fully standards compliant, they were created to verify the features that Web developers consider most important.

Continue to the sidebar:
Rise And Fall Of Version Targeting In Internet Explorer 8

Mike Lee is an independent IT consultant and software developer and an InformationWeek contributor.