The future of HTML, Part 1: WHATWG

The Web Hypertext Application Technology Working Group's approach to improving HTML

In this two-part series, Edd Dumbill examines the various ways forward for HTML that Web authors, browser developers, and standards bodies propose. This series covers the incremental approach embodied by the WHATWG specifications and the radical cleanup of XHTML proposed by the W3C. Additionally, the author gives an overview of the W3C's new Rich Client Activity. Here in Part 1, Edd focuses primarily on two specifications being developed by WHATWG: Web Applications 1.0 (HTML5) and Web Forms 2.0.


Edd Dumbill (, Chair, XTech Conference

Edd Dumbill is chair of the XTech conference on Web and XML technologies, and is an established commentator and open source developer with Web and XML technologies.

06 December 2005

Also available in Russian Japanese

HTML isn't a very good language for making Web pages. However, it has been a very good language for making the Web.

HTML's ease of learning and the view source capability for browsers has bootstrapped the Web's popularity in an amazing way. The World Wide Web Consortium's (W3C) involvement in standardizing HTML has ensured that Web browsers all implement the same dialect, more or less. The emergence of CSS, and the corresponding growth of standards-based Web design as best practice has also averted HTML chaos and led to a better Web experience for users and developers alike.

This much you probably know. The resulting Web has probably made a positive impact on your life or business. Yet the fact remains, HTML isn't a very good language. Why, for instance, does HTML have headings H1 through H6? Who ever seriously used a six-level-deep heading hierarchy? And why, in this era of 3D-accelerated graphics cards and sophisticated user interfaces, are Web pages limited to clunky text boxes and radio buttons for user input?

No surprise then, that various groups are pushing again to develop HTML in a way that lets Web publishing and Web applications use more of the technology that's available in modern user interfaces. Who are these people? Broadly speaking, they fall into three groups. The first are those who use today's technology to make a difference. This is what the Asynchronous JavaScript and XML (Ajax) buzz is about: using JavaScript and the browser's XMLHttpRequest object to create dynamic user interfaces. The effects can be wonderful, but this is not a standard way to move forward.

The other two groups focus on future improvements. The W3C promotes XHTML 2.0, based on the requirements of a broad vendor base -- not just desktop browser makers. XHTML 2.0 is seen as a radical step. In contrast, the Web Hypertext Application Technology Working Group (WHATWG) promotes a set of incremental specifications, which evolve HTML to add the most immediately required functionality into the browser. Some WHATWG features are already implemented in Apple's Safari browser and Mozilla Firefox 1.5. (See Resources for more on W3C and WHATWG.)

These articles will examine the work of the latter two groups: W3C and WHATWG. Ajax has been covered elsewhere in developerWorks (see Resources). While no standards war has erupted yet on the scale that brought HTML into the W3C in the first place, these two organizations are not always in agreement as to where HTML should go. I'll explain and evaluate both approaches.

WHATWG, HTML 5, and Web Forms 2.0

As their Web page states, WHATWG is a "loose unofficial collaboration of Web browser manufacturers and interested parties who wish to develop new technologies designed to allow authors to write and deploy Applications over the World Wide Web." Two terms are of particular interest here: WHATWG's main players make browsers (Mozilla, Opera), and the focus of their improvements is towards creating Web applications.

WHATWG's figurehead specification is code-named HTML5, but is known more properly as Web Applications 1.0 (see Resources). HTML5 is intended to preserve backward compatibility with the current HTML standard, HTML 4.01, and also with XHTML 1.0, the XML version of HTML. The specification sustains both the HTML and XHTML strands of W3C HTML, although it notes that implementations may choose not to.

In addition to HTML5, the Web Forms 2.0 specification (see Resources) seeks to address many of the annoyances that developers find with the current state of HTML forms. Today's forms omit many basic features from regular desktop applications, such as validation and richer widgets.

So what's inside HTML5? In short, a lot. The Web Applications 1.0 specification is an evolving beast, and some of the features mentioned are more fully developed than others. Here's a 30,000-foot flyover of the new features:

  • New layout elements, including a calendar control, an address card, a flexible datagrid, gauges and progress meters, drag and drop, and menus
  • Programming extensions to the Document Object Model (DOM), including server-sent DOM events
  • A formalization of the de-facto standard XMLHttpRequest object, the centerpiece of Ajax communication
  • Dynamic bitmap graphics through the canvas element

You can see the heritage of many of these in features implemented as one-offs with JavaScript on the Web today. Indeed, the recent rise in popularity of Ajax toolkits has led to a proliferation of widgets such as gauges, calendars, and so on.


Traditional implementation of HTML5 features -- that is, as part of a Web browser -- is restricted today to just a few of the technologies mentioned above. The most well-known among these is the canvas element. Firefox 1.5 and Apple's Safari browser have also implemented canvas.

While the W3C's Scalable Vector Graphics (SVG) language already provides a way to show in-browser illustrations, canvas takes a different approach. Rather than implement a declarative document, like SVG, it provides a blank surface for JavaScript to draw upon. This model of imperative graphics owes much more to OpenGL-style drawing than to the declarative Web.

Figure 1 shows a screenshot from a simple canvas demo. (See Resources -- you can view it with Apple's Safari browser or a pre-release of Firefox 1.5.) When the user moves the mouse over the shapes, the shapes slowly enlarge. Among other things, the demo shows that all the necessary ingredients for implementing user interfaces -- drawing, user input events, and timers -- are in place.

Figure 1. Screenshot of interactive canvas demo
Screenshot of interactive canvas demo

canvas applications are already one step closer to their obvious conclusion (games!) with the implementation of a simple 3D maze, as illustrated in Figure 2. (See Resources for a link to the actual maze.)

Figure 2. Screenshot of simple maze game
Screenshot of simple maze game

To get a flavor of how you can program canvas, look at some simple code. Listing 1 shows a self-contained example, the end result of which is shown in Figure 3.

Listing 1. Simple canvas example
    <title>Canvas demo</title>
    <script type="text/javascript">
      function draw () {
        var canvas = document.getElementById ('hello');
        if (canvas.getContext) {
          var ctx = canvas.getContext('2d');
          ctx.fillRect (25, 25, 50, 50);
    <style type="text/css">
      canvas { border: 2px solid red; }
  <body onload="draw ();">
    <canvas id="hello" width="100" height="100"></canvas>
Figure 3. Output of Listing 1
Output of Listing 1

As canvas does not present any declarative semantics, it is likely that it will have more applications in the user interface implementation area than anywhere else. An intriguing scope for canvas is as a prototyping ground for new browser interface elements and features. The best example of this is Antoine Quint's partial implementation of SVG using canvas (see Resources). Using Quint's method, to render an HTML file with embedded SVG, you add a couple of lines that import his JavaScript SVG renderer. Figure 4 shows the familiar tiger image rendered using this method.

Figure 4. SVG tiger image rendered using JavaScript and the canvas element
SVG tiger image rendered using JavaScript and the canvas element

Time will show whether canvas is useful in a mainstream Web setting. Its functionality is something akin to that of Java applets, yet its JavaScript interface makes it much easier to use and interface with other browser elements.

Web Forms 2.0

The WHATWG forms specification's version number indicates its intent to build on the specification of forms in HTML4. In contrast to the Web Applications (HTML5) specification, it is in a mature state. Web Forms 2.0's scope is also more limited -- focusing directly on improving the form widgets available in the browser.

What does this new revision of forms add? Among other things:

  • Validation constructs to allow the browser to do more checking before the form is submitted. New attributes include required, min, and max.
  • DOM support for validity, with a validity attribute for form elements, and a new invalid event.
  • Control over auto-completion for form elements, allowing document authors to indicate whether the browser should remember field values and offer to autocomplete them. Predefined values can be passed with the list attribute.
  • An autofocus attribute to indicate which form element should receive input focus when the document is loaded.
  • An inputmode attribute that allows the hinting of appropriate language input modes for text-holding form elements.
  • File upload control improvements, including specifying the expected file type and limits on file size.
  • Repetition of templated form elements.
  • New types of input controls: datetime, number, range, email, and url. Addition of patterns for restricting input values.

Web Forms is a more consistent specification than HTML5, and is already finding some implementation:

  • Beta releases of Opera 9 include Web Forms 2.0 support
  • An open-source Web Forms project has a DHTML+Behaviors implementation for Internet Explorer

The W3C's answer to the next generation of forms is XForms (see Resources). XForms differs from Web Forms 2.0 in that it develops a new model of browser-server interaction, based on passing XML documents. By contrast, Web Forms 2.0 is an incremental update to the existing form models intended to make current browser forms more usable. The two specifications address different needs, though obviously share some commonality. In the words of the Web Forms specification:

[T]his specification attempts to add some of the functionality of XForms with a minimum impact on the existing, widely implemented forms model. Where appropriate, backwards compatibility, ease of authoring, and ease of implementation have been given priority over theoretical purity.

Other implementations

canvas is the main WHATWG feature with browser implementation. The rest of HTML5 is still at an early stage, and may never be implemented in its entirety.

However, the Web Applications and Web Forms specifications are taking on a new significance that probably wasn't anticipated when they first took shape. In recent months, several full-featured projects for developing user interface toolkits for Web applications have emerged. These implementations use HTML plus JavaScript technology, or Flash. Many of them might well take the obvious view that it is pointless to reinvent the wheel, and look to aspects of WHATWG specifications to standardize, for example, their form implementations.


The Web Forms 2.0 specification, by virtue of the obvious need and the completeness of the specification, stands a good chance of receiving implementation and making its way into an accepted standard. Indeed, Web Forms 2.0 has been submitted to the W3C for comment, having the effect of being a position statement and building block from the WHATWG collaborators.

However, it is difficult to glean a coherent view of the future of HTML from the WHATWG specifications alone. Some parts merely describe current innovations -- XMLHttpRequest, canvas -- while others seem vague and lack the same drive from implementers. Additionally, motivation for HTML5 is mainly for desktop, application-centric, use. A great deal of HTML is now found on non-PC devices, and that is in need of direction too.

Some of the richer ideas specified in HTML5 might now be made obsolete by the rise of Ajax-based browser interface toolkits. Why should developers be content with the restricted set of widgets specified in a document when they have an extensible toolkit to play with? It might well be that richer Web interfaces are standardized more by the market than by committee.

I'm glad to see progress made in describing commonly-implemented, but as-yet-unstandardized, technologies such as canvas and XMLHttpRequest, and hope that this will promote the interoperability of these important features. To move browser technology forward itself, HTML5 needs more clarity, and would benefit from being divided into three specifications, covering available now, available soon, and imagineering features.



Get products and technologies


developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into XML on developerWorks

Zone=XML, Web development
ArticleTitle=The future of HTML, Part 1: WHATWG