html5 video fallbacks with markup

In a previous post on this blog we talked about using JavaScript to create video elements on the fly. While that was a good use case for the Mozilla’s support site in this post we offer another set of methods that will likely find more use on the web. In fact you can see it in use on Mozilla’s What’s New in Firefox 3.5 video, this blog and we’re starting to see pickup on the web as a whole.

The examples here should work with Safari 4, Firefox 3.5 and IE using a flash fallback. If you’re looking for a complete example that includes support for the video element, quicktime, windows media, iPhone support, and finally flash support you might try checking out Video for Everybody. It’s been tested with a huge pile of browsers in different configurations and is a good start point if you’re looking for support for everything under the universe.

You might also check out Michael Verdi’s video tags with fallbacks article where he uses a much simpler, but somewhat easier to understand method.

A simple example

The video tag looks something like this in a web page:

<video src="zombie.ogg" controls></video>

What this does is insert a video element into your page. Firefox 3.5 will load the video, determine its size and re-size the element to the natural size of the video.

Firefox 3.5 supports the Ogg Theora video format, a free and open standard for video. Opera and Google Chrome will also include support for Theora in later versions. Safari 4 can also support the same format when using the Xiph Quicktime component but is not guaranteed to be present. Apple has licensed the mpeg4 format for use in Safari 4 and it is supported by default.

If you want to support both formats you need to be able to provide more than one type of format. You also need to change the markup to tell the browser about the types of the files, which order they are preferred and then let the browser choose which one it should use to display the video element. For our example the code would look something like this:

<video controls>
<source src="zombie.ogg" type="video/ogg"/>
<source src="zombie.mp4" type="video/mp4"/>

In this case the browser will first check to see if it supports the video/ogg video type. If it does, it will use that and load it. If it doesn’t it will move on to the next entry, the mp4 file and use it if it’s supported.

While most modern browsers have specific plans to support the video element, Microsoft has not made their intentions clear. So in order to support IE users into the near future you should provide fallbacks until Microsoft adopts this part of the new HTML5 standard. For our example we’ll use a simple flash fallback.

One nice thing about the video element is how easily it degrades to older browsers. If in the above example your browser doesn’t support the video tag and doesn’t support the source tag it will simple fall back to whatever happened to be included inside them. This makes it very easy to support fallbacks in a very easy way. Here’s what a flash fallback would look like that uses

<video controls>
<source src="zombie.ogg" type="video/ogg"/>
<source src="zombie.mp4" type="video/mp4"/>
<embed src=""
  width="500" height="396"

And that’s it. This example supports all browsers, degrades nicely and helps to move the web forward all in one blow. HTML5 isn’t finished, but web developers can certainly start taking advantage of the features that it provides in modern browsers today.

The full example is embedded below.


Comments are now closed.

  1. Pingback from using HTML5 video with fallbacks to other formats at on June 22nd, 2009 at 23:29:

    [...] shows how to add video objects to a page using JavaScript. For most pages we suggest that you read the article that contains information on how to use the video tag to provide simple markup fallbacks. [...]

  2. Kroc Camen wrote on June 23rd, 2009 at 00:09:

    I’ll update my letter, and thank you, so kindly. I can finally see video on the web! I would only add that actual fall back text is *very* important. If the video doesn’t play for them, then a download link will help. Devices like the Palm Pre require it at the moment!

    BTW Did you leave out in the second example code?

  3. Da Scritch wrote on June 23rd, 2009 at 00:39:

    Embed is not a good solution : thisis a useless and depreciated html tag. Better way is to use Object tag, with fallback within.
    As I explain in French :

  4. Pingback from handraiser's status on Tuesday, 23-Jun-09 09:52:46 UTC - on June 23rd, 2009 at 02:52:

    [...] "html5 video fallbacks with markup" from [...]

  5. Tim wrote on June 23rd, 2009 at 02:58:

    @Da Scritch: I thought the embed tag was making a comeback in HTML 5. Personally, I don’t like the direction in which the Web is heading, but meh.

  6. Laurentj wrote on June 23rd, 2009 at 03:08:

    @da scritch : embed is not a deprecated element, it is part of html5 :

  7. Jimmy Hartzell wrote on June 23rd, 2009 at 03:51:

    Great! Straight-forward HTML over Javascript any day.

  8. Bob van der Vleuten wrote on June 23rd, 2009 at 03:57:

    This video tag is sure going to be a competitor for flash video when more browsers start supporting it in a good way. I can’t wait to see it’s potential unleashed!

  9. Pingback from links for 2009-06-23 « Breyten’s Dev Blog on June 23rd, 2009 at 04:05:

    [...] html5 video fallbacks with markup at Useful because it shows how to use the video element, and also a fallback for browsers that don't support HTML5. (tags: html html5 video howto degrading useful) [...]

  10. Shawn J. Goff wrote on June 23rd, 2009 at 04:34:

    So glad to see this method posted here!

  11. Mike Beltzner wrote on June 23rd, 2009 at 04:54:

    You forgot to end the video tag in the second code snippet :)

  12. Bernard van Gastel wrote on June 23rd, 2009 at 05:35:

    I am only sad that if I specified a non supported video format in the tag, the fallback contents will not load. In my opinion it degrades badly: if I only specify a h264 video, the video player of firefox is loaded with a black screen because it can not play the video. It should display the fallback content.

    1. N.R. wrote on January 29th, 2010 at 06:58:

      Yes, I also noticed that Firefox doesn’t fallback correctly. Instead of displaying a black frame, it should display fallback content. Somebody should submit a bug to Mozilla.

      What we did, is we made a “html5 mode” toggle button, which replaces the embed code with video tag code upon user request. This is a crappy workaround, but it works until Firefox fixes their fallback method.

      If anyone is interested, our solution can be viewed here:

      1. Kit Grose wrote on February 10th, 2010 at 01:51:

        This is not (strictly speaking) a bug; Firefox is correctly implementing the spec.

        I’ve raised this issue numerous times in the WHATWG mailing list and got a good response from Ian Hickson today:

      2. jhansi wrote on February 24th, 2012 at 00:42:

        Yes, I also noticed that Firefox doesn’t fallback correctly. Instead of displaying a black frame, it should display fallback content.
        Can you send the code of html5 which resolve the above problem…….

  13. sxpert wrote on June 23rd, 2009 at 06:18:

    doesn’t seem to work on my iPhone 3Gs

  14. t3RRa wrote on June 23rd, 2009 at 06:29:

    very nice. html5 looks that it is going to be handy :)

  15. zcorpan wrote on June 23rd, 2009 at 06:53:

    The code example should omit the </embed> tag (since embed is a void element, just like img), and should include the </video> tag.

    Da Scritch, embed is valid in HTML5, although it does not support fallback.

  16. Theodora Vorbix wrote on June 23rd, 2009 at 06:58:

    How do I control the .play() method in javascript? should I call the first, then the if the former fails?

  17. Joe wrote on June 23rd, 2009 at 07:54:

    Very cool. The mandatory use of Javascript was a real concern. I hope you decide to submit this as the recommended way to use video in HTML5.

  18. Christopher Blizzard wrote on June 23rd, 2009 at 08:01:

    @Bernard – If you specify the type to the video element the browser will display the fallback content. For example if you do this:

    <video src=”foo.mp4″ type=”video/mp4″>
    Fallback content!

    And your browser doesn’t support mpeg4 it should fall back to the fallback content.

  19. Bernard van Gastel wrote on June 23rd, 2009 at 08:03:

    @Christopher – Both Mozilla (with h264) and Safari (with theora) do not conform to that. They both just display the empty video player.

  20. Christopher Blizzard wrote on June 23rd, 2009 at 08:04:

    @sxpert – Funny you should say that. I spent an hour last night trying to figure out how to get my friend’s iPhone to play video content. In theory it’s supported. In practice it’s poorly documented and doesn’t give useful error messages.

  21. fuck you wrote on June 23rd, 2009 at 08:05:

    What a fucking retard, the guy on the video.

  22. zcorpan wrote on June 23rd, 2009 at 09:59:

    It seems wordpress is inserting <br />s for each new line inside the <video> markup, which makes it invalid HTML5. Clearly, this should be fixed in wordpress. As a workaround, you can avoid new lines in <video> in the markup.

  23. Kevin wrote on June 23rd, 2009 at 10:18:

    Does the autobuffer param do anything yet? I want to embed 3-4 videos on a page, but even with autobuffer set to false, Quicktime in Safari and the Theora player in Firefox start downloading all of the videos on the page as soon as the page is loaded. Which isn’t something I want it to do without the user saying so, especially for users on bandwidth caps.

  24. Kevin wrote on June 23rd, 2009 at 10:25:

    Is autobuffer supposed to be off by default? Because not including the parameter stops Firefox from autobuffering the video, but not Safari where Quicktime continues to download the entire video as soon as the page is loaded.

  25. Craig wrote on June 23rd, 2009 at 12:49:

    @Christopher Blizzard @Bernard van Gastel

    I reported a bug with firefox You are right – according to the html 5 specification, if the video (or audio) can not be played for any reason (including an unsupported codec), the fallback content should be displayed.

    I do not use webkit (at the moment). Can someone please file a similar bug with them?

    IMHO, this sort of non-compliance to the specification (especially such a young spec) is very bad, and should be fixed ASAP. I hope Webkit and Mozilla handle this non-compliance quickly.

    1. N.R. wrote on January 29th, 2010 at 06:59:

      Yay! Kudos to you, I hope they fix it.

    2. N.R. wrote on January 29th, 2010 at 07:04:

      I just checked, and they closed the bug as invalid, as it is supposedly a html5 spec issue :( Anyone want to raise this question there?

      This would help get rid of really ugly workarounds.

  26. Matthew Gregan wrote on June 23rd, 2009 at 15:54:

    @Kevin Yes, autobuffer is off by default as of Firefox 3.5 RC1. We now download only enough data to decode the first frame of the video. The presence of the autobuffer attribute signals that the author would like the entire video to be buffered. Note that autobuffer is what HTML5 calls a “boolean attribute”[0], where the presence of the attribute means the value is true, and the absence of the attribute means the value is false. So “autobuffer=false” is invalid markup, which is why it doesn’t do what you expect.


  27. Pingback from 颠覆网络35天 ─ 使用标记来满足HTML5 video向前兼容 < MJiA on June 23rd, 2009 at 20:09:

    [...] 原文地址:html5 video fallbacks with markup 系列地址:颠覆网络35天 [...]

  28. Kevin wrote on June 23rd, 2009 at 21:57:

    @Matt Yeah thanks. I figured that out just after I posted the comment. Removing it makes it work as expected in Firefox, now if only Safari/Webkit/Quicktime would get together and get theirs to not buffer unless told to.

  29. Ken Saunders wrote on June 23rd, 2009 at 23:59:

    This is all well and good, but doesn’t it mean that I’d have to upload and store videos in several different formats on my site?

    I’m not willing to do that or even write the extra coding no matter how basic that it is.

    I suppose it comes down to how badly that you want a visitor to your site to see a video.

    I’ll stick with learning more about open video and providing it on my sites. :)

  30. Adrian wrote on June 24th, 2009 at 01:14:

    It looks like that users cannot fully control the video play process. For example. I open this page and play the video, however I find a problem that I have no way to reply it– once I tried to drop it to start point and click play, the video shows me the face as loading.

    I use Firefox 3.5 RC2 English version on Windows XP SP3.

  31. zcorpan wrote on June 24th, 2009 at 02:10:

    Craig, both WebKit and Firefox do conform to the spec AFAICT, as I’ve commented in the bug.

  32. Joly MacFie wrote on June 24th, 2009 at 13:56:

    Is there somewhere that gives all the syntax for the tag?

    Is it possible to specify a seperate thumbnail?

    Resize the video?

  33. John Dowdell wrote on June 24th, 2009 at 15:18:

    Hi Chris, have you tested that in Internet Explorer yet? My memory is that they dropped understanding EMBED a few versions back, sticking with just the OBJECT that they invented and managed to get HTML4 to approve.

    Does the above fragment actually work across all browsers, and for parameters such as script access, autoplay and such…?

    tx, jd/adobe

  34. Christopher Blizzard wrote on June 24th, 2009 at 22:16:

    @John Dowdell – yeah, I tried it in IE 8 and it seems to be working fine.

    The fragment itself is pretty simple and doesn’t show many of the advanced features. I could add autoplay which all of the html5-video browsers support.

    As for script access someone is working on a neat little access library that will wrap flash in the html5 api if the browser doesn’t support it:

    It’s a great bridge to get us from where we are today to where we need to be a few years from now.

  35. Pingback from Firefox 3.5 available / video tag fallbacks « Cjed Audio blog on July 2nd, 2009 at 13:59:

    [...] really better than on Firefox 3.0 (are far behind Safari’s ones). We can discover a hack to use the new video tag on all browsers (on IE we will have to emebed a Flash element inside the [...]

  36. Pingback from video - more than just a tag at on July 9th, 2009 at 03:33:

    [...] Here’s some more information about the fallback mechanism. [...]

  37. Pingback from Christopher Blizzard · coherency vs. incrementalism on August 10th, 2009 at 14:16:

    [...] stacks? And can they be applied in an incremental fashion? We’re starting to see that with video being promoted as a first class citizen with Flash as a trailing edge fallback. We’re starting to see the web pick up 3D capabilities [...]

  38. Pingback from Christopher Blizzard: coherency vs. incrementalism | on August 11th, 2009 at 23:06:

    [...] these stacks? And can they be applied in an incremental fashion? We’re starting to see that with video being promoted as a first class citizen with Flash as a trailing edge fallback. We’re starting to see the web pick up 3D capabilities [...]

  39. Pingback from HTML5 video without JavaScript | on October 1st, 2009 at 11:42:

    [...] reply on using HTML5 video without using JavaScript: [...]

  40. Pingback from HTML 5 support workarounds and fallbacks | Lambda on October 3rd, 2009 at 05:58:

    [...] : [...]

  41. N.R. wrote on January 29th, 2010 at 07:01:

    Does anyone have any idea how to encode videos with FFMPEG so that they can be embedded with HTML5 video tag and play fine on the iPhone/iPad? our current mp4 files fail, I guess due to the used “vpre hq” in the x264 process

  42. troll wrote on February 9th, 2010 at 11:47:

    I hate to be a naysayer, but Apple and MIcrosoft will never support these codecs correctly and what was once a flash only solution is now going to be a free-for-all like the old days. Otherwise you’ll have to make and optimize at least 3 different renders and host all of that somewhere with the appropriate bandwidth. I don’t see this as any different than dealing with plugins ala 2001. I congratulate w3c and open source development for coming up with this, but in a production environment this is much more costly than the current solution. Even the “simpler” markup is more complicated than swfobject.

  43. Ernest wrote on February 9th, 2010 at 17:01:

    Christopher, that’s a very nice sample.
    However, it relies on the fact that the web developer will encode the video in all the available formats that browsers supporting the video tag can read, which is very unlikely.

    That snippet won’t fallback to flash if the web developer only has the ogg format and the browser only reads mp4 (the same happens with the audio tag)

    I tried to come up with a simple guide to implement a bulletproof solution. Unfortunately, Javascript is needed as it is no possible to do it only with markup. (it is for the audio tag but it also applies for the video tag)

  44. Clint wrote on June 25th, 2010 at 00:19:

    I thought I read somewhere that Apple requires the html video source tag to have the mp4 file listed first, then the other versions can be listed afterwards. I don’t think it will work on iOS unless the mp4 source is before the ogg.

  45. marc wrote on July 22nd, 2010 at 16:00:

    like to start with a big thank you!, this new Firefox 4 is great and looking forward to cheeking out some of your new addons, ps bring back the old grease monkey, lol

Comments are closed for this article.