HTML 5 melee: Chrome, Safari, Firefox, IE and Opera each show their strengths

Chrome and Opera are better at supporting the latest web features, but the differences between browsers may not be as significant as they seem.

It has been four years since "HTML 5" appeared as a hot word in front of us. Do we really have reason to trust the powerful strength of JavaScript on the browser platform? Time flies, and year after year has passed quietly while we type on the keyboard.

HTML 5 is back in the spotlight now, mainly because the W3C committee has finally decided that it is time to stop pushing the HTML 5.0 specification and move on to HTML 5.1. This marks a historic moment, as the HTML 4 document was finalized back in 1997. While the committee was messing around, more than a decade has passed.

So what is the real world doing in the meantime? It certainly isn't waiting for the final draft to be released. Websites using the HTML 5 standard are everywhere. Browser solutions are now able to support many HTML 5 features, and they are getting better with each upgrade. At present, the difference between websites and native applications is not as prominent as it used to be, and complex and interactive websites are closer to native applications than ever before.

Now is the perfect time to revisit the browsers and see how well they support the HTML 5 standards committee's recommendations. New form elements, tags, attributes, and background features will not contribute anything to the real world if they are only theoretical. Browsers are the platform on which the committee's dreams come true, and our experience when writing code or visiting a website is the end of the dream - reality.

The good news is that each browser solution has introduced standard mechanisms into itself. In the automatic scoring table provided by HTML5Test.com, although there are still some differences between different browsers, they are still very close to each other and not far from perfection.

It is worth noting that the HTML5Test website aggregates all standards compliance items into a single number (from 0 to 555) to ensure that everyone is easy to read, easy to compare, and not distracted by a lot of details. These automated tests only detect whether a specific feature is supported by creating a partial DOM object. It cannot tell you whether the feature is implemented correctly, elegantly, or without causing any serious bugs. What's worse, everyone may question the score numbers of specific (or all) features.

A single number is certainly eye-catching, but to really get the answer, we have to dig a little deeper. Spending a few minutes analyzing this list, we can see the priorities of each development team when writing the browser. Some new features are not currently supported, obviously because the development team believes that their importance is limited. Google's Chrome browser supports custom schedule handling, but not custom content handling. Firefox does not support some new input field types such as time, month, or week. Every platform has more or less of these problems, and few of them can completely leave the other competitors behind in terms of current user experience. But we can only assert that now, I believe that compliance will become a solid foundation for the development of browsers in the future.

Browser politics

These differences often stem from deep political and economic reasons 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. But they all at least support H.264. These codecs are not officially part of HTML 5, but they have become a core foundation of the modern Web, so these features are more important to many Web developers.

Some of the items in the test are not even part of the official HTML 5 draft, because they are just other things that may have been stripped out of the official HTML 5 specification. Web developers, server programmers, and especially users now often find it difficult to distinguish what belongs to HTML 5 and what is new or better. Very attractive features such as Web Storage and Web Workers are not part of the HTML 5 specification, but they are still deeply influenced by the W3C. They may even have a more considerable influence.

The core of the HTML 5 specification completes the design of a series of additional new tags designed to express role types through the text information within the tag. They will specify a variety of categories, including chapters, narration, footers, and headers. Back in the day, we would use tags to mark them and specify their fonts, such as <h3>. Now HTML 5 will use their roles to mark them, so that they can have their own CSS styles, and the browser will layout the elements accordingly. In short, sharing text and images from the arrangement and displaying them on the page continues to be a major trend.

There is a lot of debate behind these changes, but their importance will only affect those who care about how the web page looks. For example, some technicians want to completely eliminate tables from layouts, while others simply want to disable them. We can often intuitively understand how the table tag is actually used by reading the attributes. Adding borders or giving a column a header means that it probably contains tabular data. Leaving borders off means that it probably belongs to a layout.

Besides offending the self-appointed web purists, using these elements the "wrong way" can have other consequences. Even with clever reuse of the tags (like tables), other systems can still be affected. The HTML 5 development team is currently investing more resources in making web content more accessible to the blind and disabled. Using table tags for anything other than tables of data can cause confusion for screen readers and other mechanisms. Now, new attribute classes have emerged - starting with the acronym ARIA (Accessible Rich Internet Applications) - that aim to provide alternative solutions for describing the content of data. In general, separating the message from the display content can help make this easier.

From Web Pages to Web Applications

One of the good things about recent developments is that static web pages are starting to transform into fully dynamic applications. The Web Storage, WebSockets, and Web Workers specifications have evolved as browser builders have learned what works and what doesn't. These specifications have helped programmers create fully functional software suites, most notably Google Docs. Storing data locally, allowing background communication, and threading has become a fundamental way to handle special data sets.

These changes are largely focused on details that developers don't even notice. For example, the Web Workers specification now explicitly specifies that workers can independently create their own execution environments in parallel. This is only for time-critical workers, so most basic workers will not be affected at all.

There are dozens of similar small changes in Web Storage, and of course the debates about them are endless. Some people think that forcing multiple threads to use mutexes to access Web Storage will bring a lot of extra resource overhead. But others firmly believe that the importance of data integrity cannot be ignored because people often browse the same website in multiple tabs.

All of the above are discussions that have taken place in the W3C in actual work, but programmers may not care about them. If users only need to store thousands of items, then the performance should be fine, and the many details in such specifications will not affect them. But from the perspective of browser developers, all of this must be included in the agenda.

Because many of these details are still unknown, browser developers often make different choices. The Web Storage specification states that browsers should "limit the maximum amount of space used by the storage area" and recommends 5MB as a good limit. Browsers and users will be significantly affected by these details in the future. At the same time, their implementation will also vary.

Perhaps the most contentious issue is in the area of ​​media handling. Web browsers are becoming the dominant way to access video, and the HTML specification team is clearly determined to take over users' living rooms. The Encrypted Media Extensions specification includes a complex set of video source and key handling mechanisms, so that only browsers with the corresponding permission can display the images. Chrome, Opera, and Safari all support the above media extensions, while Firefox and IE do not.

There's also a lot of work going on to create moving parts. A new proposal, Web Video Text Tracks, wants to standardize how to synchronize video content with the rest of a website. It's primarily aimed at subtitles, but we'll see it used as a basis for many more applications. I can see text, graphics, and images flying around, and all browsers will support it.

Web Features

Although many people will naturally think that the HTML 5 specification has finally reached a point of finality, it is better to view it as a new starting point for the next stage of development. Some people are still not convinced that the 5.0 specification does not have enough "implementation experience". In other words, the features are not mature enough to help users understand clearly what features can be implemented and what cannot be implemented.

As part of the current draft, you can read the HTML 5.1 specification here, which includes features such as the accesskey attribute for adding keyboard actions as the equivalent of mouse clicks. All browsers are improving their support for the HTML Editing API, which aims to make every web page editable and turn the entire web into a massive Wikipedia.

More large-scale changes and adjustments may also be coming, as some people want HTML to be more like XML. This is not just about encouraging people to close all those open tags - this has caused some developers to encounter bugs and has been noticed by the parser team. Some contributors to the HTML 5 specification are discussing adding "hackability" to the next version. Specifically, they want this specification to allow people to define their own tags and use their own mechanisms to handle these tags after the parsing work is completed.

This greatly increases the potential efficiency of the markup mechanism. Anyone who has clicked the "view source" button recently will have seen that most HTML files today are 50% to 60% made up of <div> and <span> tags, each with a variety of classes attached to them. Debugging CSS style files is becoming increasingly difficult. One way to solve this problem is to use a fully extensible tag system.

All these resolutions will become a reality in the future and have a huge impact. HTML 5.0 is already a milestone, but it is just one of the milestones in the evolution of standards for how we express information and interact with it.

We've talked a lot about generational change - now let's get down to the browser battle.

#p#

Browser No. 1: Google Chrome

Chrome's score in HTML5Text is unmatched - Chrome 42 scored 523 points - which once again proves that Google is actively promoting the establishment of the HTML 5 specification and creating one of the top browser solutions based on it. The programming team only needs to mark the few dialog boxes and record the test scores directly.

The omissions are gathered in a distributed manner, but we find it difficult to summarize them in a simple sentence. You will find a scattering of missing markup elements and unimplemented graphics methods. All in all, Chrome is a fantastic choice for any developer who wants to build user interfaces with a comprehensive set of tools. If you want to use all new markup or form elements, then Chrome is your best choice. There are few obvious shortcomings in Chrome in this review.

But from a deeper perspective, Chrome still has some serious omissions. There are no hooks into the JavaScript engine to trigger individual events when scripts start and stop executing. In addition, we can't find an easy way to use scope to control the specific impact of CSS styles on the page. In addition, you can't register your code as a function to use it to handle all specific MIME types or URL schemes - this is the custom content handling function we mentioned earlier.

By the way, all three of these are well implemented in Firefox. It seems that the development team at Google has missed these points.

Another possible source of problems is the support of codecs and media formats. Take MPEG-4, for example, which works fine with iOS browsers, but not with Chrome. Both Apple and Microsoft support audio track selection, and Apple also supports video track selection, but Chrome does not allow users to complete these advanced operations.

Overall, Chrome is an ideal choice for users who want to try out the additional features of the new standard.

Browser No. 2: Opera

As of this writing, Opera ranks second in HTML5Test, though it only scores four items, with Opera 29 scoring 519. Like Chrome, Opera offers extensive support for new markup and form elements, making it a good choice for users who want to experiment, just like Chrome.

But Opera also has something in common with Chrome, which is that it skips custom content handling, scoped style elements, and script execution events, though to be fair, none of the other browsers except Firefox pays attention to these.

The biggest differences are in the codec space, where Opera doesn't support MPEG-4 and H.264 video formats. Even more annoying is the lack of support for AAC and MP3, two formats that are almost everywhere on the web. So getting your multimedia content to work on Opera is no easy task. Opera is almost certainly under the yoke of patent licensing fees, so the company may simply ignore the technologies that are too expensive to license. Opera saves some face by supporting Ogg Vorbis, Ogg Theora, and WebM, even if it can't be directly compatible.

Like IE and Chrome, Opera is also at the forefront of the times in the field of "pointer events" - an active exploration of differentiated input modes. The so-called "pointer events" are designed to make it easier for browsers to support mice and touch screens, and to give pointers richer capabilities by providing programmers with a single, more concise event model to arrange related content.

Overall, Opera is an impressive browser that doesn't get the attention it deserves, but it's second only to Chrome in terms of the breadth of support for modern web features.

Browser No. 3: Mozilla Firefox

From a numerical perspective, Firefox seems to be slightly behind the first two leaders. Its Firefox 37 scored 449 points in HTML5Test, but this is actually largely affected by the performance pressure brought by the test when testing various functions. Firefox browser pushes a lot of points in the projects where it lacks, and does not score very high in the projects where it is relatively leading.

For example, most of the points lost are because Firefox doesn't implement most new input fields and interactive elements. If you want to simply add a form element to collect data or time values, Firefox will not be able to do it. Firefox lost 26 points in terms of missing items, but it's not clear whether programmers are really affected by these problems. Firefox also provides a rich JavaScript library for receiving time data, and its design concept incorporates cross-browser compatibility considerations. Most of them have a prominent modern design and are more beautiful than other common tools. Therefore, most programmers will choose these library resources instead of directly using the built-in support mechanism.

Bottom of the form

In those categories where Firefox was ahead, the scores weren't enough to give it a significant advantage. Triggering events when scripts are about to execute is important for handling workloads, but the ability to run those script execution events gave Firefox a measly 1 point. Adding scope to stylesheets is critical for integrating multiple stylesheets, but the testers at HTML5Text gave it only 2 points.

Firefox didn't win any top marks for implementing microdata markup, which are additional tags that make it easier for browsers to identify and annotate certain common types of data from web pages. Since the W3C and all other browsers have rejected microdata, only Firefox has supported it.

In terms of codecs, Firefox has a wide range of support, but only avoids MPEG-4, which puts it in the same league as Chrome and Opera. Firefox supports Ogg, WebM and H.264, which alone is more than enough.

Do these differences matter? Ultimately, the answer depends on what you need the different features for. If you love and need all the new form elements, then Firefox is not the best choice for you and your project. But in most cases, Firefox provides the same level of support as other high-scoring browsers - as long as you don't care about those new time input form fields.

Browser No. 4: Apple Safari

In the HTML5Test test, Safari 8 scored 396 points - but here we should remind everyone that the gap in actual use is not as exaggerated as the score looks. Similar to Firefox, Safari browser also deducted a lot of points due to the inability to implement all forms and markup elements. Safari does not provide the option of using input fields to collect time or color, nor does it support various standard menu elements.

Game developers may be more dissatisfied with Safari, however. Safari does not support tracking of the device's location or running state, nor can it be controlled by game controllers or more common pointer events. If you plan to develop applications for the Safari browser, the best way is to stick to traditional content and try to avoid using elements that are too interactive. That's right, leave it to the App Store.

In terms of codecs, Apple has chosen a completely different path from Chrome and Firefox. Safari can display MPEG-4 and H.264 video content, but it blocks WebM and Ogg Theora. The good news is that Safari can control video and audio tracks through JavaScript.

Safari also has some shortcomings in terms of the completeness of other feature sets compared to Chrome, Opera and Firefox. These browsers can support peer-to-peer communication mechanisms through WebRTC, while Apple does not provide such support, which forces many users to continue to stick to IE. In addition, Safari does not support service workers for background processing, custom scheduling or content processing functions, and does not have custom search providers.

We have to admit that we can't ignore so many missing features, but Apple still provides relatively broad support for the HTML 5 standard and brings a lot of very interesting and unique features.

Browser No. 5: Microsoft IE

Microsoft IE version 11, which once had a strong market performance, received the lowest score in HTML5Test - only 348 points - but this should have been expected by everyone. The core idea behind the relevant standard changes has always been to encourage competition, and the monopoly mechanism established by Microsoft with its .Net is exactly the target that the new standard hopes to attack. In short, such a bad result is completely in line with many people's expectations.

IE's points were lost in so many areas throughout the charts that it's hard to pinpoint where it lags behind. In fact, the only area where IE beats other major browsers is in web applications, where it supports custom search providers -- very close to Safari. Other than that, IE has been firmly at the bottom of the list.

While it's fair to say that these low scores give IE a poor rating for implementing various aspects of the HTML 5 standard, they alone are not enough to make a definitive statement about how well IE will run HTML 5 code or perform everyday tasks. A quick look at the results showed that most of the points lost were for missing new features - not basic functionality. For example, IE lost points for not supporting CSS selectors such as "in-range", "out-of-range", and "read-only". IE also lacks support for several new input fields for time handling.

Although it turns out that IE has dozens of missing capabilities for small or additional features, these are not important to me personally. Admittedly, they will cause trouble for some programmers who want to use them, but this is not enough to prevent IE from being a browser product that works well.

But there are some serious oversights. Microsoft has not introduced MPEG-4, Ogg, and WebM video support into IE, and PCM, Ogg, and WebM audio support is missing. Currently, IE can only directly handle MP3 audio, H.264 video, and Flash video, three popular web standards. However, IE allows JavaScript to control audio tracks.

It is worth noting that Microsoft is clearly aware of the importance of standards compliance, so IE has been in a rapid growth process. Although the version number of IE browser is not as high as that of other competitors, it was not long ago that IE 9 only achieved a score of 113 in the HTML5Test test, and now IE 11 has achieved 348 points. In addition, the release of the Spartan project, the new web browser provided in the Windows 10 technical preview, means that its development speed is still accelerating.

The latest version of Spartan (which arrived with Windows build 10061) scored 390 on HTML5Test, better than IE 11 and just behind Safari. The major improvements to IE -- including support for device location, device playback, gamepad control, web audio, digital rights management, media extensions, and responsive graphics -- seem to indicate that gaming, entertainment, and mobile devices are high on Microsoft's to-do list.

HTML5Test is a very accurate set of metrics, but it's important to remember that its purpose is to assess whether a browser can implement the latest and most experimental features accepted by the HTML 5 committee. It does not give high scores for browsers' excellent speed in laying out tables or rendering pages. HTML5Test is just a large-scale feature checker, not a browser quality assessment tool.

The test results given by HTML5Test have also become a priority criterion for enterprises to refer to when choosing a browser. As expected, Chrome has excellent support for websites that are fully functional, application-style, and provided by Google. This also ensures that it can more easily introduce more functions to Google's hardware platform, namely Chromebook. Google, a technology giant, has very limited profit figures in the "operating system" business field, so it is no wonder that they hope to give "browsers" more considerable capabilities and development space.

From Apple's own perspective, it seems that they are not interested in supporting gaming features in their browsers. This may be because they have already made a lot of money from the App Store and there is no need to let the browser disrupt this healthy business trend.

Most of the browser support features that matter to developers in this test won't really matter. If you're going to build a web application with a bunch of DOM elements making AJAX calls and responding to server responses, all of the browsers mentioned above will do the job just fine. They all offer the same core functionality, and whether or not they implement the latest form elements won't matter for that use case.

In this sense, the focus of HTML5Text score is clearly more on the future than the present. Although the HTML 5.0 standard is now fixed and its committee has begun to turn its attention to the next set of specifications, browser developers still need to complete the implementation of this standard. While they are doing so, more and more web developers will see the emergence of such new features and incorporate them into their own developments. Only then will users really feel the benefits of the new standard.

The good news is that browser developers are moving very quickly, and most of the features they provide are sufficient to support the actual needs of Web developers. In short, the HTML 5 committee's work has been completed, and now it's our turn.