HTML5 does way more than video: Vimeo’s Flash-free player showing a clip by Maxime Bruneel.
Unless you’ve been off snorkeling in the Alps, you’ve probably heard all the recent hubbub about HTML5 and its ability to replace Flash as the web’s default video player.
But HTML5 is much more than a hopeful successor to Flash’s web-video crown. In fact, watching a video without a plug-in only scratches the surface of what HTML5 offers.
HTML5 is the next generation of HTML, the language of the web. More than just a markup syntax like its predecessors, HTML5 provides a new set of features designed to make modern web applications work more like desktop applications.
The key features in the HTML5 stack: native video and audio playback, animated graphics, geolocation, hardware acceleration for in-browser events, the ability to keep using a browser-based app even if your internet connection drops, the ability to store application data on your local machine, dragging and dropping of files from the desktop to the browser, and the addition of semantic markup on pages, making them easier for both machines and humans to understand.
Each of the major browsers supports different pieces of HTML5 right now, and we expect to see all browsers on the same page in a year or two. You might think, given variances in browser support, that no one is using the future of the web. But you’d be wrong. HTML5 is everywhere you turn. In fact, some of our favorite web apps are making heavy use of HTML5 — to paraphrase William Gibson, the future of the web is already here, it just isn’t evenly distributed yet.
Did you know that Google’s homepage, one of the most trafficked pages on the web, uses HTML5? Technically, the Google homepage just uses the HTML5 doctype — the rest of the page is actually quite archaic (and invalid) code — but other Google apps take advantage of HTML5 much more.
Gmail, one of the bigger webmail apps on the web, uses HTML5’s offline storage mechanism to allow you to work with your e-mail even when you don’t have an internet connection. Google Docs also uses the HTML5 offline tools, as do the online office suite Zoho and the WordPress blogging system. Check out Mark Pilgrim’s excellent rundown on how to add offline support to your apps if you want to start using this feature).
Scribd’s new document reader: all web standards, no Flash.
Aside from video, HTML5 is replacing Flash in other ways. Document sharing site Scribd recently made a splash by announcing it will be switching its document viewer from Flash to HTML5 and web standards. Scribd is a great example of what is possible when combining HTML5 elements (primarily the Canvas element, which powers animations) with attendant tools like cascading stylesheets. Scribd makes especially nice use of the @font-face element to load fancy fonts, and it uses the new CSS 3 standard to power some animated transitions between pages.
The combination of tools allows Scribd to convert PDF files into pure HTML documents while maintaining the structural layout, fonts, embedded images and layered elements of the original.
They came from space, and the W3C spec: Canvas Invaders
While Scribd might have the best implementation of the canvas element we’ve seen, there are plenty of other very cool examples already on the web. The site Canvas Demos has collection of experiments with canvas, showcasing everything from online games to apps like Rainbow, a browser extension that can pull any color out of a website.
Probably the best-known examples of HTML5 on the web are the current video experiments by YouTube and Vimeo. In both cases, the HTML5 versions of the sites are still opt-in, and there’s no code to embed the HTML5 version of a video on your own site, but it’s a start.
Another aspect of HTML5 that browsers are beginning to support is a set of geolocation tools. Technically, the geolocation API is not part of the HTML5 spec, but it is governed by the W3C and will arrive alongside HTML5 the markup spec. Using the geolocation API, a web app running in the browser can obtain your whereabouts, making location-based web searches more relevant.
Click on the little circle above the yellow guy to tell Google Maps where you are.
Google Maps uses it. The site’s interface now offers a small circle icon just below the navigation wheel — click it and maps will zoom to your current location.
At the moment, the geolocation API isn’t widely supported by desktop browsers (only Chrome and Firefox 3.6+), but Google makes a plug-in called Gears which offers a fallback solution for older browsers.
That’s the tactic Twitter uses for its geo-aware tweets, tapping into the geolocation API when it’s available and falling back to Gears when it’s not.
In the end, one of the most powerful changes in HTML5 may not be as flashy as any of the examples listed above. HTML5’s biggest contribution to the web may well end up being its new structural tags, like <header>, <footer>, <section> and <article>.
These new tags allow web authors to better define their content, which means search engines will need to do a lot less guessing when they index the web. That will mean better, more relevant results and faster links to the information you want.
There are countless sites already using HTML5’s new tags, though you’d never know it without viewing the source of the pages. If you’d like to see some examples, head over to HTML5Gallery, which features hundreds of sites using varying degrees of HTML5.
HTML5 can also be extended to offer even more semantic structure through Microdata. Using standardized data formats (similar in many ways to microformats) websites can offer not only data, but definitions of what that data is.
Ultimately, microdata exists for the benefit of web browsers and search engines. Eventually, search engines could use microdata to find your friends on the web and browsers could use it to connect you with those friends no matter what flavor-of-the-month social site they might be using. To experiment with these extensions, head over to Google’s Rich Snippets Testing Tool.
While there’s no question that HTML5 is still in the experimental stage, it’s already gaining traction, and it’s doing a whole lot more than just playing video on your mobile phone.
The next version of Firefox is already in development, and Mozilla’s product director Mike Beltzner has posted his team’s vision of the shape Firefox 4 will take when it’s done.
The big news is that beta code is expected to ship next month, in June, and that Firefox 4 will hit the release candidate stage in October. Of course, those dates are subject to change (actually, change is almost guaranteed at this point), but that’s the plan as it stands now.
Beltzner outlines three key goals for Firefox 4: Making the browser faster, building up support for more powerful web standards like HTML5, and giving users full control over their online identities on the social web. That last one in particular is good news to us, as we’ve often advocated that identity belongs in the browser. Mozilla has been experimenting with different identity management techniques for the past year or so, and it’s good to see the company treating user identity as a primary “top 3″ feature. The whole web is social now, and it’s time the user agent starts really acting as the user’s agent.
Beltzner shared his slides, which I’ve embedded below. Also, if you’re using Firefox or another browser that supports native Theora video playback, you can watch this .ogg file.
Not only has a very public (and contentious) debate unfolded on the web about the efficacy of presenting videos using HTML5 instead of Flash, but momentum is gathering behind the nascent web standard.
From giant video sites like YouTube to Wikipedia, everyone it seems wants to get their video out of Flash and into native web formats. With Microsoft recently announcing it will support the HTML5 video tag in the coming Internet Explorer 9, expect even more sites to abandon Flash for native video.
So, you want in on the fun? Do you want to use some HTML5 video tags on your site right now? No problem. Fasten your seat belts, as we’re about to take a tour of the wonderful world of HTML5 video.
Browser Support for HTML5
First, let’s deal with some very basic stuff, like where this will work and where it won’t. As you can see in the table below, only the latest versions of most browsers support native video playback using HTML5’s <video> tag.
HTML5 <video> support by browser:
Since Firefox 3.0 and IE 7 & 8 lack any support for HTML5 video, you’ll have to come up with a fallback plan for serving video to those users. Depending on what you want to do you, could fallback first to Quicktime and then, failing that, to Flash. That’s the strategy used in Video for Everyone (note that as of v0.4, Video for everyone no longer falls back to QuickTime).
To keep things simple we’re just going to fall straight from HTML5 to Flash.
Formats, Codecs and Technicalities
The next thing you need to understand is what is actually happening when you load and play a video file in your web browser. You’re probably used to thinking of video as .mp4 or .mov files, but unfortunately it’s not that simple. The actual file formats are just containers. Think of them as a bit like a .zip file — they hold other stuff inside.
Each container holds at minimum one video track and, most likely, one audio track. When you watch a movie online, your video player (most likely Flash) decodes both the audio and video and sends the information to your screen and speakers.
Why does this matter? Well, because the process of decoding what’s inside the video container file varies. To know how to decode a movie, the player (which is your web browser in the case of HTML5 video) has to know which codec the movie was encoded with.
When it comes to web video there are two codecs to worry about: H.264 and Theora.
There’s a huge debate right now among web developers, browser makers and just about everyone else as to which codec is right for the web. We believe that a free, open codec without patent and licensing restrictions is the best solution for the web. Sadly, neither codec exactly fulfills that dream, so for now, let’s just skip the whole argument and be practical — we’re going to use both codecs.
Why? Well, have a look at the table below, which shows which codecs work where and you’ll quickly see that there is no one-size-fits-all-browsers solution. Only Google Chrome can play both H.264 and Theora.
Codec support by browser/platform:
So, you may be thinking … if HTML5 video doesn’t work in IE7 or IE8 and it means I’m going to have to encode my videos twice, then why bother at all? Well, the best answer is simple: mobile users. If you want iPhone and Android users to be able to see your video, HTML5 is the only way to do it — Flash support is coming to Android sooner or later but for now HTML5 is the only option, and we all know Flash doesn’t run on the iPhone or the iPad.
The HTML5 Code
Here’s how to actually embed your videos. First, we encode video in both .ogv and .mp4 containers. Encoding video is beyond the scope of this article, so instead we suggest you check out Mark Pilgrim’s online book Dive Into HTML5, which has a whole chapter devoted to understanding video encoding. Pilgrim’s encoding suggestions use free software to get the job done, and in the end you’ll have two files — one .mp4 and one .ogv.
Now it’s time to unleash those movies in pure HTML glory. Here’s the code:
Yes, that’s it. What we’ve done here is use the <video> tag to specify the dimensions of our video, and to denote that we want to use the browser’s default controls. Then, within the video tag, we’ve added two <source> elements which link to our video files.
The “type” attribute of the <source> tag helps the browser understand which file it should load. It’s a bit of an ugly chunk of code that needs to specify the container format, the video codec and the audio codec.
In this case we’ve assumed standard .ogv and baseline encoded H.264 video as per Pilgrim’s tutorial. See the WHATWG wiki for more information on which video types you can specify.
And there you have it — native web video, no plugins required.
Dealing With Everyone Else
What about IE7, IE8 and older versions of just about any other browser? Well, for those users, we’ll fall back on Flash. To do that, we just use an <embed> tag within our video tag:
Now any browser that doesn’t understand the HTML5 video tag will just continue on its way until it hits the object tag, which it should understand (note that the order, mp4 before ogv, is important for iPad support — Apple requires that mp4 be the first video file).
Of course for this to work you need a Flash video container. JW Player is one popular example, or you can roll your own using Adobe’s tools. Also remember that we still haven’t handled the case of an older version of Firefox with no Flash plugin installed (maybe your users are surfing your tubes with an outdated Linux machine). You can always add good old text-based links to the video files as a catch-all fix for anyone who can’t, for whatever reason, see either the HTML5 or Flash versions.
Embedding HTML5 video isn’t significantly more difficult than using Flash, especially if you’ve been using H.264 video files in your Flash player — which is exactly what YouTube has done with its HTML5 beta.
While we’re concerned about the licensing and patent requirements of H.264, it isn’t hard to notice that if you skip Theora and make all non-H.264 fall back to Flash, you’ve still saved yourself a considerable encoding headache. In fact, that’s probably the best practical argument against Mozilla and Opera’s refusal to support H.264.
This week’s Photoshop Contest was all about finding a scapegoat for the Gulf Coast oil spill. And enough of you have blamed it on the Jersey Shore cast that I’m starting to think you’re onto something. More »
Apple and AT&T, you are doing it wrong. That $30 iPad data plan is kind of OK. However, if you’ve a smartphone in Spain, you get a microSIM duplicate to share your existing internet data plan. All for free. More »
For the last few months we’ve been talking with publishers about ways to make it easier for them to use Living Stories, our experimental format for displaying news coverage, on their own websites. Today we’re releasing a Living Stories plugin and theme for WordPress. Now anyone who publishes through WordPress can use the plugin to organize coverage of an ongoing event on a single dynamic page.
We first showcased Living Stories in December through a two-month-long experiment with the New York Times and Washington Post. We got great feedback from both readers and publishers. Our next step was to open-source the Living Stories format, allowing publishers to build on it using Google’s AppEngine infrastructure. We then released a version of the code that runs independent of our infrastructure. Since then, a number of publications have shared their ideas for ways we can offer additional tools to help them create Living Stories.
The WordPress plugin is a direct result of those conversations. We hope the plug-and-play solution will make it easy for you to get a Living Story up and running in almost no time at all. Head to our documentation page for detailed instructions. If you have questions or feedback, feel free to leave us a note in our help forum. We’re looking forward to reading your stories and seeing how the Living Stories format evolves on WordPress.