BMW traps alleged thief by remotely locking him in car

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

Chrome and Opera lead in compliance with the latest Web features, but the differences among browsers may be smaller than they appear

By Peter Wayner InfoWorld | Apr 29, 2015

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

. 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

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

Browser No. 1: Google Chrome

Chrome has the highest score on the HTML5Test -- 523 for Chrome 42-- and that says much about Google's commitment to driving the HTML5 spec and producing one of the leading browsers. There are only a few check boxes left for the programming team to mark and a few points for them to earn.

The omissions are scattered throughout the chart, and there's no easy way to summarize with a simple phrase. You'll find a missing markup element here and an unimplemented graphics method there. All in all, Chrome is a dream for anyone committed to a broad set of tools for building user interfaces. If you want to use all of the new markups or form elements, Chrome is your best choice. There are very few gaps in the list.

Some of the bigger omissions are under the hood. There are no hooks in the JavaScript engine that fire separate events when scripts start and stop executing. And there is no easy way to use scope to control how the CSS styles affect the page. Nor are there opportunities to use your code to register a function that processes all data of a particular MIME type or URL scheme, the so-called custom content handlers.

All three, incidentally, are ideas that were implemented in Firefox long ago. They haven't caught on with the team at Google.

Another area that might bring frustration is the support for codecs and media formats. MPEG-4, for instance, works with iOS browsers but not with Chrome. Both Apple and Microsoft support audio track selection, and Apple supports video track selection, but Chrome won't let you monkey around with these.

In all, Chrome is a great browser for anyone who wants to start using the extra features that are part of the new standard.

Browser No. 2: Opera

At this writing, Opera is currently in second place in the HTML5Test, but by only four points, with 519 for Opera 29. Like Chrome, Opera offers broad support for the new markup and form elements, so it’s as good a platform as Chrome for anyone who wants to experiment with them.

By the same token, Opera also skips custom content handlers, scoped style elements, and script execution events. But then, so does every other browser besides Firefox.

The biggest differences lie in the codecs, where Opera fails to support the MPEG-4 and H.264 video formats. To complicate matters, it also lacks support for AAC and MP3, two audio formats that have been around for some time. Thus, getting your multimedia content to work with Opera can be a bit tricky. Opera is almost certainly hemmed in by patent licensing costs, and the company probably chose to ignore the heavy licensing costs. Opera certainly supports Ogg Vorbis, Ogg Theora, and WebM, which are good enough, if not directly compatible.

Along with Internet Explorer and Chrome, Opera is leading the way with “pointer events,” a generalization of the different input models. These aim to make it simpler to support mice, touchscreens, and styluses by offering the programmer a single, simpler event model that harmonizes them.

In all, Opera is an impressive browser that doesn't get as much attention as it should. It is rivaled only by Chrome in its broad support of modern Web features.

Browser No. 3: Mozilla Firefox

Numerically, Firefox looks like it's a bit behind the two leaders. It scores 449 on HTML5Test, for Firefox 37, but this fact is affected heavily by the weights that the test gives to the various features. Firefox loses many points on some areas where it lags and gains fewer points on the areas it leads.

Many of the points are lost, for instance, because Firefox doesn't implement many of the new input fields and interactive elements. If you want to simply add one form element to collect date or time values, Firefox won't help you. For these omissions, it loses 26 points, but it's not clear whether any programmer really suffers. There are already elaborate JavaScript libraries for accepting time data, and they've been designed to be cross-browser compatible. Many of them are also highly stylized and better-looking than the generic tools. Thus, many programmers choose these over the built-in support.

The scoring also doesn't reward Firefox for taking the lead. Events that fire when a script is about to execute are useful for juggling loads, but support for these script execution events gains Firefox only one point. Adding scope to the style sheets is useful for integrating several style sheets, but it’s worth only two points in the eyes of the HTML5Test creator.

Firefox no longer wins any points for implementing microdata markup, the extra tags that make it simpler to identify and flag some common data types in Web pages. Unloved by the W3C and all the other browsers, microdata is supported only in Firefox at this point.

In codecs, Firefox offers broad support, but avoids MPEG-4, putting it in the same camp as Chrome and Opera. It supports Ogg, WebM, and H.264, which are more than sufficient.

Are these differences important? It all depends upon how you weigh the features personally. If you like all of the new form elements and must have them, Firefox isn't for you and your project. But in many ways, Firefox offers the same level of compliance as the browsers with higher scores -- if you don't care about things like the new time input form fields.

Browser No. 4: Apple Safari

On the HTML5Test, Safari 8 earns 396 points on the HTML5Test, which makes it look further behind than it may be in practice. Like Firefox, Safari loses a great number of points by failing to implement all of the possible form and markup elements. There are no options to make an input field to collect time or color and no support for the standard menu elements.

Game developers, though, may be more put out. There's no support for tracking the orientation or motion of the device, or for gamepad control or the more general pointer events. If you're going to create items for Safari, it may be best to stick with traditional content and avoid elements that are too interactive. Leave those for the App Store.

In the world of codecs, Apple takes a different path than Chrome and Firefox. Safari will display MPEG-4 and H.264 video but reject WebM and Ogg Theora. The good news is that video and audio tracks can be controlled through JavaScript.

There are a handful of other places Safari falls short of the more complete feature sets in Chrome, Opera, and Firefox. Whereas these browsers support peer-to-peer communications via WebRTC, Apple offers no support yet, keeping company with Internet Explorer. Nor does Safari support service workers for background processing, custom scheme or content handlers, or custom search providers.

These omissions aren't debilitating by any means. Apple still offers broad support for the standard and delivers many of the most interesting features.

Browser No. 5: Microsoft Internet Explorer

Version 11 of Microsoft's once indomitable Internet Explorer has the lowest score on the HTML5Test -- a mere 348-- but this shouldn't be much of a surprise. The standards movement was always driven by the hope to encourage competition and dislodge Microsoft from its control of the Net. It's working the way that some people clearly hoped it would.

IE lost points throughout the chart and can't even muster enough to lead in one area. In fact, the only area where it beats any of the other major browsers is in Web applications, where its support for custom search providers narrowly edges Safari. The rest of the time it's bringing up the rear.

While it's certainly fair to use the lower score to judge Internet Explorer's devotion to implementing every last bit of the HTML5 standard, it's not a good indicator of how smoothly IE will run HTML5 code or perform on a day-to-day basis. A quick skim of the results shows that many of the points are lost for features that are new and far from essential. IE lost points, for instance, for not supporting CSS selectors like “in-range,” “out-of-range,” and “read-only.” It also lacks support for a number of new input fields for time.

There are dozens of places where IE is missing support for little features or additions but none of them seem like showstoppers to me. Sure, they'll annoy some programmer who wants to use them, but they won't stop the browser from working well enough.

There are a few bigger omissions. Microsoft avoids MPEG-4, Ogg, and WebM video, as well as PCM, Ogg, and WebM audio. That leaves MP3 audio, H.264 video, and Flash video as the only supported standards that stretch across the Web. IE does, however, allow JavaScript to control the audio tracks.

It's worth noting that Microsoft clearly understands the value of standards compliance, and it's making rapid gains. While the Internet Explorer version number odometer doesn't spin as quickly as the other browsers, it was only a short time ago that IE9 eked out a mere 113 points. And the pace seems to be quickening with Project Spartan, the new Web browser that comes with the Windows 10 preview.

The latest version of Spartan (which arrived in Windows build 10061) earns 390 on the HTML5Test, well ahead of IE 11 and just shy of Safari. The biggest improvements over IE -- support for device orientation, device motion, gamepad control, Web audio, DRM, media extensions, and responsive image display -- would seem to indicate that gaming, entertainment, and mobile devices are at the top of Microsoft’s priority list.

The HTML5Test is a very precise metric, but it’s important to remember that it’s built to assess whether the browsers implement the newest and most experimental features accepted by the HTML5 committees. It doesn’t give out points for doing a good job of laying out tables or rendering pages quickly. It’s a big checklist of features, not a measure of browser quality.

The results also provide a good indication of the corporate priorities. Chrome, not surprisingly, offers great support for the kind of full-featured, applicationlike websites that Google delivers. This also makes it simpler to provide more features on Google's hardware platform, the Chromebook. The company gains little from the part of the stack called an “operating system,” so it’s not surprising that it wants the part known as the “browser” to be more capable.

Apple, for its part, doesn't seem as interested in supporting gamelike behavior in the browser, perhaps because it makes so much money from the App Store and doesn't want to undermine it.

Many of the features where the browsers are at odds don't matter as much to developers. If you're building a Web application with plenty of DOM elements that generate AJAX calls and react to the server’s response, well, all of the browsers do a good job of supporting this. They all offer the same core features, and it doesn't matter much whether they implement the latest form element.

In this sense, the HTML5Test score speaks more about the future than the present. While the HTML 5.0 standard is now fixed and the committee has turned its attention to the next set of ideas, the browser makers need to finish implementing the standard. As they do, more and more of the Web developers will see that the new features are available and ready for use. Only then will the users start to see the advantages.

The good news is that the browser makers are converging quickly and many of the features have been embraced widely enough for Web developers to start using them. The committee has done its work. Now it's our turn.

http://www.infoworld.com/article/2915570/web-browsers/html5-shoot-out-chrome-safari-firefox-opera-internet-explorer.html?nsdr=true