Skip to Main Content

HTML 5 is the hot new buzz word these days, with all sorts of Web applications, Web browsers, and development tools touting their use of HTML 5. But when does the buzz start outgrowing the actual technology? In this article, I'll explain what HTML 5 is, and what it is not.

Let's start with some history. HTML 5, the next upcoming version of the document language in which webpages are written, was started in 2004 as a project called Web Applications 1.0. It was initially developed by a group of browser developers and other interested parties who were growing impatient with the direction and slow progress of the World Wide Web Consortium (W3C) on the official HTML standards. While the W3C was increasingly focusing its efforts on abstract data modeling theory, Web Applications 1.0 was more directly focused on delivering specific features that would be readily useful to Web developers. It quickly became clear that Web developers and browser developers alike preferred the Web Applications 1.0 approach, and the W3C eventually agreed to adopt the project and give it the full attention it deserved, under the name HTML 5.

Since its incorporation into the W3C standards development process, HTML 5 has undergone a variety of changes. Its scope and structure has changed, some parts have been shoved out into their own separate specifications, and features have continued to be tweaked or even completely redefined, based on implementation feedback. Today, HTML 5 is still very much a work in progress, and its specification continues to change on a day-to-day basis. Most Web browsers have begun to adopt parts of HTML 5, but they should generally be considered experimental at this point. Even though some sections have remained fairly stable over time, there's no guarantee that they'll remain unchanged in the final version of the standard.

So, what specific features does HTML 5 introduce? The answer is, too many to list here, but I'll attempt to cover a few of the highlights.

First of all, HTML 5 is the first version of HTML to clearly define how to parse an HTML file. That may sound like a pretty obvious thing to put into a language specification, but this is one area that clearly illustrates the difference between the W3C of old and the new HTML 5 group: theory versus practice. Previous versions of HTML were, in theory, based on a sort of meta-language called SGML. SGML is a language used to describe other languages (did I mention that the W3C likes abstract data modeling theory?) which formed the basis for HTML, XML, and a number of other markup languages. Unfortunately, SGML in all its full-featured glory is simply too complex to parse efficiently, so, in practice, Web browsers have always supported just the specific subset of SGML necessary to parse the types of HTML syntax that people commonly used. Often, browsers would break from the SGML standard in order to handle existing HTML content (including incorrectly-written HTML content) in a historically-consistent way or to match what other browsers were doing. HTML 5 tosses out the whole notion of being based on SGML, and it just gets into the nitty gritty of what browsers need to do to parse HTML.

Next up, HTML 5 has some new ways of structuring webpage content to help software understand what's what on the page. For example, up until now we have had the ability to set up six levels of section headings, using the elements <h1> through <h6>. Headings are useful for a number of applications, including screen readers and search engines. However, we run into some problems when we start including third party content in our webpages, such as in portals or elaborate content management systems, when the heading levels may become incorrectly stacked. If our sidebar is at heading level 2, but it contains a widget that has a heading at level 1, then a screen reader or search engine could think that the rest of the sidebar (and maybe even the rest of the page) is inside that widget. HTML 5 solves this by allowing heading levels to be "scoped" by using <section> elements, which basically means that all heading levels within that section element are seen as relative to the heading level that was already open when the section element started.

Video and audio content are finally being made first-class citizens in HTML, with the new <video> and <audio> elements. Historically, Web developers have had to rely on browser plugins like Flash or Quicktime to embed videos in webpages. YouTube still uses Flash for the vast majority of videos it serves. In HTML 5, we will be able to hook video files directly into a webpage without the use of third party plugins. This offers a number of benefits, from sheer convenience and reliability to richness of the experience. Since the browser is playing the video content directly, it is much easier for the webpage to interact with the video through JavaScript or CSS. This movement away from proprietary video plugins has been coupled with demand for a good non-proprietary video *format* as well. See my previous post on Google's new WebM format.

HTML 5 will also include a set of new form field elements to facilitate the input of e-mail addresses, URLs, dates, and other types of data, as well as attributes to automatically do the types of input validation that we are currently doing manually using JavaScript. It will include a <canvas> element which will provide new native graphical capabilities to Web applications. It will formalize a variety of features that Web browsers have implemented in the past but had never been standardized. It will also enable vector graphics (SVG) and mathematical formulas (MathML) to be directly embedded in a webpage in a cross-browser compatible manner. The W3C provides a more complete list of changes here.

Now, let's spend a moment to talk about what HTML 5 won't do.

Some of the "HTML 5 demos" that various vendors have released actually showcase features of the also-in-development CSS 3 specifications, various other upcoming standards, or proprietary features that the vendors would maybe like to become standards. Microsoft, Google, and Apple have all made HTML 5 demos that actually depend on non-HTML 5 features. Specifically, if you see a demo featuring whiz-bang animations, rounded box corners, and other fancy visual stuff, you're most likely looking at proposed CSS 3 features, not HTML 5. HTML 5 does include the canvas and video elements, but the rest of HTML 5 is fairly non-visual and thus doesn't make for visually impressive demos, hence the use of CSS 3 to compensate.

HTML 5 does not include any method for storing large amounts of data on the user's computer; that's a goal of a few separate proposed standards such as Web Storage, Indexed DB, and Web SQL Database. The Web Storage specification used to be a part of HTML 5, but it was moved out to its own separate specification as it became considered too big for the scope of HTML 5, and as the alternatives (Indexed DB and Web SQL Database) began gaining some support. Today, Web Storage has some support in the latest versions of all popular Web browsers, but the alternative database systems provide some capabilities that it doesn't, and browsers are currently split over which of the two to support.

In addition to the database features, other features that have been misattributed to HTML 5 include Web Sockets (bi-directional JavaScript-to-server communications), Web Workers (JavaScript threading), WebGL (3D canvas), and ECMAScript 5th Edition (new core JavaScript features). These are separate specifications which have no direct connection with HTML 5 and are being developed independently of the HTML 5 specification.

HTML 5 isn't putting an end to XHTML, although it is downplaying its significance. A general consensus seems to be forming over the idea that XHTML is useful when embedding HTML-like content inside another XML format, but that regular HTML is better-suited for webpages. This is a position I have personally supported for several years, and the W3C appears to be turning in that direction now, especially since HTML 5 is being helmed by Ian Hickson, a critic of the traditional use of XHTML in webpages.

Most importantly, HTML 5 doesn't make your Internet connection faster, make Web developers obsolete, or cause the sky to rain candy. When a buzz word starts to pick up steam, companies will use it in all sorts of twisted ways to promise things that won't actually happen. HTML 5 makes some reasonable improvements over HTML 4.01, it describes what browsers are already doing when they read webpages, and it allows browsers to natively do some of the things that we used to use Flash for. It's a good update to the standard, but you shouldn't expect it to perform miracles.

There isn't any firm date set for when HTML 5 will be considered finished. At some point, possibly in 2012 or later, the W3C will declare the specification a "Candidate Recommendation" which means they want Web browsers to implement it and give their feedback. Once the W3C feels confident that browsers are able to implement the entire specification, they will move it up the ladder to the final "Recommendation" status, which will signal that they feel it's ready for Web developers to use on public websites. Of course, there will always be developers who jump ahead and try to use HTML 5 before it's officially ready, especially since browser vendors are using HTML 5 as a marketing point today. Just keep in mind that the W3C standardization process is long and winding, and there will probably be some bumps along the way. <>