HTML5, Support, Browsers, and Mobile
- No Comments
Today’s news, just in time for the new year, is the HTML5 specification has been finalized.
“W3C published today the complete definition of the HTML5 and Canvas 2D specifications. Though not yet W3C standards, these specifications are now feature complete, meaning businesses and developers have a stable target for implementation and planning.”
Per that quote, this is a great step forward, but does not mean HTML5 content is ready for broad consumption. With the specification finalized (if it is truly ‘finalized’, revisions are inevitable), now it’s up to the browser and tool developers to fully support the spec. Per the press release,
“However, the same survey shows that ‘browser fragmentation’ remains an important developer concern, as it increases the cost and complexity of using a technology.”
To address this concern, the next challenge for the W3C is “devoted to interoperability and testing”, which simply means they will continue to encourage and test browser and tool releases against the spec, likely refining test environments and whatever other consultation and encouragement they can provide. However, note that the whole ‘HTML5 world’ also requires support of new iterations of the JavaScript and CSS specifications, which are actually separate standards.
Regardless, some tool providers are enthused! Sencha provides a development framework for HTML5 applications and is now sponsoring an ‘HTML5 is Ready’ contest for developers who re-create default native apps (i.e. Calendars, Weather, Stocks) as web applications using the HTML5 and Sencha framework.
In the eLearning world, this puts more pressure on authoring tool providers like Adobe (Captivate) and Articulate (Storyline) to more-quickly improve their HTML5 publishing. That’s a good thing too.
But the real pressure needs to be put on the browser developers (Firefox, Microsoft, Apple, Opera, etc.) to full integrate these features into their upcoming releases. All these browsers have issues with proper HTML5 rendering, especially with Video.
A quick test of the latest Firefox (v.17) using the ‘HTML5 Test’ website shows no support for subtitling and still no support for MP4/h.264, which is certainly the most popular video format/codec today. The total score is “388 out of 500”.
Microsoft’s IE 9, running under Windows 7, scores a measly 138 out of 500. At least it supports h.264…
Now those are ‘desktop’ browsers, so who really cares how HTML5-supporty they are? What matters is mobile browsers…and that’s true enough…but the point is to illustrate just how far browsers, and related tools, still have to go to bring HTML5 to the masses.
For example, Facebook recently changed over their Android App to completely ‘native’ code instead of trying to wrap their HTML5 code, resulting in the declaration that “Facebook’s HTML5 app nightmare is over.” Whether that’s true, we’ll see! Facebook itself is certainly not abandoning HTML5 entirely,
“Facebook’s mobile site will still run on HTML5. It will also continue pushing for better HTML5 standards from mobile browser vendors in hopes it can one day do more with the protocol.”
This is just one example of how HTML5 is not the mobile panacea so many seem to expect – at least, not yet. Everything now largely depends on the tool makers to get their products current…which means not only HTML5 support alone, but JavaScript and CSS support as well.
A final concern for this post is just how robust and demanding these fully-compliant browsers and tools will be. It’ll be nice to not have to go find and install a plugin (i.e. Flash) when the media is encountered the first time, because support for that media will be built-into the browser (audio, video, animation, etc.). But we wonder just how large these browsers are going to be with all that additional code…and how much of the system’s resources are they going to demand? Apple’s assertions that Flash was too resource-intensive for their mobile devices may have had its truths, but are browsers with all this additional codebase going to be any less demanding?
And when a plugin crashes (i.e. Flash) modern browsers can isolate that crash so the whole browser doesn’t come crashing down with it. Will that also happen with these fully-compliant HTML5 browsers? Or when a crash inevitably happens, is the whole application going to come tumbling down?
We’ll see what happens in 2013!