Experiment with the Latest HTML5 Technologies

By Cameron Laird

While much of what's written on HTML5 obscures the point, HTML5 is more of a series of projects than a completed, singular standard, at least for now. HTML5 is a collection of technologies, most of which continue to evolve. It began when the Web development community recognized many deficiencies in HTML4 and associated XHTML, ranging from minor syntactic incoherence to inadequate support of multimedia presentations. HTML5 aims to address this wide range of defects. To make the quickest advances possible, though, HTML5 is being standardized in pieces: easier and less controversial pieces like new input definitions first, and more complex (and contentious) ones like WebSockets and video later.

If you're a Web developer who wants to experiment with emerging standards this leaves you in need of reliable guidance on what's best for your site.

Stable HTML5 Specs

First of all you should separate the stable technologies from the emerging ones. The three specs that are most stable and ready for your site are Geolocation, Canvasand SVG. These are now supported by modern browsers like Chrome, Internet Explorer 9 and Firefox. You can see these technologies in action on these sites:

  1. World's Biggest Pacman
  2. Disney Tron Legacy
  3. The Killers Music
  4. HTML5 Web Camps

Or read some tech articles on how to create them for your site like:

  1. HTML5 Behind the Scenes of Disney Tron Legacy
  2. How to Create a Location-Aware Page
  3. How to Use Canvas to Create Games

Second, step back again to a broad view of HTML5 as a whole, and recognize that each of the browsers goes about standardization in a different way. Some browsers already advertise availability of IndexedDB, for instance, even though the draft standard remains in review and is likely to change. Others take a more conservative approach. They may risk "missing out" on early adoption, but developers can be confident that changing specs will not break their sites. Developers should therefore choose when to implement based on experimentation and testing across the browsers their customers use.

Early-Stage and Experimental HTML5 Specs

An emerging set of HTML5 standards are pushing the limits to what developers can achieve on the Web. Capabilities like IndexedDB (browser data storage), WebSockets (high-performance networking), FileAPI (filesystem ops) and Media Capture (integrated speech) will be possible on the Web in the near future. You can learn how to experiment with these using HTML5Labs, a site launched at the end of 2010 to support users of early-stage Web standards. Below, I'll walk you through what to expect.

IndexedDB: An Easier Database for the Web

Suppose you're a front-line designer working on an application that needs to manage customer transactions — orders, payments, inquiries and so on. To manipulate the datasets of interest, you could write your own AJAXy code to synchronize with server-side master databases, perhaps in cooperation with cookies and session variables. You'll probably use, at least in part, one of the many fine JavaScript frameworks available. You're likely to find that you still have to solve at least a few tough problems involving transaction rollback or scalability.

There's a better approach: IndexedDB. Experienced analysts at the World Wide Web Consortiumhave thought through the client-side data-management challenges typical for Web applications, and drafted an application programming interface called "IndexedDB" that structures solutions well. You can write HTML that relies on createIndex(), transaction() and the rest of the interface as defined there, right now.

When you're ready to "go live" many browsers will already have implemented IndexedDB, and run-time compatibility libraries are expected to be available for all the others in short order. In the worst case, your code will read-in a few extra JavaScript libraries, and execute IndexedDB to achieve the results. Reading those compatibility libraries is an inexpensive price to pay for the advantages of being able to code to the smartest API targeted at high-speed client-side asynchronous data lookups.

WebSockets: A Controversial API

WebSockets is a part of HTML5 that particularly illustrates the importance of HTML5Labs. To understand this requires a bit of background.

The basic architecture of the Web has a browser issuing a request to a server for a page to display. "Need more data? Request a page." This "pull" approach has obvious limitations, most notably that there's no way for the server to announce, "Hey, browser! I have something you'll like ready for you." There is no "push."

The definition of communication between Web client and browser has expanded in several ways over the last 20 years to accommodate more sophisticated channels. Most recently, the WebSockets definition introduces bi-directional, full-duplex capabilities that provide for either the client or the browser to send or receive efficiently at any time.

Several consequences were predictable. Game enthusiasts were among the first to write against WebSockets, because it opens new opportunities to create multiplayer interaction. Almost as quickly, security gaps turned up. WebSockets "pushes the envelope" of what's possible with conventional networking, and errors were inevitable.

The result: some browsers have never supported WebSockets, some browsers have always supported one form or another of WebSockets and a few browsers have supported the interface, and then stopped supporting it.

In this case, HTML5 Labs treats WebSockets as a "prototype" here for developers to get:

  • code samples that express a draft standard
  • an executable environment that correctly interprets the code samples
  • an associated spec documentation and timeline to spec stability

The "executable environment" might be anything from a small JavaScript library that, at least in principle, any browser can load, all the way to a complex installer with parts in CSS and ActiveX only.

FileAPI bridges the Web and Desktop Worlds

HTML5's FileAPI also remains experimental, as of this writing. You might expect that a file specification is easy; desktop computing certainly has routinely relied on folders-and-files for decades. The context of a Web browser, though, brings new security challenges to proper definition of a file interface, especially when one considers that the objects of the FileAPI must behave consistently across distinct threads of threaded Web applications. Among other benefits, a well-defined FileAPI will make uploads into Web applications smoother and faster for end users.

The published FileAPI has already changed once, and is not yet finalized. The prototype is available, however, so that developers can experiment with this important new interface.

Media Capture API

The "greenest" of these four interfaces is the Media Capture API. HTML5Labs doesn't even provide a prototype library in this case; although it is possible one will be released that supports only audio capabilities.

What will Media Capture do? Think for a moment of a typical form in a Web application. You might need to give your address, including selection of a state (or province or so on). Until now, we've all done this by "clicking" on the right spot on the screen, or a close equivalent. With Media Capture and a bit of straightforward programming, the end-user will be able to say "Tennessee" or "Gujarat," and have the browser correctly decode the selection from the signal the microphone transduces.

Going from Experimental to Site-Ready

Developers need a site like HTML5 Labsto learn, experiment and to determine when a spec is site-ready. Browser makers play a role in determining spec stability by choosing when to adopt the standards. As Microsoft's General Manager for Interoperability Strategy Jean Paoli puts it, " Developers should be confident that browsers are based on stable HTML5." HTML5 Labs is a good place to decide what you think and what it means for your sites.