may the force be with you

Level: Introductory

Edd Dumbill (edd@usefulinc.com), Chair, XTech Conference

06 Dec 2005

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.

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.

canvas

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.

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

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.

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.

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.

Conclusion

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.

Back to top

Resources

• Visit the Web Hypertext Application Technology Working Group (WHATWG) to find out more about Web Applications 1.0 (HTML5) and Web Forms 2.0. These specifications include details on all the features described in this article.
  
  
• Get to the bottom of what Ajax is and isn't by reading its Wikipedia entry.
  
  
• Take a closer look at Asynchronous JavaScript and XML (Ajax). developerWorks hosts a wide range of content on this popular technology, which uses JavaScript and the browser's XMLHttpRequest object to create dynamic user interfaces.
  
  
• Bookmark the World Wide Web Consortium (W3C) site, home to many widely-used standards, including technologies mentioned in this article:
  • XForms
  • W3C Team Comment on Web Forms 2.0 Submission
  • HTML/XHTML
  • Scalable Vector Graphics (SVG)
  
  
• Learn how to use the canvas element on the Mozilla developer's site.
  
  
• View the simple canvas demo illustrated in Figure 1. You need Apple's Safari browser or a pre-release of Firefox 1.5 to view this demo.
  
  
• This simple 3D maze takes canvas one step closer to the gaming world.
  
  
• Check out Antoine Quint's partial implementation of SVG using canvas .
  
  
• This open source Web Forms project from SourceForge has a DHTML+Behaviors implementation for Internet Explorer.
  
  

• Download the Opera browser. Beta releases of Opera 9 include Web Forms 2.0 support

# posted by dark master : 12/09/2005 09:38:00 AM