Yes, You Can Use HTML 5 Today!

The blogosphere was jerked into excitement when Google gave a sneak preview of its new service, Google Wave. Only the select few have an account, but there’s an 80-minute video about it on YouTube for the rest of us. The service is an HTML 5 app, and so HTML 5 has gone from being too far away to care about to today’s hot topic.

There have been many changes to the HTML 5 landscape since my colleague, Lachlan Hunt’s 2007 article on A List Apart, A Preview of HTML 5. Let’s see what’s happening in the world of HTML 5.

What Is It?

To some, it’s an outrageous attempt by browser manufacturers to foist what they want onto developers. In SitePoint’s HTML 5: Now or Never? article, Tommy Olsson described it as “an abomination … it mocks everything I consider important on the Web.” Others see it as the way forward for developing powerful multimedia web apps on an open architecture, without Flash or Silverlight or similar proprietary technologies. Doug Schepers, the W3C’s Team Contact for the SVG and Web Apps Working Groups says, “HTML 5 is not a technical achievement, it’s a social movement.”

The reason that opinion is so divided is that HTML 5 is more than just a markup syntax for documents, like HTML 4 is. One clue is in the working group’s original name, before it was brought into the W3C camp: Web Hypertext Application Technology Working Group. The original goal for HTML 5 was to make it easier to develop Web applications. There’s evidence of this in the rash of new JavaScript APIs and support for offline development, some of which are already available in a browser near you.

Markup

We’ll start by thinking about marking up a typical blog today. Like the vast majority of sites on the Web, blogs comprise a header, some navigation (often a sidebar or two), a main content area, and a footer:

Currently, there are no ways in HTML 4 to mark up these elements in a semantic fashion – that is, HTML 4 offers no footer or header elements of its own. Instead, they’re usually wrapped in a generic div element, a technique which is described in the HTML 4 specification:

The DIV and SPAN elements, in conjunction with the id and class attributes, offer a generic mechanism for adding structure to documents. These elements define content to be inline (SPAN) or block-level (DIV), but impose no other presentational idioms on the content. Thus, authors may use these elements in conjunction with style sheets, the lang attribute, etc., to tailor HTML to their own needs and tastes.

When developing the HTML 5 spec, the editor, Ian Hickson of Google, analyzed over a billion web pages to find out how authors were actually using these elements. He discovered that in the top 20 class names used in the markup for this huge set of data were classes for common requirements: footer, header, nav, menu, content, and main.

So the HTML 5 spec has a host of new, structural tags such as header, footer, nav, article, and section, which fit these common requirements and allow us to mark up our archetypal blog with more meaningful elements, like so:

What’s really interesting is that we can use HTML 5 elements right now, even though the main browsers are yet to support HTML 5, because CSS allows you to style anything.

By default, CSS assumes that an element is inline. For HTML 4 elements such as DIV, the browser’s own default style sheet overrides that default, but for our HTML 5 elements, we need to do that manually. The following CSS rule does the trick:

header, footer, nav, section, article {
display:block;
}

Then we can add style rules – floating, background colors, margins. I’ve put together an example; let’s check it out!

Depending on which browser you use, you will either see a colorful layout, or no styles at all. Here’s how it should look, as seen in Safari 4:

Older versions of the Gecko rendering engine, currently used in Firefox 2 and Camino, have a parsing bug which means Gecko closes an unknown element when it sees the start tag of a block-level element like p, h1, or div. There are workarounds, but as Firefox 3 is out, Camino 2 is in beta, and both browsers’ users tend to upgrade quickly, it’s safe to assume that the problem will be history by the time you start building HTML 5 sites for the real world.

There’s a more serious problem with our old friend, Internet Explorer. It refuses to display this basic CSS until you prod it with a pointy JavaScript-shaped stick. Yes, you heard right – you need some JavaScript to make CSS style your HTML. Over the page, we’ll find out what we need to do to make HTML 5 elements work in IE 8.

Here’s how IE 8 displays our example at the moment:

We’d like IE to recognise that these elements exist. At the top of the page, we need to add the following JavaScript, which is simply a series of document.createElement statements:

<!--[if IE]>
<script>
document.createElement("header");
document.createElement("footer");
document.createElement("nav");
document.createElement("article");
document.createElement("section");
</script>
<![endif]-->

I’ve surrounded it with a conditional comment, so the other browsers can ignore the IE-only code. Now, lo and behold, your page styles in IE – if you’re using IE, you can see the fixed example here.

Of course, this workaround only helps if your IE-using visitors have JavaScript turned on, but for a fully-fledged HTML 5 application, the whole site would be unlikely to work if you have JavaScript turned off.

Let’s have a more detailed look at what each of these structural tags are for, and meet some new ones.

header and footer

header is our new element for headers, oddly enough. The natural place to use this element is for the main banner at the top of your web site, but a page can certainly contain more than one header. You’ll notice that we have multiple articles in our rudimentary blog post; each of these can have another header that contains the heading, byline, and date for that article.

The same goes for footer, too. There’s a footer at the bottom of the whole page, but there’s also a footer at the bottom of each article, listing the category that the article is in and how many comments it has. So each individual article is marked up as follows:

<article>
<header>
<h1>Header for article 2</h1>
<p>Posted 14 June 2009</p>
</header>
<p>article 2</p>
<footer>Posted in the "trains" category by Thomas T. Tang-Kenjin</footer>
</article>

This is perfectly valid HTML 5: on the topic of footers, the spec says “the footer element represents a footer for the section it applies to,” and also: “Footers don’t necessarily have to appear at the end of a section, though they usually do.” Check out the source of our example and validate it. The additional headers and footers can be very easily styled with simple descendent selectors – article header and article footer. Our third example shows a blog with two entries, each with its own header and footer elements.

There’s a newly proposed element for grouping headings and subheadings together – hgroup – that looks like this:

<header>
<hgroup>
<h1>HTML 5</h1>
<h2>The mark-up language for fun and profit</h2>
</hgroup>
</header>

It seems unlikely to me that the hgroup element will make it through various revisions of the spec, and I struggle to find a real use case for it in this example.

nav

nav is used to indicate navigation areas. There can be more than one nav element in a page, just as there can be primary and secondary nav on a web page, and it’s unnecessary to put every group of links into nav elements. As the spec says:

“Not all groups of links on a page need to be in a nav element – only sections that consist of primary navigation blocks are appropriate for the nav element.”

I think that’s ambiguously written; what I think it should say is that “only sections that consist of blocks whose primary purpose is navigation around the site are appropriate,” so that lists of links to sponsors or advertisers could be distinguished from a site’s navigation.

You can, if you wish, include primary navigation in the header element, but this is optional. Just like now, navigation is usually marked up as an unordered list of links or, in the case of breadcrumb trails, an ordered list.

article

article represents a standalone part of your content. According to the spec, an article could be “a forum post, a magazine or newspaper article, a Web log entry, a user-submitted comment, or any other independent item of content.”

What’s particularly interesting from the point of view of a blog is that a user-submitted comment is an article too, so you would nest each comment inside the post’s article element. The spec also says:

When article elements are nested, the inner article elements represent articles that are in principle related to the contents of the outer article. For instance, a Web log entry on a site that accepts user-submitted comments could represent the comments as article elements nested within the article element for the Web log entry.

Here’s the markup for an article with two comments:

<article>
<header><h1>Header for article 2</h1>
<p>Posted 14 June 2009</p>
</header>
<p>article 2</p>
<article>
<p>Comment 1</p>
</article>
<article>
<p>Comment 2</p>
</article>
<footer>Posted in the "trains" category by Thomas T. Tang-Kenjin</footer>
</article>

Our fourth example shows comments within a blog entry.

aside

We left aside out of our basic example. It’s a useful if confusing beast: I’ve seen people assume it’s the way to mark up a sidebar, which on a web page is usually a navigation menu and thus best marked up with nav.

On the topic of aside, the spec says:

“The aside element represents a section of a page that consists of content that is tangentially related to the content around the aside element, and which could be considered separate from that content. Such sections are often represented as sidebars in printed typography … The element can also be used for typographical effects like pull quotes.”

figure and legend

The figure element is often used to wrap a picture and a caption, called legend, and therefore associates them. The spec says it may be:

… used to annotate illustrations, diagrams, photos, code listings, etc, that are referred to from the main content of the document, but that could, without affecting the flow of the document, be moved away from that primary content, e.g. to the side of the page, to dedicated pages, or to an appendix.

Let’s see one in action:

<figure>
<img src="bruce-lawson.png">
<legend>Bruce Lawson, a sort of modern-day Clark Gable
<small>Photo copyright Bruce's mum, all rights reserved</small>
</legend>
</figure>

You’ll note that I’ve also used the small element – unlike HTML 4, this is defined as a way to represent “legalese describing disclaimers, caveats, legal restrictions, or copyrights. Small print is also sometimes used for attribution.” In other cases, figure is remarkably close to the aside element – too close in my opinion.

section

The section element divides the page if there are no more appropriate structural tags above. It’s more than just another kind of div, though – section imposes a kind of hierarchy upon the content. In a purely HTML 5 world, you only use h1 (for backwards compatibility), and the outlining algorithm works out the heading level from its context within the page’s sections.

So:

<body><h1> is a heading 1
<body> ... <section><h1> is a heading 2
<body> ... <section><section><h1>is a heading 3, and so on.

In this way, you can have more than six levels of heading. However, it’s best to continue to use h1–h6 for now, with sections if you choose. Assistive technologies such as screen readers have yet to catch up to the new outlining algorithm, and a proper hierarchy of headings is vital for blind users to navigate pages.

New Features for Web App Developers

With HTML 5’s emphasis on web application development, there’s plenty of new features for developers to use, some of which we can use today:

• A 2D drawing API for scripting graphics using the new canvas element, which is supported in all the major browsers except for Internet Explorer.
• registerProtocolHandler and registerContentHandler, which allow web applications to register for certain protocols or MIME types. Both are available in Firefox.
• A manifest caching mechanism to support offline web applications, available in Firefox and Safari.
• Video and audio APIs. The majority of the API works in Firefox, Opera (experimental build), and Safari – although Safari only uses Apple’s proprietary .mov format, rather than the open-source Ogg formats supported by Firefox and Opera.
• window.postMessage: cross-document messaging implemented in all major browsers.
• history.pushState to enable better back-button support in Ajax apps. (No implementations yet, but window.onhashchange is supported in IE8.)
• A drag and drop API with a draggable attribute, supported in Firefox 3.5.
• An editing API that hooks into the contenteditable attribute allowed on any element, already in all major browsers.
• Client-side persistent storage using key/value pairs and support for embedded SQL databases: key/value pairs are in Firefox, Safari, and IE8, while SQL is supported only in Safari at this point.

(Note that browsers are adding support thick and fast – this is a snapshot at June 2009. Expect it to change month-by-month.)

Forms

An exciting development in HTML 5 is in the realm of Web forms. For space reasons, we’re unable to cover forms in any great detail. However, if you’re using Opera 9.6, check out my forms demo – Opera is currently the only browser with full support – to see how the browsers will validate required fields, datatypes such as email, URLs and any pattern without JavaScript. You’ll also see that the browser can now natively provide a date selection calendar, and set autofocus against a field. Be sure to view the source to see how it was put together. When broader support for these elements is introduced, we’ll be able to start playing with these too.

Become Involved – Have Your Name in Lights!

Hopefully, this brief article has shown you enough of the structural aspects of HTML 5 to prove that it’s good to start thinking about it now; it’s being added to browsers and used as we speak. Sure, at the moment it’s being used mostly for personal sites, but that’s how CSS-only layouts started and now they’re mainstream. Structural elements like article or nav can be used right now, and with browsers adding support for more features all the time, now’s a great opportunity to get started with HTML 5.

If you fancy becoming more involved, there’s still time – try using it and giving feedback to the specification group via the WHAT-WG mailing lists. The editor, Ian Hickson, has put out a call for people to review the spec – looking for confusing items, typos, and other small problems. If you find one, you’ll be mentioned in the acknowledgements. There’s plenty to do, so dive in!