HTML5 <video> – a (very) short trip into real world use

After my last post about HTML5 video and thinking everyone’s getting ahead of themselves, I’d like to point out I’m not that stupid that I was going to ignore it completely, until I’d had a chance to try it out in a real world work environment situation. I can now ignore it. For a few years/implementations, at least.

It had been weighing on my mind that one of clients has a lot of video, and a lot of their audience are Mac users. This will probably mean there’s a high percentage of iPhone users, and in the coming months, iPad users.

So I’d been thinking about wrapping the Flash video player we have with the <video> tag and seeing how we go. A bit of an experiment, being eager to use these HTML5 elements because they show so much promise of doing things “the right way”, without kludgey plug-ins and so forth. So armed with a chapter on multimedia from messers Bruce Lawson and (the real) Remy Sharp from their forthcoming HTML5 book, I embarked on a journey of discovery.

The good news. Getting up and running, playing video and setting the poster frame was ridiculously easy. Having the chapter to hand was fantastic, because a reference source is needed with anything new. Very happy to see the video running in WebKit browsers, nice playback bar (Safari’s looks a little more cultured (figure 1) than Chrome’s basic big bar (figure 2)), but the video didn’t look quite as good stretched as Flash in Safari (you could see some cross hatch type lines were the scaling was implemented), but seemed better in Chrome. Not a show-stopper.

Right, cool, lets push this further. I want to style that playback bar. What’re the CSS classes and IDs? Oh. I have to “roll my own” in JavaScript? Are you kidding me? This is the beginning of the bad news.


That’s right. If you want to customise the playback bar in anyway, you have to write it. In JavaScript. I don’t do much JavaScript, in fact, very bloody little, and I was very disappointed in this. I guess I was hoping for a bunch of default elements I could target, move and style. Still, I guess it won’t be long til some clever sod has written a js-playback bar generator online, where you can choose all your desired elements and attributes. A cookie for the first one, from me.

Ok, so slightly disheartened, we go looking at how the video reacts in other browsers, and it’s fall backs etc., aka, the bad news steps up a gear.

Here’s where I misunderstood something about <video>, the fall back content you put in between the <video> tags is only there for browsers that do not understand the <video> tag. It is not there for browsers that do not understand the video codec. Let me repeat that so we are clear. If the browser understands <video> but does not support your codec (h264 in my case), the browser does NOT fall back to the Flash code or instructions and links you may have put inside the tag. Once I’d understood this, I kinda went “oh yeah, that makes sense.”

What does not make sense is that at the moment, is how browsers that don’t support h264 behave. Opera still shows the play bar, and holds the poster frame (figure 3) which for all intents and purposes, will make the user thinks the video is still going to load. There’s no alert and no warning. Firefox is a little smarter, and knocks back the poster frame to an opaque black, and puts a cross in the middle (figure 4). No real description of what’s happening, but at least the user is told that something is amiss. To my mind, this would be a perfect time to use that fall back content that’s in between the <video> tag, but aimed solely for older browsers.

Rich Clark on Twitter

So I started googling and asking a few knowledgeable people on twitter about this, and it appears this is the way it is. Rich Clarke of HTML5 Doctor fame agrees that yes, it sucks at the moment, but that’s the way it is. Tom Leadbetter, who wrote this piece on HTML5 video for HTML5 Doctor, says he can’t see if he’s missing anything, but did point me to a method of JavaScript browser sniffing to write in the correct code at run time. WTF!? 2010 and we’re back to using browser sniffing.

Rich says he’d like to see OGG win, as do all of the Opera crew I know, but I have to be brutally honest, I hope it doesn’t. No hardware acceleration on playback or encoding, shit meta-data containers, lower quality picture quality to file size ratio… it’s like saying I’d like to see everyone driving a Trabant. I think it’s a disgrace that these browsers that don’t support the given codec can’t do anything better about handling it. And before you accuse me of being biased against OGG/Opera, if Safari can’t handle being fed *only* an OGG file, with no h264 file, then it better do a better job of handling it gracefully.

So it appears, that at the moment, if you have a handful of videos, and you can encode to both OGG and h264 formats, and don’t want to style a playback bar, <video> does a great job. If however, you’re maintaining a client’s site that has over a thousand videos, and possibly no way of getting your hands on the originals that the h264 videos were encoded from to encode an OGG alternative, and you want to style a playback bar to fit in with your site’s branding, you’re in for some tears.


On a lighter note, I will, however, highly recommend Bruce and Remy’s book, Introducing HTML5. I’ve been lucky enough to unofficially review a few chapters from Bruce, and I really like what I’ve read, and it’s practical. It’s aimed at people who’re crafting away with HTML4 or XHTML, with hands-on examples and where needed, theoretical discussions of unimplemented tags or methods. We shall be buying a copy for the JP74 offices as soon as it’s published.

Figure 1. Safari
Figure 1. Safari
Figure 3. Chrome
Figure 2. Chrome
<video> in Opera
Figure 3. Opera
<video> in Firefox
Figure 4. Firefox