HTML5test 2 Comments

Upcoming changes

It’s has been a busy time for me at HTML5test HQ, but we’re not done yet! I’ve got a lot of changes coming to the site in the next couple of weeks. Two weeks ago, I already unveiled the next version of HTML5test and at the time I was hoping to be able to launch it this week. But it will take just a little while longer before it will replace the current version. There are still some outstanding issues we are looking into and I also expect to tweak the scoring a little bit too before we launch.

As you can see, the next version of the site not only introduces new tests, but the site has also been completely redesigned. I hope you like the new lighter and flatter design.

The blog has already been moved to the new design and once the next version of the site is ready, so will the rest of the site. One other part of the site that already uses the new design is the home of the HTML5test Device Lab which will open tomorrow.

HTML5test

Using QR-codes with HTML5test

One new features of the upcoming HTML5test redesign is the use of QR codes. By scanning the QR code of a test, you can view the results on another device and are no longer limited to the small screen of the phone.

Browsers

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 →

HTML5test

Html5test now also works on S60 3.x… Yeah…

I managed to get my hands on a Nokia N95 and N96 yesterday and I quickly found out that they had some problem running HTML5test. It turned out that HTML5test never worked on older versions of S60 due to a bug in the S60 browser. It was simple enough to fix so I can now officially announce full support for S60 3.x. Okay not exactly earth shattering news, but it is still nice to fix these little bugs.

The score was about what I expected for four year old phones: 14 points and no bonus points.

Device Lab

Thanks!

I’d like to thank everybody who donated in the last couple of weeks. Last week we were able to add three new devices to our testing lab: a Nokia 500 running Symbian S60, a Nokia Asha 203 running S40 and a Nokia Lumia 610 running Windows Phone 7.5. With these additions we hope to be able to update the HTML5 compatibility tables more quickly and solve problems with running html5test.com on these platforms before actually releasing new versions of the test.

We are still actively looking for new devices running Windows Phone 8 and Android 4.2, but also older devices running older versions of Android 1.6, iOS 3 or 4, Maemo, Meego and Windows Mobile 6. If you have a new or used device you want to donate to our lab, please contact me below in the comments, on Github or Twitter.

Any device or donation will help us improve HTML5test.com.

Thanks in advance!

HTML5test

A new version of HTML5test.com

A couple of days ago html5test.com was updated to version 4.0. The update brought a number of bugfixes and a couple of new tests. The maximum score is still 500 points, but the number of points awarded by each tests were modified in certain cases. The most notable changes are the getUserMedia method which was worth 20 points and now only 10 and IndexedDB which was worth 10 points and now 15.

In a couple of cases I decided to stop awarding points altogether. The HTML5 doctype isn’t worth any points anymore because every browser supports this. The filesystem API which failed to gain traction as a standard and isn’t implemented besides by some Webkit based browsers also loses its poins.

And finally ‘drag and drop’ is no longer worth any points because I figured it could only properly be implemented on systems with a mouse. Given that touch based devices are now ubiquitous, it seemed unfair that they could not get the maximum number of points. Of course it didn’t take long to prove me wrong, because Opera Mobile 12.10 does support drag and drop. I still need to take a proper look at their implementation, but I’ll happily restore points for drag and drop in the next update if that means other vendors are also going to implement it for their mobile browsers.

New tests added in version 4 are Mutation Observer, Pointerlock and Opus audio support.

Browsers

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 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 →