HTML 5 and Internet Explorer 9: What We Know, What We Don't
The last time we explored HTML 5 in detail, specifically the video tag, the jury was out on whether the tag could be implemented with a specific codec: Apple had implemented H.264 in its Safari browser and Google had implemented both H.264 and Ogg Theora in Chrome, while both Mozilla Firefox and the Opera browser had settled for Ogg implementation, citing it as the open source video standard. Microsoft, for its part, was playing its hand close to the vest, telling the specifications editor of the HTML 5 working group, Ian Hickson, that it had no comment on either the tag or a particular codec.
At MIX 10, Microsoft's developer's conference that wraps up today in Las Vegas, the company has partially revealed its hand, announcing HTML 5 support for its upcoming Internet Explorer 9 (IE9) browser.
I say partially because, even though we know that Microsoft is supporting a large portion of the draft HTML 5 specification—joining Apple's Safari, Google's Chrome and Mozilla's Firefox browsers in supporting Cascading Style Sheets 3 (CSS3) and Scalable Vector Graphics (SVG)—we don't yet know other pertinent details, such as which video codec the new IE9 will be using.
Let's look first at what we do know.
Compatibility
The essence of browser nirvana, the thinking goes, is to have content represented the same across any HTML-based browser. As such, most browser vendors have adhered to the Web Standards Project's Acid Tests. Initial indications are that the IE9 browser scores much better on the Acid tests, which measure compatibility with cross-browser HTML code implementation, than any previous version of Internet Explorer. According to Microsoft, IE9 scores 55% on the Acid3 test, in contract to approximately 20% for IE8. By way of comparison, Acid3 scores for Chrome and Safari, based on WebKit implementations, are approximately 96% for each.
"IE supports CSS3 features such as rounded corners and opacity," one report of the conference stated, "while also now supporting SVG (scalable vector graphics) even though Microsoft is pushing its own Silverlight platform for rich graphics."
Speed
Acid3 isn't the only test that is used for compatibility; the SunSpider benchmark test is also used for assessing JavaScript speed. IE9 has a markedly improved JavaScript engine, with an almost seven-fold improvement over IE8, which brings it into line with the Firefox 3.7 browser beta.
Given that IE9 is a preview release, there's a good chance that JavaScript speeds could continue to increase. A part of the magic in the new JavaScript engine, named Chakra, is that it assigns an available core to work on processing the script. This hardware abstraction layer (HAL) allows the browser to take advantage of multiple cores without requiring the JavaScript or HTML programmer to program for a specific processor.
Another HAL that Microsoft uses is the graphics processor unit (GPU) as a way to offload graphics rendering from the CPU to the GPU. Microsoft calls this GPU-powered-HTML5 and was able to demonstrate smooth graphics and motion, as well as video playback.
Legacy support
IE9 will not support Windows XP, as the minimum requirement for IE9 is Vista's Service Pack 2 (SP2).
Support for legacy browsers provides a launching point into the discussion of how HTML 5 video tags are handled, as well as a few possible scenarios around the video codec that Microsoft will choose.
What happens when those users who have legacy browsers stumble on a site with HTML 5 video content?
The HTML 5 draft spec (March 2010 version) includes two options of ways to handle HTML 5 video tags. Using the term "user agent" to describe the browser, the draft spec notes that content can be embedded within the video element:
"Content may be provided inside the video element," the draft notes, adding "User agents should not show this content to the user; it is intended for older Web browsers which do not support video, so that legacy video plugins can be tried, or to show text to the users of these older browsers informing them of how to access the video contents."
The spec goes on to note that this is not a workaround for addressing accessibility concerns (508a in the U.S.) and suggests that authors are to pre-embed "accessibility aids (such as caption or subtitle tracks, audio description tracks, or sign-language overlays) into their media streams."
What This About Plug-Ins?
Isn't the HTML5 video tag supposed to eliminate the need for video plug-ins?
The answer is a bit convoluted. While it is true that the HTML5 video tag makes it possible to directly embed video clips in web pages, eliminating the need for plug-ins, the specification does not require such, in part because of legacy browser backwards-compatibility requirements.
In fact, in one of the bastions of open source software, the news and opinion site Slashdot.org, says the HAL concept is giving hope to those who see their favorite browsers moving toward H.264 when the users want to use open source codecs.
"There's nothing precluding the browser from using the OS centralized codec repository," said one Slashdot poster, "to which a codec can then be added (if not there already). In fact, Opera 10.50 does just that on Linux (it uses gstreamer). It also uses its own copy of gstreamer on Windows and OS X, to which you can add codecs if you want to."
A second approach that the HTML 5 draft suggests is the use of an external player.
"User agents that cannot render the video may instead make the element represent a link to an external video playback utility or to the video data itself," the draft states.
This leads to a third option, however, which is not part of the draft spec but has been popular for quite some time and may continue to gain in popularity for those who continue to want to use Flash.
The HTML video tag provides the opportunity to offer up multiple versions of a video file, covering the options amongst browsers that have settled on one specific codec. Here is an example of code gleaned from Henrik Sjökvist's website, in which he offers the third solution:
"A downside to this [HTML5 video] approach as opposed to using Flash or another plugin," he states, "is obviously that we currently need to provide three versions of every clip we want to embed (MPEG4, Ogg and FLV). For legacy browsers that don't support [the video tag] we need to use an alternative. An easy solution is to degrade to Flash using SWFObject."
In Sjokvist's version of the HTML5 video playback, with a failover to Flash, "the browser detects a video element and attempts to play it. If the content fails to play, a JavaScript kicks in and asks for the Flash player to play the video file that is encapsulated within an SWF (Flash-native) object.
Which Codec Will Microsoft Use?
All this talk about legacy support leads us back around to the question of which codec Microsoft will choose to use. My expectation is that they will use H.264 because it is natively supported within Windows 7 as part of the Windows Media Player, the exact same way that H.264 support on Apple's Safari browser takes advantage of QuickTime to access the H.264 codec for playback within Safari on the Mac OS X desktop operating system as well as the iPhone mobile operating system.
So why does the operating system's native support matter? In a word, distribution. The H.264 licensing addresses media players but not necessarily browsers.
This presents a conundrum for browser manufacturers that don't have a single desktop operating system to rely on: Do they create one official version of the browser that includes H.264 or do they revert back to plug-ins to insert H.264 after the browser is distributed.
A Slashdot commenter sums up one side of the argument.
"If Firefox had H.264 support, it could not be redistributed. Period." the poster said. "Everyone would have to download the 'official' version from Mozilla. No Linux distro could include it. No one could change the code and distribute it. It would cripple Firefox."
Another commenter countered with the plug-in option.
"H.264 can be implemented as a plugin," the second commenter stated. "Firefox needn't include this plug-in by default. There are plenty of third-party H.264 implementations to choose from. Mozilla themselves could even create such a plugin as an add-on, and make it freely available (sans source, if necessary)."
"Mozilla are shooting themselves in the foot," the commenter continued, "if their present stance is anything but bluster. The H.264 train is leaving the station, and Apple, Google, and even Microsoft are on board."
Related Articles
Now that Microsoft has announced HTML5 support, the question remains: Will HTML5 video end up being open source or standards-based?
22 Mar 2010
Kaltura provides a toolkit for HTML5 embedded video, with a fallback to Flash or Ogg Theora when H.264 isn't available in a user's browser
18 Mar 2010