Thursday, 2 September 2010
Last week the MPEG-LA announced that it will not charge any royalties for streaming H.264 encoded video in the future. That does change much from the current situation. A couple of years ago the MPEG-LA already promised it would not change for streaming H.264 video until December 2011 and earlier this year this was extended to December 2015. Now they removed that deadline altogether, making H.264 “royalty free”.
At least, that is what several websites concluded. Some even predicted that Mozilla and Opera would soon implement H.264, that it would become the default codec for HTML5 and that WebM was doomed. Well, things are not that simple…
➜ Read more…
Friday, 25 June 2010
In case you haven’t heard yet, Microsoft released a new preview release of Internet Explorer 9 with all kinds of great goodies we have been waiting for, including HTML5 video support. I did notice that this new preview didn’t score any bonus points on the HTML5 test for its video and audio support. This was pretty strange, because it should have scored bonus points for the H.264 codec. The article below is the result of a little investigation about why IE9 doesn’t pass the H.264 codec test and the problems I found in other browsers.
➜ Read more…
Tuesday, 8 June 2010
Earlier today I’ve released a new version of the HTML5 test. The goal is still the same: to show an indication of how well your browser supports the upcoming HTML5 standard and related specifications.
It was clearly time for an updated test, because browsers were starting to get very close to the original maximum score of 160 points. If you disregard the codecs for a bit: a current nightly of Safari scores 95 out of 106. That is very close and demands a new challenge. The maximum of 160 was always intended to be a moving goalpost. The original test suite did not test for all of the new HTML5 features and I always intended to keep adding tests until the specification is stable and all features are properly tested.
➜ Read more…
Tuesday, 16 March 2010
I’ve just downloaded the first Internet Explorer 9 platform preview and tried out the demos. And frankly I am confused. They mention HTML5 all the time in the press release and on the IE blog. There are even five dedicated HTML5 demos… Imagine my surprise that after running the HTML5 test, Internet Explorer scores exactly the same as IE 8: a meagre 19 out of 160.
Even the demos they list as HTML5 are misleading. None of them actually deal with HTML5. First we have some CSS stuff like border radius and selectors. Then they give us DOM Events and DOM CSS. And finally the HTML5 T-shirt Designer which deals with SVG and events and not what the name suggests: HTML5. None of these tests are even served with the HTML5 doctype.
Okay, they did officially announce HTML5 video support, but where is the rest? I almost get the feeling they use the word HTML5 more like a fancy buzzword than actually supporting the specification. Time may prove me wrong, and they may actually implement stuff for future previews, but at the moment it is simply not yet here.
Tuesday, 9 March 2010
Want to know how well your browser supports HTML5? Try the HTML5 test and find out. Points are awarded for every HTML5 feature that is supported. Added together these points give a total score between 0 and 160. Compare multiple browsers or different versions of the same browser and find out which vendor is slacking off and which vendor is pushing the web forward.
Apart from the total score, the test also shows exactly which feature is supported and groups the results into easy to compare sections. Ideal for developers wanting to keep track of the capabilities of the browsers they develop for. In fact, the whole test started out just as a small internal tool for doing just that.
Of course there are some inherent problems with doing automated tests. The tests are only trying to detect if a feature is offered by the browser. It does not test the actual functionality of each feature. Also, the HTML5 standard and other related specifications are still in development. As the specification matures I hope to add new tests to test for these new features. The upper limit of 160 is a moving goalpost. Despite these shortcomings we hope that by quantifying the level of support users and web developers will get an idea of how hard the browser manufacturers work on improving their browsers and the web as a development platform.
➜ Read more…
Opera Mini for the iPhone
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.
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.
95% of statistics are completely made up
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.
Monday, 8 February 2010
I’m afraid PPK has gone off the deep end again. While I value his work on documenting desktop browser quirks and mobile browsers immensely, it is getting more and more difficult to take him serious when he rants about the iPhone.
➜ Read more…
Friday, 27 November 2009
Earlier this week Peter-Paul Koch wrote an article on how iPhone developers were stupid for not recognizing the potential of developing webapps. I agree with many of his points why webapps are a good alternative for native applications. I also agree that some of the apps that Apple currently ships with the iPhone could be replaced with webapps. That being said I do not believe that webapps can replace native apps altogether. Even Peter-Paul changed his mind on this point based on the comments in the original article.
➜ Read more…
Adobe AIR 2.0 scores 90/100 on the Acid3 test
Which is pretty good considering Adobe does not support SVG and at least 6 of the failed test are related to SVG.
Firefox gets a brand new HTML5 parser
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.
Microsoft started work on IE 9 and is planning to give web developers what they want
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.
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.
The CSS Selector test is also mentioned in a MSDN Channel 9 video about IE 9: Standards and Interoperability.
Adobe released the first beta of AIR 2.0
Adobe AIR 2.0 includes an updated version of the Webkit rendering engine which should add support for some HTML5 elements and CSS transforms, transitions and animations. I did a quick check to see what is supported and noticed the following:
- CSS Animations
- CSS Transitions
- CSS 2D Transforms
- CSS Gradients
- CSS Masks
- CSS Reflections
- HTML5 Canvas
- CSS 3D Transforms
- CSS Fonts
- CSS box-shadow and text-shadow properties
- HTML5 Offline Application Cache
- HTML5 Local and Session Storage
- HTML5 Database Storage
- HTML5 Video
Although 2D transforms are supported they look pretty ugly compared to the same effects in Safari. It looks like the transforms are done without proper interpolation and anti-aliasing. In their current state I would almost say that transforms are unusable. One thing I also noticed is that large text is also not anti-aliased, which makes it look quite bad compared to desktop browsers.