Articles Tagged ‘lwsdeep’

HTML5 Video and Audio at #lwsdeep

This month at London Web Standards, two in-depth HTML5 talks, covering bits which aren’t in common usage at the moment, and what you can do with the bits that are. This is part two, Opera’s Patrick Lauke (@patrick_h_lauke) on <video> and <audio>. Part one has Google’s Michael Mahemoff (@mahemoff) on 8 HTML5 features you haven’t seen before. Below are my notes and write-up. Enjoy!

Sketchnotes from HTML5 Video and Audio

Sketchnotes from HTML5 Video and Audio

First off, Patrick had a cold, hence the poorly drawn tissue in the top-left corner.

<video> and <audio> are some of the most important ¬†elements in HTML5. Steve Jobs thought so much of these new elements and HTML5’s potential, that Flash was dropped from iOS devices and everyone was encouraged to make the transition. Even Microsoft has recognised their importance, adding native support for the elements in IE9.

The basic idea behind <video> and <audio> was to do for these media types what had been done for images. Instead of using messy <object> and <embed> tags to make Flash work properly, create something simple that doesn’t rely on proprietary technology. Therefore, <video> is now a native object in the browser, which allows you to treat it just like any other object, including styling it with CSS and even using CSS transforms on the video.

There’s an important aside around video formats which I’ll cover briefly here. There are three codecs:

  1. MP4/H.264 – implemented by Chrome, Safari and IE9, encumbered with potential royalty payments, whatever the MPEG association try to say.
  2. Ogg Theora – implemented by Chrome, Firefox and Opera, open source but not very good as a codec
  3. WebM – implemented by Chrome, Firefox, Opera and IE9 (with downloaded codec) it’s made for the web and will be the de-facto standard going forward. Apple have yet to commit to using the format

Thankfully, you can use multiple sources in your videos which will fall back to one another. You can even fall back all the way to Flash to give older browsers a fighting chance.

Each browser gets to implement their own controls for the video player, but these can be overridden and the whole video controlled by JavaScript. There are events which fire at different times and ¬†theoretically it’s possible to time-match subtitle tracks, which WhatWG are looking into for future versions of the HTML spec.

<audio> is very similar in implementation to <video>, with the same format fight, this time between MP3 and Ogg Vorbis. Interestingly you can remove the controls from the page and run the whole thing from JavaScript, allowing for such horrible interactions as a whoosh sound when hovering over a button.

Best yet, is that Patrick officially certified these techniques ready for use. Their is sufficient support and fallback options to support all browsers, take YouTube for example, running HTML5 video for nearly a year now. However, he asks that you use feature detection rather than browser sniffing when making these fallbacks. There are a few tools out at the moment which do all this for you, such as SublimeVideo and videoJS.

And that’s it. Hope you enjoyed it. You can read Part one of #lwsdeep here.

8 HTML5 Features You Haven’t Seen Before at #lwsdeep

This month at London Web Standards, two in-depth HTML5 talks, covering bits which aren’t in common usage at the moment, and what you can do with the bits that are. This is part one, Google’s Michael Mahemoff (@mahemoff) on 8 HTML5 features you haven’t seen before, and part two, Opera’s Patrick Lauke (@patrick_h_lauke) on <video> and <audio>. Below are my notes and write-up. Enjoy!

Sketchnotes for 8 HTML5 Features You Haven't Seen Before

Sketchnotes for 8 HTML5 Features You Haven't Seen Before

This talk focused on 8 less-commonly used features of HTML5. Whether they’re all actually part of HTML5 is up for debate, but they’re all specifications being worked on for implementation in browsers, so that’s enough.

Firstly, Michael had made his slides using HTML5, which worked really quite well, nice flashy transitions and all that and was a good example of some of the features he showed off (notably the history API) .

1. App Caching
App caching is making web sites work offline: it tells browsers which files they should keep cached and re-load when the URL is requested. Whole apps can be cached like this and the iPhone and Android make good use of this. This is not the same as…

2. Client-side Storage
Which is data storage accessed from JavaScript. You used to do this with cookies, but now you’ve got access to simple storage arrays, and WebSQL and IndexedDBs are coming. Both of these together replace services like Google Gears which was a stop-gap for this.

3. Cross Origin Resource Sharing
One big problem with AJAX is that the XHR request can’t request something on another domain. The work-around for this is JSONP which is a hack if there ever was one. CORS allows people to do this in an open way… which to me, is simply dangerous. However, it will have some uses, unlike…

4. Ping
Which, apart from being a new social network, adds a bit of header information basically pinging a web site when a link is clicked. It’s designed to replace redirects but I didn’t really understand a good use case for it. If anyone wants to explain it, please drop me a line.

5. Web Sockets
Web sockets allow for a connection to a server to be kept alive and events received, much like sockets created in any other programming language. Web sites like Facebook (for chat) and Swoopo currently use Comet for doing this and web sockets will allow them to get updates pushed to the page from the server without the ugly hacks.

6. History API
I’m looking forward to this one: it allows for JavaScript inspection and manipulation of the browser’s history stack (or array, whatever it is) without changing the URL to use the # technique. It’s going to be very powerful for making applications where you don’t change the page but lots of things change state and users use the back button a lot. I made ¬†a note that it’s quite a bit like a view state, making an ASP.NET comparison, but that’s a bit unfair.

7. Workers
Web workers enables multi-threading in JavaScript. Finally! I hear you cry. It’s not widely supported at the moment and it is about 25% slower than running the process in the main thread, but means you can do all sorts of things whilst the UI keeps updating.

8. Geo-location
Used to be done by IP with big expensive databases, but can now be done with hooks into device hardware. Useful for a load of different applications, this will be one of the most widely-used of the HTML5 APIs.

And that’s it. They’re all under-the-hood improvements, and the browser makers are making it easier to do the cool stuff, which will bring in a lot of innovative web apps as people discover the power of these new tools.

Part two of #lwsdeep can be found here

Update: here’s a picture of what’s in HTML5 and what isn’t by Bruce Lawson (Flickr)

What's in HTMl5

What's in HTML5 and What isn't, created by Bruce Lawson