HTML5 shoot-out: How Chrome, Safari, Firefox, IE, and Opera measure up

Has it really been four years since the buzzword “HTML5” came screaming across the sky and gave us every reason to believe in the power of JavaScript in the browser? Time flies when you're writing code.

HTML5 is back on the tips of our tongues because the W3C committee finally decided it's time to stop fiddling with the HTML 5.0 spec and move on to HTML 5.1. This marks a historic occasion because the HTML4 document was finalized in 1997. Time drags when you're working on a committee.

What's the world been doing? Certainly not waiting for a final draft. Websites that take advantage of the standards in HTML5 are everywhere. The browsers support many of the HTML5 features, and they're getting better with each rev. The differences between the websites and the native apps are smaller than ever, and complex, interactive websites that behave like native apps are more feasible than ever.

Now is a good time to revisit the browsers and see how they're adopting the recommendations of the HTML5 standards committee. The new form elements, tags, attributes, and background features in the proposal are no good to the world if they're merely ideas on virtual paper. The browsers are where the dreams of the committee turn into the reality that all of us experience when we write code or visit a website.

The good news is that the browsers are converging on the standard. The scores on the automated checklist, HTML5Test.com, are getting closer and closer to perfect, although there's still a big difference between some browsers.

It's worth noting that HTML5Test boils all of the standards compliance down to one number (from 0 to 555) that's simple to read, easy to compare, and devoid of all nuance. The automated test checks only whether a feature is supported, by creating some DOM objects. It can't tell whether the feature is implemented correctly, elegantly, or without horrible bugs. To make matters worse, everyone will want to argue with the number of points given (or not given) to particular features.

While a single number is hard to ignore, the real answers lie a bit deeper. Spending a few minutes scanning the lists reveals the priorities of the development teams steering each browser. Some of the new features that aren't yet supported may not feel like a big deal. Google's Chrome supports custom scheme handlers but not custom content handlers. Firefox doesn't support some of the newer input fields for forms like time, month, or week. There are at least a dozen or so omissions on each platform, and few of them make much difference in any user’s experience now. But that’s now. Compliance is about building a firm foundation for the future.

Browser politics

Some of these differences stem from deep political and financial battles hiding behind the scenes. Firefox and Chrome support the WebM and Ogg Theora video codecs, but not MPEG-4. Safari supports MPEG-4 but not WebM or Ogg Theora. At least they all agree to support H.264. These codecs aren't officially part of HTML5, but they are such a big part of the modern Web that progress on them may be more important to many Web developers than all of the other features.

Other items in the test aren't even part of the official HTML5 draft because they're part of another specification that may have been spun off from the official HTML5 spec. It's often hard for Web developers, server programmers, and especially users to draw a line between what's HTML5 and what's a new or better feature. Some of the most attractive features like Web Storage and Web Workers aren't under the HTML5 umbrella, though they're also being nurtured by the W3C. They may have an even bigger impact.

The core of the HTML5 spec finalizes the addition of a number of new tags designed to indicate the role played by the text inside the tag. They specify areas like sections, asides, footers, and headers. In the old days, we would mark them up with tags that specified the typography, like <h3>. Now they'll be marked up with their role, so they can be given their own CSS styles, and the browser will lay out the elements accordingly. The trend to separate the text and images from their arrangement and presentation on the page continues.

There are fascinating debates behind these changes, but they’ll be important only to the folks who worry about the appearance of Web pages. There are, for instance, some who want to stamp out the use of tables for layout and others who merely want to discourage it. It may be possible to intuit how a table tag is being used by reading the attributes. Adding a border or giving the column a header means it's probably holding tabular data. Leaving the border off means it could be a layout.

Using the elements in the “wrong way” can have consequences beyond offending self-appointed guardians of the Web. Clever repurposing of tags (like table) also breaks other systems. The HTML5 team is devoting more resources to making it easier for the blind and disabled to use the Web. Using table tags for anything other than tables of data confuses the screen readers and other mechanisms. Now there is a new class of attributes starting with the acronym ARIA (Accessible Rich Internet Applications) that provide alternative descriptions of the data inside. In general, the push to separate the message from the presentation is helping make this much easier.

From Web pages to Web apps

A good deal of the recent work has been in the extras that are turning static pages into full dynamic applications. The specs for Web Storage, WebSockets, and Web Workers have grown much fatter as the browser builders figure out what's working and what's not. These specs are the ones making it possible for programmers to create full-featured suites of software like Google Docs. Saving data locally and allowing background communication and threading is essential for working with nontrivial data sets.

The changes are largely focused on small details that may not even be noticed by many developers. The spec for Web Workers, for instance, now declares that the worker officially begins when a separate parallel execution environment is created. This is only important when the workers are timed, so they won’t impact the vast majority of more basic workers.

There are dozens of small changes like this in Web Storage, as well as debates around them that may not be finished. Some feel that forcing the different threads to flip a mutex bit to access the Web Storage adds too much overhead. Others believe that data integrity is important because people often browse the same websites in multiple tabs.

These are the kind of tidbits that the W3C debates, but programmers might not care. If they're only storing a few thousand items and the performance is OK, many of the details in these specs aren't important to them. But the browser makers must sweat them all.

Because many of the details are left uncertain, the browser creators often make different decisions. The Web Storage spec says browsers should “limit the total amount of space allowed for storage areas” and suggests that 5MB might be a good limit. These are details that the browsers and the users will converge upon in the future. Meanwhile, the implementations differ. 

One of the most contentious areas may be in the media processing. The Web browser is becoming the dominant way we access video and the HTML spec team has clearly set their minds on conquering the living room. The Encrypted Media Extensions spec includes a sophisticated mechanism for juggling the video feed and the keys, so only the properly licensed browsers will be able to display the imagery. Chrome, Opera, and Safari support these media extensions; Firefox and Internet Explorer don't.

There is plenty of other work aimed at creating moving parts. One new draft, Web Video Text Tracks, explores a standard mechanism for synchronizing video with other parts of a website. It is mainly aimed at captions, but there's no reason it won't find more applications creating multimedia extravaganzas. I can see words and graphs and imagery flying everywhere; all of the browsers support it.

Web futures

While it's natural to think of the crowning of the HTML5 spec as the end of a long process, it's better to see it as the beginning of the next generation. Some of the ideas were bumped from the 5.0 spec because there wasn’t enough “implementation experience.” In other words, the features haven’t been out long enough for everyone to know whether they’re doing what we want.

A quick skim of the HTML 5.1 spec, already in draft form, includes features like the accesskey attribute for adding keyboard equivalents to mouse clicks. There is more support across all of the browsers for the HTML Editing APIs that make every Web page potentially editable and the entire Web potentially one big Wiki.

Even bigger changes may be afoot, as some would prefer HTML become more like XML. It's not merely an attempt to make everyone close all of those open tags -- which obviously bugs some developers and rattles the parser teams. Some contributors to the HTML5 specification are already talking about allowing the next version to be “hackable.” That is, they want a spec that would allow us to define our own tags and our own mechanism for handling the tags after they’re parsed.

This has the potential to make the markup much more efficient. Anyone who has hit the View Source button lately knows that many HTML files may be 50 to 60 percent <div> and <span> tags, each with several different classes attached. Debugging the CSS style files is growing increasingly difficult. One way to clean this up is with a fully extensible tag system.

All of these decisions lie in the future. The 5.0 milestone is a big one, but it’s only a pause in the evolution of a standard that has defined how we present and interact with information.

Enough generalization -- it's time to dig into the browsers.