An Introduction to HTML5
HTML5 is the latest version of the language that serves as the foundation of the web. It’s the first major revision in over 10 years and as it’s gotten closer to its final form and more and more browsers begin to implement its features it’s become a source of intense interest and contention in the technology community. This article hopes to explain the realities of HTML5, dispel a couple of myths and shine some light on the future of the web.
To begin we’ll need to define what we’re talking about when we say “HTML5.” There is a specification to refer to and much of what falls under the HTML5 name lives in that spec. In addition, there are several related specifications and APIs that are lumped together and called “HTML5″ when people talk about these things informally.
So, conversationally, HTML5 consists of the following:
New Semantic Elements
HTML5 has introduced several new elements. They aim to introduce more meaning to markup and codify existing web development patterns. Some examples of these new elements are nav (for navigation), article, header and footer.
The idea is to identify common patterns and use them to impart real meaning on standard web page elements. So, instead of using a generic element like a div with an id of “header,” there’s a header element. This will allow for much smarter interactions between web browsers/search engine spiders and web content. For example:
- voice browsers could be set with special instructions for handling nav elements
- search engines could weight content in an article element more strongly on the assumption that it’s the most important content on the page
- mobile devices could have special rules for asides or navigation elements in order to enhance the usability of a site on a small screen
New Media Elements and APIs
Over the past few years, users have become accustomed to seamless audio and video on the web. Youtube has grown from nothing to a traffic behemoth based on the ease of consuming video.
Serving video, on the other hand is far more complicated. For now, the ubiquitous nature of Adobe’s Flash plugin has been leveraged to offer video content over the internet. While it works, going through a third party plugin to serve video isn’t the most efficient solution to what’s become central functionality on the web. It also places a lot of power in the hands of a private company. Adobe has been a reasonably benevolent master so far, but surrendering control of such a vital technology to any one company is dangerous.
Enter the new audio and video elements. Leveraging these developers can now provide audio and video using nothing but the browser’s native capabilities. Several sites are already experimenting with this like YouTube. This trend has been hastened by Apple’s decision to omit Flash support on the iPhone and the iPad.
Currently the new video and audio elements are supported by the latest versions of Safari, Firefox, Opera and Chrome. Support has also been announced for Internet Explorer 9.
That’s a great start.
Unfortunately, there’s ongoing controversy about the codecs that each of those browsers support. For the time being, there are two codecs in play- h.264 and Ogg Theora. Without devolving into a lengthy discussion of an issue covered in detail elsewhere, Firefox is sticking with Ogg Theora because of license and patent issues with h.264. Opera is also exclusively supporting Ogg. Microsoft, and Apple are throwing their support behind h.264, which is a higher quality solution. Chrome supports both.
This issue adds a degree of difficulty to video implementations. While some organizations have the infrastructure to output and host two separate video codecs, most don’t so the organizations are forced to choose between the two. With that in mind, h.264 is the smartest choice as it brings video to Apple’s devices.
The hope is the W3C Working Group and the browser vendors will come together on a codec everyone will support. The rumor that Google will open source the excellent VP8 codec is potentially welcome news on that front.
Features for Web Applications
Several new APIs have been introduced that open up a wide range of possibilities for web application developers.
The most exciting might be the new canvas element and related canvas 2d API. Canvas gives developers the ability to craft visually rich experiences without relying on 3rd party plugins (most often, Flash.) Developers have taken to this with real zeal and have already produced some remarkable results like this canvas port of Quake 2.
The latest versions of Firefox, Opera, Chrome and Safari all natively support canvas and with the help of the explorercanvas library, even Internet Explorer can join in the fun.
Geolocation is another area of interest to developers as location-based apps and data have been touted as the “next big thing” for while now. Geolocation is also a perfect example of a technology that gets lumped in with the rest of HTML5 that isn’t actually part of the specification. It’s a separate document from the Geolocation Working Group. Regardless of where it lives, it’s
so ingrained in the conversation Mark Pilgrim’s forthcoming book on HTML5 even includes a Geolocation chapter.
Geolocation is also a technology just beginning to gain support, with desktop support only in Firefox and mobile support from the Android browser and Safari on the iPhone.
Beyond those two notables there are several other innovations that might not be as flashy but will allow developers to make some interesting enhancements to the way web applications work. These include:
- Offline storage, so you work on your web app on the plane, with or without wi-fi
- Inline content editing
- Native drag and drop
- New application specific elements and input types. Some examples of the element side are
menu(for dynamic menus,) andprogress(for progress bars.) New form inputs includerange(for a slider,)date(for a date-picker) andcolor(for a color-picker.)
What’s the Catch?
As with anything on the web, it’s not as simple as defining a specification and getting on with the business of using the new elements and APIs.
Some parts of the specification, like the new semantic elements are safe to use right now with relatively little pain and minimal risk. Why? Support, in the sense that the new elements don’t break for the end user even if they don’t have semantic value in the browser, is around very high and the code to make that support happen is minimal. Simply insert a few lines of JavaScript to the head of your document or include a small JavaScript library and you can use headers, footers, asides and all the rest of the new semantic elements without fear. Browsers with support for the new elements will provide the enhanced user experience and browsers that don’t have support will be none the wiser.
Beyond that the picture gets murky. On the one hand we have progressive browsers like Chrome, Firefox, Opera, and Safari that are in an arms race of sorts, trying to be the first out off the block with HTML5 features. This means developers have a live lab to test out new features and some of them are working their way into production sites as enhancements for some lucky users.
On the other hand we have three versions of Internet Explorer (6,7, and 8 ) with large market shares and only one of them has support for any HTML5 features of note and even that (version 8 ) fails to bring on board some of the most exciting features. While there are some workarounds that bring the Microsoft browsers up to date for certain technologies it won’t be until Internet Explorer 9 (due sometime in 2011) supplants the three previous generations of Microsoft browsers that we can
fully unleash the power of HTML5 to the widest possible audience.
Which isn’t to say all is lost. In some cases the solutions are solid and the pay-off is high enough that taking the leap into more advanced features of HTML5 can be worthwhile. For one example, Youtube, Vimeo and Brightcove are all taking initial steps to leverage the power of HTML5 video. Many more will follow.
Mobile/Tablet
On a positive note, beyond just video, the power of HTML5 is already being unleashed in the smartphone/tablet space. Owing to the lack of mobile flash support and the presence of robust Webkit-based browsers in Android, Apple and Palm’s smartphones, HTML5 applications and media are strong in the mobile space.
Because of this, there’s a move in some circles away from making native applications to creating web based mobile apps instead. This allows for a broader audience as you’re no longer tethered to a specific device or OS. The downside is not being able to leverage some of the phone’s features like GPS or the accelerometer.
HTML5 is also the cornerstone technology for Apple’s recently announced iAd platform.This is another volley aimed straight at one of Flash’s strongholds- rich advertising experiences.
2022
Many bits have been spilled over a statement made by HTML5 editor Ian Hickson that HTML5 would be “done” by 2022. It’s an easy soundbyte to riff on (and many people have) which is unfortunate because it distorts the perception of HTML5 as a living, breathing technology in active development. Without getting into too much detail about the ins-and-outs of specification writing and the goals of the working group (as in what they mean by “done”), the reality is that many parts of HTML5 are basically stable right now and the specification will likely be a Candidate Recommendation as early as 2012. So while the 2022 number makes some people giggle, the real finish line is right around the corner.
Flash is Dead, Right?
No. Not for the foreseeable future at least.
Even based on the most aggressive projections for HTML5 adoption, as long as people support legacy Microsoft browsers, Flash is going to be a big part of the Internet. The standard pattern for HTML5 video for example, falls back back to Flash to extend support to the largest possible audience.
Do many parts of HTML5 do away with the need for Flash? Sure, but the same could be said for the advances in JavaScript interaction we’ve seen over the past few years and those haven’t killed Flash. They’ve just given open-minded developers and organizations more options for programming the user interface. HTML5 enriches that toolbox significantly.
Where do we go from here?
We watch, experiment and learn.
Many developers are excited by HTML5 so there’s a vibrant community of people the world over, experimenting with, commenting on and testing out the new specification. This will continue. As we’re witnessing now, where possible these experiments will feed into production code, strengthening our confidence with the new technologies
and feeding back into the specification itself, making it stronger.
The ongoing shift to mobile development will accelerate the tire-kicking of the spec and the release of Internet Explorer 9 (with many planned HTML5 features) will unleash it to an even wider audience.
Staying ahead of the curve on this is going to be vital, especially over these formative years. At some point in the next two or three years HTML5 will reach a critical mass and begin to dominate the web. Any organization with a stake in the
web needs to be prepared for that shift.

















