The New HTML5 Markup Elements

HTML5 intro­duces a whole bunch of new ele­ments. The first ones I’ve looked at are the markup ele­ments — those used to organ­ise the con­tent of a doc­u­ment or the text within it. Look under the hood of many pages and you’ll find that the page nav­i­ga­tion is con­tained within a div often with an id or class named “nav­i­ga­tion” or “nav”. There’ll be sim­i­lar div ele­ments for the main body, side­bars, foot­ers and so on. Many of the new ele­ments will be used to replace these non-semantic div ele­ments. With HTML5 we now have seman­tic navigation, article, aside and so on. The rest appear to be a mixed bag that can rep­re­sent data “types” or group together related con­tent and for now at least, are largely unsup­ported by browsers. Any­how, with­out fur­ther ado, on with the show…

sec­tion & article

These two tags appear to be respon­si­ble for the most con­fu­sion and argu­ments, largely because they are so sim­i­lar. They’re both used for group­ing related con­tent with article defined as being for “self con­tained” con­tent. To me, the section ele­ment has a more generic name and can there­fore be used in more sit­u­a­tions whereas article has a more spe­cific name and there­fore more spe­cific use. It’s a very sim­plis­tic way of look­ing at things, but right now, it helps me think out where I might use them. e.g. in a blog, you might have a section around the main body of con­tent and within that, each post would be an article. You might also use a section within an article to con­tain the com­ments (though maybe they should be an aside?)

One of the best expla­na­tions I’ve seen comes from Jean Galea who says

Think of a news­pa­per. The paper comes in sec­tions. You have the sports sec­tion, real estate sec­tion, maybe home & gar­den sec­tion, etc. Each of those sec­tions, in turn, has arti­cles in it. And, some of those arti­cles are divided into sec­tions themselves.

What I’m now won­der­ing is how you dif­fer­en­ti­ate section from the good old div? The way most peo­ple are look­ing at it, div con­veys no mean­ing and is just used to group together other ele­ments for pur­poses of styling. A vari­a­tion on this was that a section should (or could) have a title whereas a div is just for block­ing off a bit of con­tent. I reckon if the div ele­ment had been called division I’d prob­a­bly not be writ­ing this now…


The aside ele­ment is used “for con­tent that is tan­gen­tially related to the con­tent around it” and it looks like it will be mostly used for mark­ing up side­bars. How­ever, in the con­text of an article it can be used for related read­ing, glos­saries and so on and in fact, this was the orig­i­nal pur­pose of the ele­ment. Basi­cally, it’s for stuff that is nice to have but that you can safely ignore. e.g. as I men­tioned above, I think that for a blog post, com­ments could be placed within an aside.

header & hgroup

The new header ele­ment is used to group together related head­ing ele­ments. For a web page, this will usu­ally be the stuff at the top of the page and might include the sites name, maybe a tag line, some nav­i­ga­tion etc. Within an article (e.g. a blog post) it might con­tain the title plus addi­tional meta data such as the author and date/time published.

There’s another new head­ing related ele­ment. The hgroup ele­ment “is typ­i­cally used to group a set of one or more h1-h6 ele­ments — to group, for exam­ple, a sec­tion title and an accom­pa­ny­ing sub­ti­tle”. There’s some exam­ples of how to use hgroup on the HTML5 Doc­tor site but to be hon­est it still doesn’t make much sense to me. They use a hgroup to group together an article’s title with its “sub­ti­tle”. The prob­lem I have is more to do with the use a h2 ele­ment for a “sub­ti­tle”. I doubt that there’s any­thing wrong with that, but to me, h2s are for a sec­ond level of head­ings rather than a sub­ti­tle. I sup­pose if you are going to use h2 for a sub­ti­tle then group­ing them together with a hgroup ele­ment at least shows the author’s inten­tion but why not just wrap it in a header instead? It’s good to see I’m not alone and that peo­ple far more knowl­edge­able than me are also won­der­ing about this.

There seems to have been a lot of to-and-fro’ing over the inclu­sion of hgroup in the HTML5 spec. For now at least, it appears to be in but I’m not sure if I’d ever use it.


The footer ele­ment seems pretty sim­ple and unam­bigu­ous. It’s for stuff that comes at the end of a doc­u­ment or section or article. On a web page, the footer usu­ally con­tains some nav­i­ga­tion ele­ments, some cred­its and other flot­sam and jet­sam that needs to go some­where. For a section or article (e.g. a blog post) it might be tags, cat­e­gories and so on.


The nav ele­ment is used to iden­tify “major nav­i­ga­tion blocks”. What exactly con­sti­tutes “major nav­i­ga­tion” seems to be left to inter­pre­ta­tion. It sounds like the nav­i­ga­tion found at the top of most web pages would be a dead cert for the nav ele­ment as would sec­ondary nav­i­ga­tion — the sort you usu­ally find at the top of a left or right hand side bar. The spec makes an exam­ple of the nav­i­ga­tion you often find in a site footer (to copy­right and terms of ser­vice pages etc) as nav­i­ga­tion that doesn’t need to be wrapped in a nav ele­ment. Other pos­si­ble uses could be for table of con­tents, bread­crumbs, pag­i­na­tion and so on. I sup­pose it’s for the nav­i­ga­tion that peo­ple use on a the day-to-day basis to get around a web site.


The mark ele­ment is intended for “text that should be high­lighted”. The spec adds:

When used in a quo­ta­tion or other block of text referred to from the prose, it indi­cates a high­light that was not orig­i­nally present but which has been added to bring the reader’s atten­tion to a part of the text that might not have been con­sid­ered impor­tant by the orig­i­nal author when the block was orig­i­nally writ­ten, but which is now under pre­vi­ously unex­pected scrutiny.

How does this dif­fer from strong or em? My take is that mark is more ephemeral — that it is used for high­light­ing text that is impor­tant for the user right now, but might not be impor­tant the next time they visit the page. A sim­ple exam­ple of where it might be used would be to high­light search terms.

fig­ure & figcaption

The figure and figcaption ele­ments appear to be fairly straight­for­ward and are intended to “mark up dia­grams, illus­tra­tions, pho­tos, and code exam­ples”. You use figure to group together an image and a cap­tion as a sin­gle log­i­cal entity with figcaption used to mark up the actual cap­tion. As with most of these ele­ments, it seems that there’s been a bit of dis­cus­sion about exactly how this should be done. In this case the dis­cus­sion cen­tred around how the cap­tion should be marked up — should an exist­ing ele­ment be used or should a new one be cre­ated. In the end, it looks like they’ve gone with the lat­ter option.

And the rest?

There are a few other new ele­ments such as time and ruby but they don’t have much in the way of sup­port at the moment and I’m not even sure if they’re finalised or whether there’s still some argu­ing to do yet. As such, I’m going to move on to other things. Next up, the new HTML5 form elements…

Some Links

I found these use­ful whilst writ­ing this…
Dive into HTML5
W3C Schools List of New Ele­ments
HTML5 Doc­tor
Com­par­i­son of Browser Support

And here are a cou­ple of gallery/example sites…

Contact-Form-7 with IIS

I’ve been using the “Con­tact Form 7″ plu­gin, but found I had a prob­lem with a WP install on a Win­dows IIS host. The prob­lem seems to stem from perma­links not work­ing prop­erly with IIS and hav­ing to cre­ate a file to fake them by redi­rect­ing 404 errors to the right place — this appar­ently gets in the way of post­ing the form. A quick google threw up this sup­port topic and a few posts sug­gest chang­ing contact-form-7/includes/classes.php. The sug­gested changes didn’t work for me, but I found that set­ting the form sub­mit url to the “dirty” page url (i.e. /index.php?page_id=11) plus the form name did the job. So, instead of

$url = wpcf7_get_request_uri();

I now have

$url = ‘/index.php?page_id=11#wpcf7-f1-p11-o1’;

Good enough rea­son to stick with linux web servers that guar­an­tee Apache as the web server rather than IIS!