Google and the <video> tag

Though H.264 plays an important role in video, as our goal is to enable open innovation, support for the codec will be removed and our resources directed towards completely open codec technologies.

From HTML Video Codec Support in Chrome

Well that sucks.

Gruber asks a few “simple questions” here. Aside from the question of hypocrisy w.r.t. Flash bundling, I think his points are more than neutralized by these ten questions:

You are a proponent of Apple using its influence to diminish the importance of Flash for the web. Yet, when Google makes similar moves to rid the web of a similarly closed and patented, albeit different type of technology, you do not support them. Why is Apple promoting an open web a good thing, but Google promoting an open web a bad thing?

I think that if Google pulled Flash support from Chrome there would be no question that Google were on the side of the angels (although it would still be a dumb thing to do), but since there’s no hint of this it seems purely like a cynical move to hurt Apple’s anti-Flash campaign which will damage HTML5 <video> adoption. I think you can make the argument that HTML5 <video> adoption with H264 as the defacto standard codec is a Bad Thing.

Anyway it’s a bigger mess now than it was before Google decided to do this. Ultimately it will come down to “what will let the most people see the most porn using the most devices?”

Postscript: “standards”

One of the arguments made in favor of WebM/VP8 is that it can be part of the W3C standard, unlike H264, because it’s not encumbered by license fees. The problem here is that WebM/VP8 almost certainly is encumbered (as was GIF in earlier days), it just hasn’t been sued yet because no-one uses it. But this is beside the point — the CSS font-family property supports any font, and almost all the fonts that anyone cares about are encumbered (i.e. subject to royalties, copyright, and so on). Just as CSS font-family can specify a non-free non-open-source font, there’s no reason why a video tag can’t point to an arbitrarily encoded video.

To put it another way:

There’s no conflict between the HTML specification being open and royalty-free and H264 video playback being supported in HTML5 video tags as long as the codec doesn’t need to be implemented by the browser. Just as a slab of text with font-family “Verdana” won’t necessarily display on every browser correctly (if the font is not installed) it would follow that not every video will play back in every browser.

As a practical matter, it would be nice if serving a page with video were as simple an affair as possible. E.g. figuring out which video to serve didn’t involve sniffing the browser, operating system, and so forth; better yet, if one video format worked everywhere. As a practical matter right now H264 is the best candidate. VP8/WebM will never be the best candidate because by the time there’s a critical mass of hardware support out there it will be obsolete. This is a stupid, stupid fight.

And yet one more thing:

It’s interesting that the companies still in favor of h264 (Apple, Microsoft) are precisely those companies who do not implement the codec in the browser. Apple and Microsoft both implement h264 as a plugin architecture at OS level rather than a plugin at browser level (a much worse thing — see this excellent piece that daringfireball brought to my attention).

Is a it a font or an image file format?

The flipside of my argument that H264 should be considered analogous to a font is that, generally speaking, text is still legible when presented in the wrong font. By that argument H264 is more like an image format (JPG, PNG, etc.). If we accept this argument — which I’d say is the most h264-hostile stance (within reason) to take with respect to video codecs — then consider that most browsers simply let you display pretty much any image that’s convenient inside an <img> tag (sometimes badly, as per Internet Explorer’s notorious mishandling of PNG files over the years), generally by using the underlying OS’s APIs for handling images, which is exactly what I’d suggest the idealistic and pragmatic approach for video ought to be.

Would it be great if there were one codec out there that worked everywhere that web developers could target? Sure. But that doesn’t mean not supporting video codecs that happen to be around anyway, just as I can click on a PSD or TIFF in Safari and see it in the browser.

Ultimately, Google’s stance would have web browsers simply refuse to play back content with non-standards-based content (unless it’s Flash). What kind of “principled” or “non-evil” position is that? Again, if Google were to drop Flash support and make the argument that HTML5 is “the platform”, then it could make some kind of argument about consistency, but that’s not it. Google is making Flash part of “the platform” but not H264.

Webkit & Chrome UI Problem and Solution

Chrome's Tabs

I’m starting to like Chrome. I used it as my default browser for Windows for about a week before its various subtle bugs drove me back to Firefox (I got over my annoyance with Firefox…). Under Windows, Chrome is aesthetically challenged, but on the Mac it’s lovely. My one quibble is with the way tabs are positioned.

Chrome does put its tabs above the URL which—conceptually—belongs to the web page you’re looking at. But the tab also contains your bookmarks, which are global context.

Webkit's TabsWebkit/Safari has, without doubt, the most bizarre tab arrangement in the history of computing. It looks quite nice, but it makes no sense at all. It doesn’t work badly, and I guess if you’re going to give up on making sense conceptually, why not go for aesthetics?

I think there’s a very simple solution. Put the freaking tabs on the side of the window—like iTunes or Finder. There’s one browser that does this—Omniweb.

I actually bought a copy of Omniweb back when it was pretty much the best alternative to Internet Explorer 5.1—shortly afterwards Camino came out, followed by Firefox, followed by Safari. Omniweb is now free and webkit-based.

Omniweb's Drawer

The only problem with Omniweb is that the “tabs” are placed in a drawer, which is ugly, has the disadvantage of not visually associating the tabs with the browser view as Finder does, and—worst of all—being a freaking drawer. Even so, Omniweb probably has the best thought-out UI of any current browser. (And not just because it is the only browser to deal with “tabbed” browser windows in a sensible way.)

Aside: drawers should simply not be used for UI elements you expect to use all the time. I’d go so far as to say that Mac OS X would be better off without drawers in the first place. I can’t think of an application which uses a drawer that wouldn’t be better served by simply integrating the same stuff into the parent window. (Pathfinder’s pathological use of drawers is the main reason I can’t bear using it.)

Finder's sidebarHere’s Finder. This is how to do browser tabs. (It’s a shame Finder doesn’t actually dynamically insert open windows in its side menu—it would fix about 75% of what’s wrong with it.)

Tabs are, in general, a stupid idea. They waste vertical real estate (which is more valuable than horizontal, especially on today’s widescreens), and they do so inefficiently (since titles are wide the squat) so you frequently can’t see all your tabs. They’re really only useful in cases where they let you pick from between a small number of options (e.g. selecting views and palettes in Photoshop or Unity)—cases where a side panel would be massive overkill. This is why a lot of more complex programs have stopped using tabbed dialogs for their preferences.

Here endeth the lesson.