The HTML5 test – how well does your browser support HTML5?


The HTML5 specification isn't finished yet!

True. Whenever the specification is updated, we also make sure the test is updated. If features are removed from the specification we remove them from our tests and new tests are created for additions to the specification.

Why do you include specifications that are not part of HTML5?

HTML5 means different things to different people. You could argue that HTML5 only includes features that are defined in the W3C HTML5 specification. Or you could argue that it includes every specification, draft or experimental feature that is added to browsers in the last couple of years. We decided to take the middle ground and split the test into three parts: the official HTML5 specification, specifications that are related to HTML5 and some experimental new features that are extensions of HTML5.

Many of the related specifications were at one time part of HTML5. During the development of the specification they were moved to separate specifications.

But WebGL isn't even a W3C specification!

The W3C isn't the only organization that creates open specifications for the web. The WebGL specification is published by Kronos, the same group that is also responsible for OpenGL. WebGL is related to HTML5 though and listed as one of the HTML5 technologies on the W3C HTML5 logo page. The W3C HTML5 specification allows the canvas element to be extended by new drawing methods and WebGL is one of them.

Why do you test for Chrome's Web Audio API, but not Mozilla's Audio Data API?

The Web Audio API is an official proposal submitted to the W3C Audio Working Group and may end up being an official audio specification. The Audio Data API has been deprecated by Mozilla and may not be supported in future releases.

Why do you test for Web SQL?

The Web SQL specification has been deprecated and replaced by the IndexedDB specification. It is however still commonly used on mobile phones and at least three vendors have shipped desktop browsers supporting Web SQL. We've decided to include this specification, but make it a special case. Web SQL is worth 5 points, but only if IndexedDB is not supported. IndexedDB is worth 10 points. If a browser supports both, only 10 points are awarded. This way browsers that only included IndexedDB are not penalized, but browsers that only support Web SQL do get some points.


What is the maximum number of points you can score?

If a browser passes all tests it would receive the maximum score of 500 points and 15 bonus points. Previous versions of the HTML5test had less tests and therefore also a lower maximum score, such as 160, 300, 450 and 475 points. In the future we will probably add even more tests which would also mean we will raise the maximum number of points.

What are bonus points?

HTML5 defines an audio and video element, which allows the browser to play media files. The HTML5 specification does not define a required codec though. So for each common codec that is supported we award bonus points. Similarly we give bonus points for SVG and MathML support. Bonus points are counted separately and do not count towards the maximum of 500 points.

The scoring seems arbitrary, who decides how many points are awarded?

We decided to award points for each feature depending on how important that feature is for web developers and how difficult it is to implement that feature. A small and simple feature would be worth less points than a large and complicated feature. We think this is the most honest way to grade browsers, because otherwise a browser that only supports the small and simple features would score as high or higher than a browser that went the extra mile and decided to tackle the big features. But in the end it is based on personal preference, but I doubt there is a truly objective alternative.


Can my browser be included on the 'other browser' and 'compare' pages?

We would love to add new browsers, but not all browsers are eligible. First of all we only accept browsers that are publicly available, either in beta form or a final release. We do not accept scores for internal development builds. Secondly we only accept browsers that are available in English. We want to check browsers before including them and unfortunately we do not speak Chinese, Japanese, Korean or Russian. And finally we only accept browsers which have a unique score. There are many browsers that are forks or modified versions of Chromium or Firefox. Similarly there are many browser that embed Internet Explorer or Webkit as provided by the operating system. These browser do not qualify. For comparisons, simply choose the original browser on which the browser was based instead.

We retain the right to make exceptions to any of the rules above and to remove or refuse any browser we deem necessary.

What happens when a browser cheats?

We cannot distinguish between a browser that supports a particular feature and a browser that lies about supporting that feature. The only way do deal with these situations it to manually confirm the test results. And if a browser is found to be overly confidant about claiming support for certain features we can put that browser on a blacklist. That means that that even though the browser claims to support a particular feature, we ignore what the browser says and do not give any points. This is usually just a temporary problem and once the browser has been fixed we will remove the new version from the blacklist.

Claiming to support a feature which isn't working is not just causing problems for the reliability of the test results, but there are other real-world problems. For example if you claim to support WebGL, a website make decide to serve WebGL content. If your browser does not support WebGL, the website may fail in an uncontrollable way. If you correctly denied support for WebGL, the website may have served alternative content that would work in your browser. If you claim to support features that you don't, you are breaking the web.

If we find that a browser is structurally lying about which features they support - deliberately or not - we will usually give a warning to the developers of the browser and if the problem hasn't been fixed in the next version we will remove the browser from the 'other browser' and 'compare' pages and/or give other penalties.


Why are you using browser sniffing?

Unfortunately, in two very specific cases we are forced to use browser sniffing. The first case is contentEditable which was not supported on many older mobile devices. Yet almost all mobile browsers claim to support contentEditable. Fortunately modern mobile devices are starting to support contentEditable, but this left us with a problem. We cannot reliably detect if a browser has proper support. The only way around this is to use a whitelist of mobile browsers that do support this feature, otherwise you risk awarding points to mobile browsers that they do not deserve. The second case is drag and drop, which is also not supported on mobile phones and tablets.

Please open a new issue on Github when you believe a browser should be included on the whitelist.

How are you detecting when a field is using a custom user interface

The HTML5 specification introduces a number of new field types. Instead of just a plain input field there are now color pickers, date pickers, number fields and sliders. The specification doesn't define what the user interface of these new fields are supposed to look like. Rightly so, because the user interface might depend on the device that is used. It does make detecting a bit problematic. What we do is look at the field itself and how the field affects its surroundings. We start by creating a plain text field and wrap it with a block. We measure the rendered style of the wrapper and the field itself. We then create a field of a specific type and measure the wrapper and the field again. If the rendered style of the wrapper has changed, this should mean the field itself is rendered in such a way that it affects its surroundings in a certain way. That does not mean it has a fully functioning custom user interface, but this is the best we can do. Similarly we compare the rendered style of the field itself. If either one of these is different from the plain text field, we assume the field has a custom user interface.


What kind of data is collected from visitors?

Each time you visit this website your score and test results are logged on our servers. We also store the user agent of your browser which contains information about the browser, operating system and device you are using. The collected information is solely used to generated anonymized reports about HTML5 support in browsers and improve the quality of our software.

We do not store cookies in your browser, but we do use several external components that do, including: Google Analytics, BuySellAds, Facebook, Twitter and Google+.