Chrome Dropping Video Codec H.264
It was big news when World Wide Web Consortium's (W3C's) Philippe Le Hegaret stated, "The problem we’re facing right now is there is already a lot of excitement for HTML5, but it’s a little too early to deploy it because we’re running into interoperability issues." In his coverage of this quote in W3C: Hold off on deploying HTML5 in websites, Paul Krill summarizes a particular sticking point in HTML5's progress:
HTML5 still does not have a video codec. It can’t use the popular MPEG-4 format because it has “patent issues” according to Le Hegaret. Google is hoping that its open source WebM format could become the default, but that is far from settled yet.
The problem of the video codecs was illustrated clearly today with the announcement that the Chrome web browser will be dropping its H.264 support in order to "focus investments" on "technologies that are developed and licensed based on open web principles." Chrome will support "WebM (VP8) and Theora video codecs" and may provide "support for other high-quality open codecs in the future." These statements are specifically talking about Chrome's support for the HTML5
<video> element.The announcement is interesting because it illustrates the struggles of HTML5 to have standard video implementations. Other browsers will likely continue supporting H.264 for the forseeable future. Developers are stuck with the unenviable position of needing to decide which codecs to encode their video with or making multiple copies of their video for the different formats. In all likelihood, most developers will likely simply use Flash or Silverlight to do this heavy lifting if the browsers cannot improve standardization and compliance on the video front.
The comments on the Chrome announcement regarding dropping of H.264 support (numbering nearly 400 at time of this writing) are an interesting read as well. There is a wide range of responses. Even developers who want to see open standards prevail are at odds over whether this is a good move or not. Some developers think it is good for open standards because Google is choosing "open" over proprietary. Others who want open standards to progress feel it will lead to just the opposite result: developers and users will continue/return to Flash/Silverlight and abandon or minimize HTML5. Some feel the move is simply another tactic in the increasing clashes between Google and Apple similar to Google's pulling out of JavaOne 2010 in its spat with Oracle.
End users are not too happy about the Chrome announcement either. The general demographic of the people commenting on this post seems to be technically-minded individuals and even many of them realize that they will likely shift to a browser that plays a video format as prevalent as H.264. I have a difficult time believing that ends user with less technical savvy will want to continue using a browser that doesn't play many of the videos out there (or they'll simply make sure they have Flash installed!).
On the one hand, developers admire Google's decision choosing open over closed. On the other hand, some developers argue that choice is always best and that Chrome should support open standards but should not remove support for the closed but common (defacto standard) format.
I'll admit that I'm torn on the issue and understand the various arguments and can appreciate them. In the end, though, I too think that if it becomes too much of a pain for me as an end user, it's all too easy to switch to one of the many other fine web browsers that are available. There's much to like about Chrome, but it still has a relatively small percentage of users compared to Internet Explorer and Firefox. I'd expect this usage to stop growing and even decline among general users without standard video support unless Flash is able to cover the gap (the most likely scenario for web developers to deliver if they want to make their customers' video experience consistent). Chrome is more popular among developers, but even its popularity in that group could be reduced because of this move.
Undetectable HTML5 Features
Scott Gilbertson's post A Guide to HTML5 Features You Can’t Detect references Modernizr's wiki page on The Undetectables. I have blogged previously on using Modernizr to detect HTML5 compliance in Firefox, Chrome, Safari, and Internet Explorer and on using Modernizr to detect HTML5 compliance in Opera. Unfortunately, there are HTML5 features that are not sufficiently supported in one or more browsers whose lack of availability cannot be detected through the typical feature detection mechanism. The Modernizr wiki page The Undetectables lists features whose presence/absence cannot be determined via feature detection and enumerates the three possibilities left to the web developer for dealing with these.
HTML5 Templates
The HTML5 Boilerplate is well known among HTML5 developers as a starting point for HTML5/CSS/JavaScript and as an example of what can be done with these technologies. However, some find it too difficult or too large to use as-is as evidenced in The Real HTML5 Boilerplate post. HTML5 templates seem to be popular now and two examples are Easy HTML5 Template and Five Free Beautiful HTML5 Templates.
People of HTML5
Chris Heilmann, "Principal Evangelist at Mozilla for HTML5 and open web," has started a series of posts called People of HTML5 and so far he has highlighted Bruce Lawson and Remy Sharp. I typically don't care much about posts about individuals, but these are interesting because of the insight they provide into HTML5 as it is today and as it is expected to be tomorrow.
Conclusion
I really like many things about HTML5, a large number of which are already well supported and an even larger number of which will be really well supported among the two dominant web browsers when Firefox 4 and Internet Explorer 9 come out of beta. However, there are legitimate concerns about portions of HTML5 such as video that appear to be potentially troublesome for the near future. The frequency of HTML5 posts demonstrates the enthusiasm for it, but legal and political realities seem to still be hurdles. It is most likely that, much like previous versions of HTML, some portions of HTML5 will enjoy greater consistency of implementation than others. Developers will be likely to favor those HTML5 features with the greatest consistency in support and to provide fallbacks for other features if used at all.
6 comments:
John Gruber has publicly asked five questions that I think many of us are asking regarding the announcement that Chrome is dropping support for H.264. Ed Bott's Google Chrome to drop H.264 support; roadblock to HTML5? looks at how this announcement may or may not impact HTML5.
Hi Dustin. In the HTML5 Templates section, the link for Easy HTML5 Template and Five Free Beautiful HTML5 Templates point to the same target. Can you let me know the target for the Five Free Beautiful HTML5 Templates link? Thanks! Another great article!
Chris,
Thanks for letting me know about that copy-and-paste problem (duplicate paste!). I've fixed it in the post itself. The link is http://www.codefear.com/template/free-beautiful-html-5-templates/.
Thanks again for letting me know about this.
Dustin
In Google and H.264 - Far from Hypocritical, Simon Phipps states that Google is not being hypocritical for dropping Chrome's <video> element support for H.264 while retaining support for the Flash Player, which Phipps states suffers many of the same negative points as does H.264. Phipps admits that there really is some hypocrisy in this "if you're an absolutist." I get a little nervous when we start splitting semantic hairs. I think it is, on the surface and in the short term, somewhat hypocritical.
I think that what is more compelling in Phipps's post is why Google might be choosing a current state of hypocrisy. Phipps outlines some differences in the support for Flash versus for H.264 and writes that this is a move toward greater openness. I agree with many of his points and believe that this is a case where Google probably believes that the "ends justify the means" even if the means are a degree of hypocrisy (at least in the short term).
Is there hypocrisy here? Yes. Is that anything new? No, it's human nature and all too common, especially when "a greater good" is used to justify some short-term hypocrisy.
To me, though, the most compelling difference is what Phipps hits on - Chrome's support of an HTML5 tag (<video>) is a very different animal than supporting a plug-in via a mechanism outside of the proposed standard. In short, I agree with most of Phipps's assertions and his thoughts on Google's "bigger picture" motives, but I think it's entirely reasonable for people to see the behavior as somewhat hypocritical.
For other viewpoints, see So Google, You’ll Be Dropping Support For Flash Next, Right?, Google Prepares to Ruin Chrome Browser, Chrome Users are the Latest Casualty in Google's Crusade Against Apple, Chrome Waves Goodbye to H.264, and this article on Microsoft versus Google in HTML5 video battle.
In his post More about the Chrome HTML Video Codec Change, Product Manager Mike Jazayeri today posted additional details on the recently announced decision to drop <video> support of H.264 in Chrome. Many of his points have been made by others and are valid points (plug-ins will still allow H.264 encoded video to play, other browsers don't support H.264 in the <video> element either, etc.).
However, as the comments on the post indicate, many believe there are still ulterior motives and abundant hypocrisy involved. Several commented that they feel Google is setting back the adoption of HTML5 <video> rather than speeding it up.
It does seem to me that history is repeating itself again and that we shouldn't hold our breath for truly comprehensive standardized HTML support in web browsers anytime soon. Throughout the history of the web, we've never been able to enjoy such standardization. As this and other recent moves by other major players prove, we'd be silly to think it will be any different any time soon.
In my last comment, I mentioned that the history of web standards is that they are not applied consistently so we shouldn't really expect more with HTML5. Further evidence of this is the post IE9 Tries to Implement HTML5 - Hilarity Ensues and a response post Building Great Browsers Together. The good news is that Internet Explorer finally seems to be making an effort to be more standardized. Historically, Internet Explorer has been by far the least compliant with standards of the major browsers.
I'm a strong believer in the theory that a standard is only as good as its implementations. This applies to HTML5: it will only be as good its major implementations. If the implementations lack consistency in support of HTML5, HTML5's efficacy will be reduced.
Post a Comment