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.

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

Thoughts on Blink

Yesterday Google announced they were going to create a new rendering engine based on WebKit. The new engine will be named Blink and it is going to be an integral part of Chromium, their open source browser on which Chrome is based.

Why did they leave WebKit and how is this going to affect Safari and other browsers based on WebKit?

What is WebKit anyway?

Back in 2001 Apple needed a rendering engine for their own web browser. They chose the open-source KHTML and KJS projects and worked in secret to create a fork called WebCore and JavascriptCore. When Steve Jobs announced Safari on stage and told the crowd they chose KHTML almost everybody was surprised. Rumors suggested Apple was going to use Gecko. At the time KHTML hardly looked like a match for Gecko.

Apple made many changes to KHTML, improved standards support and made it faster. Much faster. Even though their forks were open-source, it was developed internally at Apple and once in a while they published a big code dump with all of their changes.
After the announcement there was initially some hope that Apple’s work on WebCore would eventually trickle down to KHTML. But this quickly became more and more difficult. As the two projects started to diverge, patches from WebCore became more and more difficult to integrate into KHTML. This is when people started accusing Apple of abusing the principles of open-source and not giving back to the community.

As a response Apple opened up the development of WebCore and JavascriptCore and released their newly created wrapper around the two: WebKit. The open-source WebKit project was born. Even though KHTML still exists today, WebKit has supplanted it completely.

Continue reading

Everybody wants to be like Safari

or why Apple’s browser marketshare is inflated

The data for this article was collected during spring of 2012. Despite based on older data, the conclusions of this article are still very much valid. So I decided to publish this article as is.

After implementing a new reporting backend for, I noticed something strange. It seemed like there were an unusually high number of visits from browsers that claimed to be Safari but did have scores that were different from my own devices. It looked like there were quite a lot of visits from browsers that were lying about their identity.

Each visit to is logged and is used for generating reports. You can see those reports on the html5test website by going to the “Other browsers” or “Compare” tabs. Creating the reports isn’t fully automatic – I still have to go over the logged data manually, but by using some smart queries I can get the data I want quite easily from the database. The hardest part of writing the new reporting backend wasn’t actually the reporting: it was identifying the name and version of the browser that is used. If you do not accurately recognise the browser, you can’t say anything useful about how well each browser supports HTML5. Properly identifying the source of the recorded score is vital to reliable reports about HTML5 support.

If you ever needed to identify browsers you’ll probably know that every browser has a user agent string that basically tells you the name and version of the browser and rendering engine. Well… kind of. There are many problems you will run into, but for all intents and purposes it is possible to reliably detect the identity of the browser using the user agent string. The script I wrote was pretty good and over the course of a couple of months and a couple of million real world user agent strings it became quite accurate.

Continue reading

Problems with HTML5 video codec detection

In case you haven’t heard yet, Microsoft released a new preview release of Internet Explorer 9 with all kinds of great goodies we have been waiting for, including HTML5 video support. I did notice that this new preview didn’t score any bonus points on the HTML5 test for its video and audio support. This was pretty strange, because it should have scored bonus points for the H.264 codec. The article below is the result of a little investigation about why IE9 doesn’t pass the H.264 codec test and the problems I found in other browsers.
Continue reading