It took a while, but today I have finally released a new version of html5test.com. This should have happened much sooner, but unfortunately some very serious health issues in my family meant I was not able to spend enough time to make that happen. But fortunately we can now put that behind us, and over the last month I’ve made a large number of improvements.
New specifications
First of all, there are a large number of new specifications, like Web Payments, Web Authentication, Credential Management, WebVR, Fetch, Web Animation, the new Shadow DOM spec, ES6 and ES7 enhancements, and much much more. A complete list can be found on Github. I’ve also removed a number of experimental features that failed to gain traction and have been removed from the specifications.
The total number of points stay the same, which means existing features are now worth less points. So browsers tend to score less points on the new version of HTML5test than the previous version and need to implement new features to get to the maximum of 555 points.
Prefixes
A notable change in this version is that prefixed implementation will be worth less points than their non-prefixed counterparts. The idea behind this is that prefixes make our lives more difficult than it should be. Almost every browser vendor no longer uses prefixes for new features and places them behind a flag instead. That’s great! But now lets get rid of all those old prefixed versions.
New features
I’ve also added a number of new features that makes retrieving data from HTML5test much easier, like showing diffs of features on the browser comparison page and searching for browsers of features if you want to add one to a comparison.
Another great new feature is the ability to see a timeline for a browser. You can see the differences between each version and when features were added.
Easier to maintain
And finally the new version of HTML5test is easier to maintain.
There is an automated system that uses BrowserStack to generate verified test results for most desktop browsers. This cuts the time needed to prepare an update from weeks to just a couple of hours. Previously I needed to collect data before launching the website. That meant the old website already ran the new version in the background for a few weeks until there was enough data say something meaningful. And discovering a bug halfway, meant starting over completely and throwing away all that old data.
For the new website I’ve also created a system for maintaining the data on Github. That means everybody could file a pull request for a new browser, or a new version of a browser.