Tuesday, April 13th, 2010

HTML5 Test. Acid for HTML5?

Category: HTML, Standards

<>p>html5test

html5test.com is a site by Niels Leenheer that runs a series of (currently) 160 tests on your browser. The tests are grouped into:

  • Doctype
  • Canvas
  • Video
  • Audio
  • Geolocation
  • Storage
  • Offline Web Applications
  • Workers
  • Section elements
  • Grouping content elements
  • Text-level semantic elements
  • Forms
  • User interaction

This is a good start, but help him out with new areas to test! Having a simple “count” did wonders for Acid in many ways, but suffers from the flaw that every test isn’t equal. Missing a couple of obscure tests isn’t worst than missing a large piece of functionality that is only accounted for in one test for example.

Related Content:

Posted by Dion Almaer at 6:26 am
12 Comments

++++-
4.2 rating from 27 votes

12 Comments »

Comments feed TrackBack URI

Since the idea is to have a simple “count” like in the Acid tests and test HTML5 support, I’m not sure what to think about giving points for specific codecs that are not mandated, let alone required by the HTML5 specification. Especially when such codecs are known to be or become non royalty free.

Comment by p01 — April 13, 2010

The developer’s commented about the video codec issue here: http://github.com/NielsLeenheer/html5test/issues#issue/4

Comment by dave1010 — April 13, 2010

The test shows that Chrome supports datetime type input. But does it? I can’t see any sort of date picker in Chrome.

Comment by BartekG — April 13, 2010

This was also my issue regarding the scoring, that he was counting codec support towards the overall score.

But I liked his response linked above, it’s pragmatic. He gives you 25 points if you support at least 1 codec, and 5 additional points for any extra codec, sort of a bonus.

Comment by atonse — April 13, 2010

Opera Mini on iPhone scores 14 out of 160

Comment by brentashley — April 13, 2010

@BartekG: They mention that they test for existence of a feature not the implementation. I imagine what the test does is assign type “datetime” to input field and then “get” it – AFAIK if you assign a type that the browser doesn’t understand and try to get it it’ll return text (i.e. the default type).

Also, did anyone test the various “beta” builds with this – FF3.7, chromium, etc.?

Anyway, so I ran it on a few browsers, here are some of the results
IE8 – 19, really pathetic but not unexpected (it does though support @font-face if that’s what they used for the score).
Chrome 5 – 137
Firefox 3.6.3 – 101, where it loses in particular are form types (search, url, etc.) and section tags [nav], [article], etc.

native nexus one browser – 118, it has geolocation (unlike chrome) but loses on form inputs and interestingly enough, it supports both audio and video elements but none of the codecs, I’m not sure what that means… what would be the point of video or audio elements if they can’t play any of the files?
(btw, seems to lack @font-face support, again, assuming that’s what’s used for the score font, I didn’t actually check :))

Opera on nexus one (5 beta) – 14, so that’s really pathetic, but also unexpected, I thought opera was always at the head of the bunch. the only thing of significance that it seem to support is canvas, the others are doctype, 2d context and scroll into view (i don’t even know what those last 2 are) and that’s it. It doesn’t even have geolocation, how is that possible for a mobile browser.

safari on ipod touch 2g – 113, it supports all video and audio codecs except for ogg, but no web workers (as oppose to nexus browser), and slightly worse off input type support.

opera on ipod touch 2g – 14, guess shouldn’t have expected it to be different than the nexus version

Comment by iliad — April 13, 2010

Wow, it’s good to see the community speaking more and more about HTML5. I personally blog a lot about HTML5 features, but honestly I wasn’t hoping of so much news around it. Great!

Comment by stoimen — April 13, 2010

Hmm, IE9 platform preview only gets 19 too. I was surprised it didn’t have any Section Elements or any special Form Input types. I expect the real beta later this year will have some of them. Hopefully it will get to at least 55, considering Safari on my iPhone3.0 gets 110.

Comment by GordonStanton — April 14, 2010

Guys, opera mini cannot run javascript, it only displays what it received from the server, which in turn does all the rendering with Presto 2.4 engine. Try running Opera Mobile instead and report the results.

Comment by SpShut — April 14, 2010

I love this. Would love to see it added to Browserscope ( http://browserscope.org/ ).

Comment by souders — April 14, 2010

Interesting, not sure the validity of this test though. Example: My Chrome Beta scoring 21 out of 27 on forms. O RLY!? So how does <input type=date> get a pass in Chrome, it doesn’t do anything! Opera implements it and you’ll see a real full blown calendar picker. Same with all the others like range, pattern, week, color, etc. Sure the attribute is created and scritable but in theory I can make an attribute “foo” on a DOM element and script it. Maybe because you aren’t using getAttribute() so the binding is native that is a pass!?

For finishing up HTML & CSS: The Complete Reference, 5th Edition I tested all this stuff quite extensively and I can tell you they only browser that has forms to any significant degree is Opera and I am still monitoring. There are a few attributes in WebKit but that’s it. The challenges are limited to that section.

Even the browser’s knowledge of the semantic elements like section, nav, etc is purely just because you can introduce arbitrary elements in the browser. They are not known as block or not, have any particular HTML5 attributes, etc. You can even simulate there occurrence in IE so failing IE seems slightly political not practical. (See Remy Sharp’s HTML5 shim script – http://remysharp.com/2009/01/07/html5-enabling-script/) All that does is a little trick that makes IE properly think of the custom elements here. You might want to add a <foobar> tag to the test, as I am sure it will pass too in many browsers given how they treat dummy elements.

Sadly while I LOVE this idea it somewhat misrepresentative of the true state of HTML5 which is itself quite a moving target. The kitchen sink attitude of the spec and people’s understanding of it particularly when including GeoLoc, Workers, Storage, etc. which aren’t main spec really confuses this testing and score of conformance. Maybe try to break the discussion up into the markup language, the APIs, etc.? Also the similar weighting seems to favor volume over core features. Unfortunately the test itself by bundling of all these things together really is aiding in making any mention of HTML5 into more a buzzword than a term anybody has a consistent and agreed upon definition of what is included. Despite that…go HTML5! :-)

Comment by ThomasAPowell — April 14, 2010

Because I’ve used my own js lib for a long time, I thought it could be nice to share my feature detection source as open source. Please take a look and see if it matches you needs. http://supports.netzgesta.de/

Comment by ucanmexwise — April 19, 2010

Leave a comment

You must be logged in to post a comment.