HTML5 Video support Inception - Specialmoves
HTML5 Video
Support Inception
Specialmoves labs
In front-end development, it's sometimes too easy to get excited about the cool new things we can use, and to dive right in, in the belief that the sooner we start using something, the sooner regular users will come on board. The thing is, they won't.
SO given that, how exactly do we deliver funny cat videos to those using older browsers and less feature-rich mobile devices? It's time to take a journey into your mind some HTML.
The HTML5 Base video
This is our desired format, so we'll define it first. The handiest thing about HTML5 video is that support detection is built in at the browser level — you don't even need JavaScript to trigger a fallback if support doesn't exist. If a browser encounters an element it doesn't understand then it's ignored, so the <video> tag will be treated as a generic element with no styling and whatever is inside it will be rendered instead.
The biggest problem we're facing so far is a good, old-fashioned format war. Currently we can support all HTML5 supporting browser by providing two formats. h.246 and one of either Ogg Theora or WebM – browser support for the two is currently pretty much the same, so choose whichever one gives you the best video quality to file size. In our tests we've seen much better video quality with Ogg Theora, but it's worth you testing both.
Many other tutorials have dealt with the specific HTML, so I won't go into detail about that. So here's our starting HTML:
<video class="video" poster="/assets/video/posters/example.jpg" controls width="768" height="432" preload="none">
<source src="/assets/video/example.mp4" type='video/mp4; codecs="avc1.42E01E, mp4a.40.2"' />
<source src="/assets/video/example.ogv" type='video/ogg; codecs="theora, vorbis"' />
</video>
So now we're supporting all up-to-date desktop browsers, and the vast majority of the smartphone market. Well done, you. Have a banana.
We need to go deeper
You can probably guess what happens next — if HTML5 video isn't supported, then the <video> and its two <source> children are ignored and the browser skips to whatever's next, so this is where we need to put our Flash fallback. A neat time-saver here is that Flash can play the same h.264 video we're supplying to HTML5 browsers, so there's no need to provide yet another video format.
<video class="video" poster="/assets/video/posters/example.jpg" controls width="768" height="432" preload="none">
<source src="/assets/video/example.mp4" type='video/mp4; codecs="avc1.42E01E, mp4a.40.2"' />
<source src="/assets/video/example.ogv" type='video/ogg; codecs="theora, vorbis"' />
<object type="application/x-shockwave-flash" data="/assets/swf/player.swf" width="768" height="432">
<param name="allowfullscreen" value="true" />
<param name="allowscriptaccess" value="always" />
<param name="flashvars" value="file=/assets/video/example.mp4" />
<embed src="/assets/swf/player.swf" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="768" height="432" />
</object>
</video>
Great, so now we're also supporting any browsers with Flash, too. Excellent.
Heading into feature-phone-limbo
Imagine a world where you didn't have a little computer in your pocket the whole time. Some people still live in that world. That's ok, don't panic - but they want video too! Thankfully, browsers are smart about Flash support, too.
Many Flash developers fall back to a prompt to install Flash, which isn't always useful. Since we're dealing with video we can simply allow the user to download the file to view in the media player of their choice. Also, there's a very good chance that if they don't Flash available, they either don't want it, or can't have it. In these cases we can offer up a mobile version, too, for your dad on his Nokia 6820 or whatever the hell.
So our final code ends up looking like this:
<!-- This is the video itself. If neither of the first two <source> files are supported then this will fallback to the Flash player -->
<video class="video" poster="/assets/video/posters/example.jpg" controls width="768" height="432" preload="none">
<source src="/assets/video/example.mp4" type='video/mp4; codecs="avc1.42E01E, mp4a.40.2"' />
<source src="/assets/video/example.ogv" type='video/ogg; codecs="theora, vorbis"' />
<!-- Here's the Flash fallback. If Flash is unsupported then the image and link in this <object> will remain visible, which will provide the "last-resort" fallback -->
<object type="application/x-shockwave-flash" data="/assets/swf/player.swf" width="768" height="432">
<param name="allowfullscreen" value="true" />
<param name="allowscriptaccess" value="always" />
<param name="flashvars" value="file=/assets/video/example.mp4" />
<embed src="/assets/swf/player.swf" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="768" height="432" />
<!-- If Flash support does not exist, then the browser will render the following image and text: -->
<img alt="" src="/assets/video/posters/example.jpg" width="768" height="432" />
<p>Your browser can't play this video. <a href="/assets/video/example.mp4">Download it</a> instead.</p>
</object>
</video>
Conclusion
The main thing to take away from this is that supporting all your visitors is easy. If their device can play video, then you can provide it. There's absolutely no excuse for stopping someone in their tracks to tell them they need Flash. Or Silverlight.
This method of delivering video ensures that practically any web-enabled device with video capabilities will be able to view your video in some capacity. If after all this graceful degradation you still can't watch the video, chances are you're trapped in some kind of time-safe in the 80s. How are you doing in there are you alright it looks uncomfortable.
---
Jonic is a Front End Developer at Specialmoves. He's good at that Twitter @jonic