The State of HTML5

I will be presenting the thirty minute presentation "A First Look at HTML5" at Rocky Mountain Oracle Users Group (RMOUG) Training Days 2011 three weeks from today. Because I only have thirty minutes, I will necessarily only be able to cover high level concepts of HTML5 features and perhaps show some of the HTML5 demonstrations I have used in previous blog posts. However, one item I do intend to focus on because I think it will be the question on the minds of many in the audience is, "What is the state of HTML5 today?" In this post, I briefly look at what I plan my answer to be.

HTML5 and associated modern web technologies and standards hold much promise. Some features are better supported across the major browsers than others. Unfortunately, most web developers using HTML5 features today would need to ensure that their applications detect absence of HTML5 features and provide fallback mechanisms when necessary. Some HTML5 features suffer such lack of comprehensive support currently that including them at all may not seem worth the cost.

A World Wide Web Consortium (W3C) official (Philippe Le Hegaret) has stated (October 2010) that "it’s a little too early to deploy" HTML5 due to "interoperability issues." Le Hegaret specifically cites lack of video codec and, according to the Paul Krill article (W3C: Hold off on deploying HTML5 in websites), "does not expect to have one in the upcoming specification."

This seems to be born out by Google's dropping of H.264 from Chrome. The five major browsers are currently split 3-2 in terms of which video codecs they support in their <video> tags. The impasse is not limited to <video> only: Scott Schiller lays out the issues and caveats surrounding the current state of the HTML5 <audio> tag in "Probably, Maybe, No": The State of HTML5 Audio (December 2010).

Perhaps the most telling review of the current state of HTML5 is provided by Ido Yehieli in the post Why I'm Moving from HTML5 to Flash. Yehieli lists three main reasons (including well-known spotty feature support across browsers as well as performance issues) for switching from HTML5 (used for prototyping) to Flash for the game Cardinal Quest. What makes news of this switch compelling is that it comes from people who really wanted HTML5 to work and who invested time and energy into building something real with HTML5. Practicality, however, seems to have forced their hand. Yehieli ends his post with statements that I think reflect many web developers' feelings regarding HTML5 and its current state:

Is html5 the future? I sure hope so! Unfortunately, it isn't the present.

My recommendation is that HTML5 features should be considered on an individual basis and some might be applied earlier than others. Considerations that factor into this include how well a particular feature is supported across browsers, how difficult it is to provide fallback mechanisms, and the ability of browsers to degrade gracefully.

Joe Stagner's post 10 things you should think about with HTML 5 summarizes some other promising and concerning issues surrounding HTML5 as currently constituted. He too recognizes the ability to take advantage of HTML5 features incrementally.

An increasing number of HTML5 features should be more generally supported as time rolls on. Firefox 4 supports many HTML5 features not previously supported in Firefox and there is hope that it will be out of beta soon. Similarly, Internet Explorer 9 is also expected to be much more supportive of HTML5 features. With Internet Explorer and Firefox still holding the majority of web browser market share, the release of more compliant versions is important to the future of HTML5. Of course, there will be people who don't upgrade to more HTML5-compliant browsers for years to come.

I find HTML5 to be promising, but there are portions of it that still have a long way to go. Fortunately, there are some features that are or soon will be well supported by all major browsers and can likely be adopted currently or in the very near future. The WHATWG decision to change HTML5 to HTML reflects an increasingly popular perspective that the future of HTML mirrors its past: inconsistent support across browsers gradually evolving to more standardized approaches as the cowpaths are paved.