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.
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.
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.
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.
This test seems kind of silly because it's testing things that aren't even close to becoming standards. Take Web SQL:
http://dev.w3.org/html5/webdatabase/
The current version this test is based off, was put up this month by Google. Just a few months ago, SQL wasn't even in a draft document.
Personally, I think it's destructive to put tests up on drafts that are so highly volatile. The biggest CSS bug in IE6 was because the initial definition of the box model was ambiguous about measuring width vs padding.
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.
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).
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.
