Wednesday, January 26, 2011

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.

1 comment:

@DustinMarx said...

Neil McAllister articulates well some of the same thoughts I have had regarding the implications of WHATWG's decision to drop numeric versioning for HTML in the post HTML: The Standard that Failed?

I agree with McAllister that this move does make it even more difficult for web developers to know what level of compliance they are working against for each browser and makes it difficult to even gauge the browsers' respective levels of compliance.

I also agree with many comments on the blogosphere that this has always been how it has been with HTML: even with version numbers, browsers' respective degree of compliance has varied widely and developers have had to build web applications with feature detection and other tactics. Although this may mean continuing doing things as we've always really done them, it's still just sad. Why couldn't we improve things? Instead, things will continue to be more difficult than they should be and possibly even more confusing with HTML5 logos on one side and no numeric version on the other side.