HTML5test how well does your browser support HTML5?

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 →

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.

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 →

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!

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 →

or why Apple’s browser marketshare is inflated

After implementing a new reporting backend for html5test.com, 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 html5test.com 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 →

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 →