HTML 5 introduces some new elements to divide pages in semantic blocks. In HTML 4, there are divs for that purpose.

<div id="header">...</div>
<div id="footer">...</div>

Etc. In HTML 5 we can use header and footer elements instead. In HTML 4 the semantic meanings used to be in id and class names, in HTML 5 they are in the element names (but semantics can still be enhanced of course by using well chosen id and class names).

HTML 5 also introduces a nav element. In the HTML 5 specification, nav is defined as follows:

The nav element represents a section of a page that links to other pages or to parts within the page: a section with navigation links. Not all groups of links on a page need to be in a nav element. Only sections that consist of major navigation blocks are appropriate for the nav element. In particular, it is common for footers to have a list of links to various key parts of a site, but the footer element is more appropriate in such cases, and no nav element is necessary for those links.

On HTML5 Doctor there is an article by Tom Leadbetter about the use of the nav element. Tom notes that the key phrase is major navigation, which is rather vague indeed. In the Responses to the article (and also on Twitter) Matt Wilcox and Bruce Lawson add some useful comments. Matt ends up suggesting that it would be better not to have a nav element altogether and use a role attribute (role=”navigation”) on existing elements to indicate navigation blocks. Bruce is still in favour of a nav element, but agrees that the current specification won’t do.

I think there are the following sorts of navigation that could be considered major:

1. In-page navigation: mainly links for accessibility like ‘skip to content’, ‘bottom of page’
2. Sitelinks: links to the main pages of a website.
3. Side-wide navigation: categories, tags, monthly archives, etc.
4. Section navigation: navigating within an article between chapters, or to previous or next pages (in paginated articles).

In-page navigation blocks

should be right at the top of the document body and I would suggest to use class="accessibility" or id="skiplink", which are commonly used around the web. In-page navigation are often hidden for normal browsers as they are intended for text or speech browsers.

Sitelinks

is a word I borrowed from Google. For bigger websites, Google provides links to its main pages or categories. For instance, Apple’s main pages according to Google are ‘iPhone’, ‘Mac’, ‘iTunes’, ‘Support’ etc. Most websites display these sitelinks in a sort of menu bar at the top of the page. The place of this navigation block should be below the header block of the page. Using "sitelinks" as classname name seems logical.

Side-wide navigation

by tags, dates etc. is common in weblogs. Usually these navigation blocks are in the sidebar and I don’t see why we should not use the nav element for this type of navigation. Usually a monthly archive has its own url like /date/2009/06/ for June 2009. For me, this is major enough.

Section navigation

Navigation blocks should obey the page hierarchy (as horuskol suggests in a response to Tom’s article): section navigation blocks need to be inside the section or article they apply to, right below the article or section header. They can be tables of contents.

I am not sure how to prescribe this, or something similar, in the HTML 5 specs. Following the page hierarchy to determine what sort of navigation the nav block contains, would be a good start. I would not forbid using nav elements inside footers. In many websites, some or all links at the top of the page are also in the footer, and just being there in my opinion doesn’t make them less important of major.