This article is an edited version of two articles published by Opera Web Evangelist, Bruce Lawson, reproduced with permission. All rights reserved.

This article was updated 27 May 2014 to use the <main> element to denote the main content of the page (was previously <div>).

Much of HTML 5’s feature set involves JavaScript API s that make it easier to develop interactive web pages but there are a slew of new elements that allow you extra semantics in your conventional Web 1.0 pages. In order to investigate these, let’s look at marking up a blog.

Firstly what we’ll do is use the header , footer , main and nav elements to mark up the broad structure of the page. Doing this will make your site more accessible to real people who use some assistive technologies.

Next, we’ll make the blog comments form much smarter by using the new data types and built-in validation available in HTML 5-aware browsers.

Then we’ll do some work on the guts of the page, using HTML 5’s article elements to better mark up blog posts and comments and show how to use the sectioning elements to better structure accessible hierarchical headings on sites that are CMS -driven. As blogs are chronologically ordered, we’ll see what HTML 5 offers us for representing dates and times.

So take the phone of the hook, and make a cup of tea and we’ll get started.

Setting the DOCTYPE HTML 5, when used as plain HTML rather than its XHTML 5 sibling doesn’t need a DOCTYPE. But all browsers do, otherwise they go into Quirksmode, which you don’t want: the collision of HTML 5 and Quirksmode is like matter and anti-matter meeting, and will cause a negative reality inversion that will make your underwear catch fire. You’ve been warned, so at the top of your document, you need the line <!DOCTYPE html> . Some sites “use” HTML 5, when in actual fact all they’ve done is take their existing code and change the DOCTYPE. That’s fine and dandy if you’ve been using valid, semantic code as HTML 5 is very similar to valid HTML 4.01. Eric Meyer mentions small differences like “not permitting a value attribute on an image submit”, and there are a few differences between the languages, summarised in the document HTML 5 differences from HTML 4. However, I don’t want simply to rebadge my existing code, but to use some of the new structural elements now.

Using some new structural elements My blog – like millions of others – has a header denoted by <div id="header"> , a footer <div id="footer"> , some articles (wrapped by an area called “content”, <div id="content"> ) and some navigation (wrapped up in an area called “sidebar” <div id="sidebar"> ). Most sites on the Web have similar constructs, although depending on your choice they might be called "branding" or "info" or "menu", or you might use the equivalent words in your own language. Although these all have very different functions within the page, they use the same generic div in the markup. as HTML 4 has no other way to code them. HTML 5 has new elements for distinguishing these logical areas: header , nav , footer and friends. (There’s more on this in an artice by Lachlan Hunt on A List Apart: A Preview of HTML 5.) The overall aim is to replace this structure: with this: It’s a simple matter to change the HTML div s into the new elements. The only difficulty I had was deciding which element to use to mark up my sidebar, as it also includes a search field and “colophon” information as well as site-wide navigation. I decided against the aside element, as the spec says it “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”, but it’s nevertheless content rather than navigation. So I decided to go for the nav element as the closest fit. I’ve wrapped the main content in a <main> element, which maps to the ARIA role=main so that screenreaders and other assistive technologies can easily find the main content. Note that you should only use this element once per page. New form attributes As well as the main structural item on the page, I’ve added some new attributes on input elements in the comments form. HTML 5 was designed to reflect what developers actually do rather than to reflect a philosophical purity, and that’s very clearly manifested in the new attributes which mean the browser takes up much of the work currently done by developers re-inventing validation routines in JavaScript. (Extending forms functionality was how the HTML 5 spec began). So I amended the email input field in the comments to be input type="email" which means that when the user submits the form, an HTML 5-aware browser will use built-in validation routines to check that it’s in the correct format, without any JavaScript. Check it out in the current version of Opera, as that the only full implementation at the time of writing (June 2009), and note that it also adds a “mail” icon in the input field as a cue to the user. There are similar input validation routines triggered by some of the new input types, such as url (which I use on the field that asks for the user’s web address), number and pattern which compares the input with an arbitrary regular expression. Another good example is input type="date" , which pops up a calendar widget/ date picker when the user focusses on the input field. You can test the date picker, or here’s a screenshot from Opera 9.6: A very useful new attribute I used on both input fields for commenter’s name and email address, and the comment textarea was type="required" which generates a message on submission if the fields are left blank. Each different localisation of a browser would need to have a different message, and it’s not (so far) customisable by the developer. The good thing with all this new form fabulousness is it’s all formed around new attributes on an exisiting element, so people using older browsers just see a plain old input field. A note on screenreaders and HTML 5 I hope screenreaders are ready for these new interactions; I asked the html 5 group to formally invite screenreader vendors to participate in the specification; to my knowledge, none have done so. However, using <header<, <footer>, <nav> and <main> gives real benefits to some assistive technology users.

Laying out the new elements It’s not too hard to layout the new elements. In all the non- IE browsers, you can lay out anything using CSS – even a nonsense element. One gotcha is that that the current crop of browsers have no “knowledge” of these elements, although support is improving all the time. All browsers have default settings for the elements they “know about”—how much padding, margin they element gets, does it display as a block or inline?. (Here’s a sample default stylesheet.) Unless over-ridden by CSS , these defaults apply. But the browsers don’t know about header , nav and the like, so have no defaults to apply to them. I got terrible rendering oddities until I explicitly told the browsers header, footer, nav, article, main {display:block;} IE layout There’s one gotcha about styling HTML 5 pages in IE : it doesn’t work. You can force it to quite easily with a JavaScript hack document.createElement('element name') . (Lachlan Hunt gets to the bottom of why IE needs this.) For your convenience, Remy Sharp has written an HTML 5 enabling script which I use in the header to conjure all the missing elements into existence all at once. But let’s be clear: this won’t work if your IE user doesn’t have JavaScript turned on. How much of that’s a big deal that is for you to decide. Pragmatically, it seems to me that the sites that will benefit the most from HTML 5’s new “Ajax”-style features, such as drag-and-drop, are the sites that currently have no hope of working without JavaScript. Firefox 2 and Camino 1 layout Firefox 2 and Camino 1 both use Gecko 1.9 which has a bug and so gets grumpy if you don’t serve the page as XHTML . (Go figure; that’s almost enough to trigger a negative reality inversion and you know how bad that can be). However, Firefox and Camino users upgrade frequently so Firefox is in version 3, while Camino 2 beta is out, so the problem will soon cease to exist. (Read more at How to get HTML5 working in IE and Firefox 22 by Remy Sharp.)

What’s the point of those new structural elements? Well, they add semantics to the page. The browser now knows which area of your site is the header or the footer because there are header and footer elements, whereas div might be called “branding” and “legal”, or even “en-tete” and “pied-de-page” or “kopfzeile” and “fusszeile“. But so what? Robin Berjon expressed it beautifully in a comment on A List Apart : Pretty much everyone in the Web community agrees that “semantics are yummy, and will get you cookies”, and that’s probably true. But once you start digging a little bit further, it becomes clear that very few people can actually articulate a reason why. So before we all go another round on this, I have to ask: what’s it you wanna do with them darn semantics? The general answer is “to repurpose content”. That’s fine on the surface, but you quickly reach a point where you have to ask “repurpose to what?” … I think HTML should add only elements that either expose functionality that would be pretty much meaningless otherwise (e.g. canvas ) or that provide semantics that help repurpose for Web browsing uses. In my view, there are a couple of things I want to do with those semantics. The first is for search engine use; it’s easy to imagine Messrs Google or Yahoo! giving lower weighting to content in footer elements, or extra weight to content in the header . The second reason is to make the site navigable for people with disabilities. People with learning difficulties might instruct their browser always to put the articles before the navigation, for example. User agents might very well have a keyboard shortcut which jumped straight to the nav for example, or jumped straight past the navigation, in a programmatic implementation of “skip links“. Which brings me to…