53 comments

[ 3.5 ms ] story [ 64.3 ms ] thread
Chrome 5.0.342.9 beta: 137/160
Chrome 5.0.371.0 dev: 142/160
It'd be more useful to have this list for all browsers, rather than just the one you happen to be using.
Table of overall scores for different browsers: http://rakaz.nl/2010/03/the-html5-test.html
I love the scores posted, I also love that I don't see any above me (Chrome 5.0.371.0) (yet), but I'd like to see a bit of a better breakdown. Anyone know of some info on some of the conflicts, like I'm missing a few in User Interaction, but I don't know who isn't. Or other html5 statistics sites, since the topic is a pretty common trend right now.

Edit: (Like this: http://en.wikipedia.org/wiki/Comparison_of_layout_engines_(H... in case its useful to anyone)

I agree on the fact that there should be some differentiation between current html5 and proposed, (and that this site is hilarious: http://isgeolocationpartofhtml5.com/), as well as some of the downfalls of scoring codec support that the author has mentioned, I think I like the out of 155 idea where chrome can go above it.

WebKit nightly r57408: 137/160
r56990 — 143
How does that work? It went backwards? And WebKit in what browser?
Not sure, but if those are SVN revisions they could be on different branches?
WebKit nightlies: http://nightly.webkit.org/

And they probably enabled or disabled some features, based on what they're working on.

For awhile (or, a few days, at least), Safari release was faster than WebKit nightlies on SunSpider, since they were working on strings in SFX (or something like that. Point I'm making is, release was faster and the slowdown was in the strings test).

Internet Explorer 8: 19/160
Same with the Platform Preview 9.00.7745.6019
Mozilla Firefox 3.6.3: 101/160
(comment deleted)
Latest, ie Gecko/20100410 Minefield/3.7a5pre 20100410 (well almost latest): 102
NCSA Mosaic 2.7b6: None existant
Safari 4.0.5: 115/160
Other OS X alternatives (on OS X 10.5):

Opera 10.10: 38/160

Firefox 3.6.3: 101/160

Chrome 5.0.342: 137/160

Where are WebSockets?
Isn't WebKit the only engine to support them now, and isn't in not formalized yet? But I think KAAZING would make support easily feasible without direct built in support so I'm not too concerned with including it in the score.
(comment deleted)
(comment deleted)
wow, chrome on linux scores 137. Higher than the latest firefox!
Interesting. Chrome 4.1 (stable) on Windows scores 118.
Current chrome-unstable (5.0.371.0dev) on Linux scores 142.
(comment deleted)
Safari on iPod Touch (3.1.3 OS): 113
iPhone is the same, not surprisingly.
(comment deleted)
Same in Safari 4.0.5 on SL
Android (Nexus One): 118
Safari 4.0.5 / OS X 10.6.3/x86 - 120/160.

I believe various configuration settings might affect the score.

Whatever version of Iron that I'm using on Linux: 118.
I don't agree with the video ratings - codec support isn't defined in the HTML5 specification. It's not really fair to give a rating based on unspecified decisions.

There's still a big debate about who's wrong and right, why should this test get involved? Surely some people will just see that Chrome gets 30/30 and think that Firefox/Safari are thus inferior.

OmniWeb 5.10.2 sneaky peek (v622.11 r128512): 113 (not in the rakaz.nl list)
Codec support isn't HTML5 support. Also, since when was MP3 audio/mpeg3 (which is tested)? The test should be for audio/mpeg. I know Chrome supports MP3.
That was an explicit choice: "In some cases the tests go beyond the specification." Given the current battle over codecs right now, I think this is a good choice.
That doesn't change the fact that the correct MIME type of mp3 _IS_ audio/mpeg, not audio/mpeg3. It is a defect to test for audio/mpeg3.
Midori 0.1.9

117/160

w3m and links: Des not run.
This proves HTML5 has a very long ways to go before replacing all 3rd party plugins.
N900 default browser: 55

I'm pretty surprised at that. I expected higher due to it's Firefox roots.

H.264 codec support is NOT part of HTML5.
142/160 Chrome 5.0.371.0 dev on OSX
The tests for "section", "nav", "article", etc. fail in Firefox because it report them as "HTMLUnknownElement" not because they can't be really used and styled like any other element.