HTML5test has been updated!

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.

The problems with feature detection

By now everybody should already know this. You should not rely on browser detection. User-agent sniffing is evil. Use feature detection instead. Sound and solid advice. At least until you start looking at some of the more unusual browsers.

Earlier this summer I did extensive research on smart TV and console browsers. It showed me that these browsers are a lot like mobile browsers 10 years ago — before Chrome and Safari. Everybody is trying, but nobody really knows what is right. More on that at a later time.

One important lesson I learned was that we as developers make a lot of assumptions.

Continue reading

A eulogy for Internet Explorer, 1995 — 2015

This week Microsoft is going to release Windows 10. For us web developers this is important, because for the first time since Windows 95 SR1, Internet Explorer will no longer be the default browser.

I thought now would be an appropriate time to say goodbye to Internet Explorer. During a NLHTML5 meetup last Thursday I looked back at the early days of Internet Explorer and explored an unexpected premise: Internet Explorer really was a good browser…

Slides are available on Speakerdeck.

The Android Webview

During PhoneGap Day EU in Amsterdam I did a talk about the problems surrounding the Android WebView. I have about 75 different Android devices in my device lab and I explain why. I talk about the differences between WebViews on phones from different manufacturers and explain why our problems haven’t been completely solved now that Android comes with the Chromium based WebView.

Please, be kind. It was my first public speaking gig. But I loved it so much that I have given a number of other talks since. If you’re Dutch (or perhaps located in the north of Germany) my next speaking appearance is scheduled for August 20th in Zuidlaren at a NLHTML5 meetup.

Slides are available on Speakerdeck.

Safari and IE

Two weeks ago I attended EdgeConf in London. If there is just one thing you are allowed to say about EdgeConf I would say that interesting things always happen during EdgeConf. It was just a year ago, during the previous EdgeConf in London that Yoav Weiss launched his crowdfunding campaign for implementing the picture element. When you put that many smart people in one room the level of the discussions is just astounding.

The most interesting thing of this EdgeConf however didn’t happen during the conference itself, but a few days after. Nolan Lawson published the now famous Safari is the new IE article on his blog and all hell broke loose. Even Don Melton – the godfather of Safari – called him out. The only thing more impressive would be Steve Jobs coming back from the dead and punching Nolan in the face.

It certainly didn’t come as a surprise to me. This subject came up in one way or another in just about every panel and every conversation I had during EdgeConf. In fact I think this sentiment is pervasive among professional web developers who have become frustrated with the apparent lack of innovation coming from Safari. It certainly wasn’t the first time I was asked the question whether or not Safari was becoming the new IE6.

Sure, the title was a bit link-baity and Nolan made a number of errors in his article – which he quickly corrected in his Safari is the new IE 2: Revenge of the Linkbait article. But the perception among web developers is that right now Safari is no longer a front runner. Nolan was just the one who wrote it down first.

The comparison to IE may be deserved – it may not be. In any case the fact that there is such a sentiment is sign of an underlying problem.

Continue reading

The Android Browser

Yesterday I posted this slideshow on Twitter and got many comments and questions. I’d like to address some of them below.

First of all it never was my intention make fun of Android. This is a real problem for web developers and one that unfortunately cannot be fixed on the short term. In my opinion the problem exists because the WebKit based Webview was not developed as quickly as the webstandards evolved, which I though was always a bit peculiar because Google is a company that embodies the web.

Part of the problem is that the Webview is updated when the OS is updated. And unfortunately not every device gets updates. Even worse, even new devices are being sold with old versions of the OS, including an old versions of the Webview. There are still devices being sold with Android 2.3 today.

The devices makers saw their browsers fall behind with standards support and needed to do something. Unfortunately they did this by themselves and did not cooperate with Google to improve the Webview for everybody.

The irony is that Google also saw this problem and tried to fix it with the new Chromium based Webview. Unfortunately this fix is just for Android 4.4 and up and not earlier versions. Updates to the Webview still require an update of the whole OS – which means that we will many different versions for years to come.

If only it could be updated through the Play Store, just like Google Play Services. Google could even bring the Webview to older versions of Android. But for now we still have to deal with all of the different browser and Webviews.

I create web apps for a living and have shipped many Android apps that use the Webview or are expected to be compatible with “the” Android browser. I regularly receive bug reports that a particular features does not work. And when I investigate the bug it happens quite often that I cannot reproduce it. Even when I ask the customer which device they use and use one from the same manufacturer I cannot reproduce it. When I use the exact same device I cannot reproduce it. Turns out the problem only exists on one particular device running one particular version of Android. The same version of Android on another device works perfectly and the same device with a different version of Android also works perfectly.

I test my apps on about 30 different Android phones before I ship them and it has happened that I simply had to accept that one particular phone has a problem that will not be fixed. Simply because the workaround broke another phone. And that workaround broke another one. And another one.

That is definitely a problem.
You cannot expect web developers to own all devices. And even worse, you’ll actually need multiple versions of the same device, because some bugs only exist in one specific version of Android.

It does point out the importance of Open Device Labs – and the importance for ODLs to have as many Android devices as possible.

Thanks everybody for the comments and retweets!

Coming soon: New scores for the Xbox One

Last week Microsoft released the Xbox One in certain countries and fortunately one of the first sites that people are going to check out is HTML5test. So I was able to quickly add the test results for Internet Explorer 10 on the Xbox One.

I also quickly discovered a discrepancy between the documentation that Microsoft released and the test results I was seeing. It looked like Geolocation and the File API were available on the Xbox One, but the documentation specifically said they were not. With the help of Anna Debenham I was able to quickly pin point the problems and discovered some bugs in the browser and errors in the documentation.

In case of Geolocation the documentation was right that it is not supported, but due to a bug in the browser it is impossible to determine this using feature detection. The basic implementation is still there, it just does not give any location and even worse not even an error. A more detailed write up of this bug can be found here: Geolocation on the Xbox.

The problem with File API was with the documentation: it is supported and fully functional. But in practice it is of limited use, because input fields of the file type are not working. If you click on the field nothing happens. You simply can’t select any file. But the FileList interface is functional, however because you can’t select any files, the list of files it is always empty. That that is not the only use of the File API: you can still load binary files using XMLHttpRequest and use Blob and FileReader to get the contents of the file.

Unfortunately these bugs also mean that the score needs to be adjusted – and in this case downwards. The new results will show it does not support Geolocation and also no support for input type=file. These changes will go live in a couple of hours, together with some other fixes we are still working on.

Photo by Steve Petrucelli

The new HTML5test is here!

After months of preparations I am very proud to be able to launch the new HTML5test. Personally I think it is the biggest improvement yet. Not only do we have new and improved tests, but it’s a completely new, lighter and flatter design with many new features.

Some of the more notable changes are:

  • We’ve got a new maximum score of 555 points. And the bonus points are gone.
  • Many new tests and improvements for already existing specifications, but also for new specs.
  • Click on a test result to get more information about the test. Find out how many points the test is worth, the status of the specification and links to the specification and other sites such as WebPlatform.org
  • Save the results, so you can view them at a later time, or on another device. Use a QR code to immediately view the results of a device with a small screen on your tablet. Use html5te.st/qr to run the test and show just the QR code.
  • Give feedback and correct the browser identification so we can improve WhichBrowser – our browser identification library
  • A handy browser overview table which shows the scores for the current versions of the major browsers, but also the upcoming and older versions.
  • See a list of the 100 most recent test results and search through our database for results of specific browsers.
  • Compare up to five browsers at the same time.

Of course there are many more changes and over the next week I will explain some of the new features in more detail. The number of confirmed results are also still limited, because we just started collecting data a couple of days ago. This too will grow over the coming days and weeks. There is still plenty of work to be done and I am already working on some new ideas. But first take a look around on the new site, I hope you like it as much as I do!

The HTML5test Device Lab: We’re open!

Ever since I started collecting and reporting HTML5test scores I noticed the enormous diversity of browsers on mobile. There are not just a handful of popular browsers, but literally dozens. And even worse, you can run the same browser on the same OS on two different devices, but still get significantly different test scores.

On desktop, testing a website is pretty easy. You just install a couple of different browsers and a couple of virtual machines running some old versions of Internet Explorer and you’re basically done.

On mobile it is a bit more complicated. You’ll need devices. And devices cost money. If you’re a big company you can probably afford to build your own device lab, but for an independent designer that can be very costly. And even if you can afford to buy all those devices, not many companies actually realize this is a problem. So what happens is that designers usually check websites on their own phone and maybe on the phone of a friend and be done with it. And that is why we have some many ‘mobile’ sites that only work well on iPhones.

One of the solutions to this problem is getting devices in the hands of developers.

The HTML5test Device Lab

Little over a year ago I read an article on Smashing Magazine about Jeremy Keith opening up his own device lab to other developers and ever since I’ve been thinking about doing something similar myself. When the subject of the Open Device Lab movement was brought up during PhoneGap Day last september I decided to step up and do the same.

As of today I am going to be running an Open Device Lab: the HTML5test Device Lab. If you want to test your site on a large range of different mobile devices, all you have to do is make an appointment and visit my lab. The coffee and Wi-Fi are free!

Over the last couple of years I managed to collect a substantial number of devices for my day job and for testing the HTML5test site itself. A couple of weeks ago I reached out to a number of companies with my idea and I’ve gotten some very good responses. Last week BlackBerry sent me some devices I did not have yet and I’ve gotten some pledges and support from other companies too. Want to help out? Please read our wish listThanks!

Right now the lab has 71 devices available for testing. If you want to know how your website looks on an ancient BlackBerry, on a Nokia N9 or a Firefox OS device – we’ve got them. Need to test on iOS? No problem, we’ve got devices running iOS 2.2 to 7.0 and you’re welcome to use them.

Other Open Device Labs

The HTML5test Device Lab isn’t the only one. There are more than 70 Open Device Labs across 22 countries. Head on over to OpenDeviceLab.com for more information and locate the one closest to you.

Device Wish List

I’d like to think we already have an impressive amount of devices available for testing in the HTML5test Device Lab, but there are some devices we have not yet been able to find. Below is our wish list:

  • Nokia Asha 501 – thank you Nokia
  • Jolla Sailfish
  • Sony Playstation Portable – thank you Arjan Eising
  • Sony Playstation Vita
  • Sony Playstation 3 and 4
  • Sony eReader
  • Kindle Touch
  • A device running BlackBerry OS 5
  • A Palm Pre 2 running webOS 2
  • A device running Tizen – thank you Samsung
  • A mid-range or high-end device running Windows Phone 7 – thank you Nokia
  • A mid-range or high-end device running Windows Phone 8 – thank you Nokia
  • A Nexus S, Nexus 4, Nexus 5, Nexus 7 2013 and Nexus 10 – thank you Google and KitKat
  • Xbox 360 and Xbox One
  • An iPad 1 or iPad 2, an iPad mini with Retina
  • Any device that runs some version of Android
  • And basically any other device running a web browser

If you can help us acquire any of these devices, please contact me. Maybe you have some old phone lying around in a drawer somewhere, or you work for a manufacturer that may be willing to sponsor us? And otherwise, please consider donating something using Paypal, so we can buy our own devices or maybe a nice coffee maker for the lab.

We’re happy with any device you have and even if you have devices we already have, we’ll make sure they will find a new home at any of the other Open Device Labs.