Firstly what we’ll do is use the
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
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”,
<divid="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 4has no other way to code them. HTML 5 has new elements for distinguishing these logical areas:
footer and friends. (There’s more on this in an artice by Lachlan Hunt on A List Apart: A Preview of HTML 5.)
It’s a simple matter to change the HTML
divs 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
navelement 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.
So I amended the email input field in the comments to be
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),
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
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.