With the revelation that Internet Explorer 9 will support HTML5 video the score is tied. Opera and Mozilla are pushing for Ogg Theora. Safari and Internet Explorer will support H.264 and finally Chrome supports both.

Today Microsoft released the SDK for Windows Phone 7. It includes an emulator with a build of Internet Explorer. The useragent reported by the emulator is Mozilla/4.0 (compatible; MSIE 7.0; Windows Phone OS 7.0; Trident/3.1; IEMobile/7.0). I’ve also ran the CSS selector test and the HTML5 test and both report the same numbers as the desktop version of IE7.

Unfortunately still no modern browser for Windows Phone 7 users, but at least it’s a big improvement over Windows Mobile 6.5 which shipped with Internet Explorer 6. Even though they could make a switch to a more modern engine like Webkit, I can understand their reluctance to use an externally developed engine. Still I’m quite curious why they didn’t ship their own standards compliant engine: the one used in Internet Explorer 8.  Anything less seems to indicate to me that phones are still a second class citizen within Microsoft itself.

Opera announced that they ported their Opera Mini browser to the iPhone and will be submitting it to the App Store. It isn’t the first third-party browser for the iPhone but all others were based on the standard Webkit component that is available in the SDK. Opera Mini is unique in this regard because it doesn’t use Webkit, but has its own renderer.

There is one potential problem though; Apple refuses to approve applications that have an interpreter or virtual machine that can run arbitrary code. This is exactly what you need if you have built your own renderer and want to render pages that contain JavaScript. The interesting part is that Opera did not port Opera Mobile, but Opera Mini. The latter doesn’t actually contain a full brown renderer.

It uses Opera’s servers to render the HTML pages and sends the result in a proprietary compressed binary format to the relatively light-weight client. This is exactly why Opera Mini works so well on all of those older mobile phones which don’t really have the speed to power a full brown renderer like their Opera Mobile product. Is it enough to bypass the SDK rules? Maybe, I’m quite curious how Apple is going to handle this.

After Vimeo announced that they would be support the H.264 codec for the HTML5 video beta test, Silvia Pfeiffer published a completely ridiculous article in which she claims that Ogg Theora is a better choice because it has a reach of 95% while H.264 only has 25%.

Given that only roughly 30% of all browsers actually support HTML5 video in one form or another this claim is something of a mystery. She actually gets the 95% not from actual browser support by counting how many browsers are able to use the Java Cortado player as fallback. Well wouldn’t it be fair to do the same for H.264 and also count Silverlight and Flash for possible fallback. That way H.264 would be available in 147% percent of all browsers… Ehh…

The reality simply is that if we want use HTML5 video we need to use H.264 with a fallback mechanism or encode our content in both Ogg Theora and H.264. Only using Ogg is simply not an option for many devices.

Which is pretty good considering Adobe does not support SVG and at least 6 of the failed test are related to SVG.

As of tomorrow the new HTML5 parser will be available in nightly builds:

If you are still comfortable with testing, download a trunk nightly build tomorrow, run it, navigate to about:config and flip the preference named html5.enable to true. This makes Gecko use the HTML5 parser when loading pages into the content area and when setting innerHTML. […] There is also another preference called html5.offmainthread that defaults to true. If you suspect a thread collaboration bug, you can try flipping the pref to false to make all parts of the HTML5 parser run on the main thread.

FYI, this doesn’t mean that Mozilla will support any of the new HTML5 features any better, it will just mean that the HTML that it tries to render is parsed according to rules specified by the HTML5 spec. The result is that the DOM generated by the parser would be the same in all browsers that support these rules.

According to Dean Hachamovitch in the announcement on IE Blog:

Our focus is providing rich capabilities – the ones that most developers want to use – in an interoperable way.  Developers want more capabilities in the browser to build great apps and experiences; they want them to work in an interoperable way so they don’t have to re-write and re-test their sites again and again. The standards process offers a good means to that end.

Apart from support for border-radius and a big speed up for the JavaScript engine, Microsoft did not announce any specific features. They did not make any promises to support HTML5 features such as video and canvas, but they did mention the Acid3 test as one of the areas they would work on. Again no promises that IE 9 would pass the Acid3 test, just that its score will continue to go up during the development.

Things are also looking good for a pet peeve of mine: CSS selector support. A couple of years ago I created an automated test suite for the CSS3.info website that would test support of almost all CSS selected in the CSS2.1 and CSS3 spec. At the time no browser passed the test, but that quickly changed and nowadays every browser except for Internet Explorer passes. IE 8 did improve the score quite a bit and added all of the CSS2.1 selectors. Work on the CSS selector engine in IE9 is apparently already almost finished, because the announcement on the IE Blog includes a screenshot of my test suite and clearly shows that it fails only 4 tests of the 578. It supports 43 of the 41 selectors, one is buggy and just one is unsupported.

Update:

The CSS Selector test is also mentioned in a MSDN Channel 9 video about IE 9: Standards and Interoperability.