Semantic navigation with the nav element

by .

One of the new elements for HTML 5 is the <nav> element which allows you to group together links, resulting in more semantic markup and extra structure which may help screenreaders. In this article I’ll discuss how and where to use it as well as some reservations I have with the specifications definition.

At first, I thought the <nav> element to be pretty simple. And whilst it still is very easy to use, I found the specification to not be overly helpful; a lot of decisions are left to the developer. Then on Monday Hixie made a change to the definition of <nav> in the draft following a prompt from our very own Dr Bruce.

How to use it

You are probably used to using something like

<div id="nav">
<ul>
<li><a.... etc

Or

<ul id="mainNav">

Well, for the sake of your markup, nothing much will change as you will now have something like this

<nav>
<ul>
<li><a href="index.html">Home</a></li>
<li><a href="/about/">About</a></li>
<li><a href="/blog/">Blog</a></li>
</ul>
</nav>

The specification

The HTML 5 specification defines <nav> as:

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.

The key phrase there is “major navigation” (previously primary navigation).

Looking at the example they give – “In the following example, the page has several places where links are present, but only one of those places is considered a navigation section.”

<body>
<header>
<h1>Wake up sheeple!</h1>
<p><a href="news.html">News</a> -
<a href="blog.html">Blog</a> -
<a href="forums.html">Forums</a></p>
<p>Last Modified: <time>2009-04-01</time></p>

<nav>
<h1>Navigation</h1>
<ul>
<li><a href="articles.html">Index of all articles</a></li>
<li><a href="today.html">Things sheeple need to wake up for today</a></li>
<li><a href="successes.html">Sheeple we have managed to wake</a></li>
</ul>
</nav>

</header>
<article>
<p>...page content would be here...</p>
</article>
<footer>
<p>Copyright © 2006 The Example Company</p>
<p><a href="about.html">About</a> -
<a href="policy.html">Privacy Policy</a> -
<a href="contact.html">Contact Us</a></p>
</footer>
</body>

I have to say that this is no use to me. There are six items of navigation in the header element there. But only three are in the nav tag. There is no explanation as to what differentiates the first three links with the second three links – both go to different pages and all are in internal to that current site.

They also give a second example:

<body>
<h1>The Wiki Center Of Exampland</h1>

<nav>
<ul>
<li><a href="/">Home</a></li>
<li><a href="/events">Current Events</a></li>
...more...
</ul>
</nav>

<article>
<header>
<h1>Demos in Exampland</h1>

<nav>
<ul>
<li><a href="#public">Public demonstrations</a></li>
<li><a href="#destroy">Demolitions</a></li>
...more...
</ul>
</nav>

</header>
<section id="public">
<h1>Public demonstrations</h1>
<p>...more...</p>
</section>
<section id="destroy">
<h1>Demolitions</h1>
<p>...more...</p>
</section>
...more...
<footer>
<p><a href="?edit">Edit</a> | <a href="?delete">Delete</a> | <a href="?Rename">Rename</a></p>
</footer>
</article>
<footer>
<p><small>© copyright 1998 Exampland Emperor</small></p>
</footer>
</body>

This is a little more helpful as I find the biggest isse of the <nav> element is deciding which sets of links should be classed as major navigation.

Where to use it?

If you take a peek at the source code for this site, there are three uses (Ed. or four if you’re on a page that includes pagination) of the nav elements – we used it on the main navigation and above the footer (both are exactly the same links by the way). We also decided to use it on the skip links that are included for accessibility.

Looking at the content of the site, it could be argued that the <nav> element could be used on the Recent Articles and Categories listings in the sidebar. Should you do it? Honestly, I think it is hard to say from looking at the spec – but I would say these are not “major navigation” but it would tempting to do, particularly if you’re analytics suggest these areas of navigation are ‘major’ ways in which your users navigate your site.

Other Possible Uses

Below are a few more examples of other areas of the site in which you might consider using the <nav> element. It is also important to note that while XHTML 2 <nl> element, this hasn’t been replicated in HTML 5 because navigation does not have to take list form, as we’ll see.

  • Table of Contents
    I would say definitely yes to that – it is primary navigation for that particularly content
  • Previous/next buttons (or pagination)
    I would say yes to this because it is important to the overall structure and hierarchy of the blog/site
  • Search form
    For me, a definite yes, but it is not mentioned in the spec. A search form is hugely important to the navigation of a site, particularly large sites which rely almost solely on their search engine.
  • Breadcrumbs
    Again, I would say yes to this as well. Although breadcrumbs are not always necessary and can be used when not applicable, on large sites a breadcrumb trail can be an important navigation aid.

The difference of nav from menu

If you aren’t aware there is another element that can confuse the issue in the HTML 5 specification – menu. I’ve noticed that some developers are using the <menu> element for navigation rather than the <nav> element. We thought it best to clarify that <menu> is to be used for a list of commands and is an interactive element and more likely to be used exclusively in Web Applications. We will be covering more about the <menu> element in a later post.

And finally…

Only with the help of the community, and hopefully a much clearer spec, can we be sure when and perhaps more importantly, when not to use the <nav> element.

85 Responses on the article “Semantic navigation with the nav element”

John Faulds says

To me search and navigation are two entirely separate functions. Both have the same end goal but they work differently and require different techniques from both the author and the user. It’s kinda like a contact page that has an email address and a contact form – both achieve the same result of the site owner getting an email, but they’re two different things.

horuskol says

Love the idea of semantic navigation elements – and I agree that there is some way to go to get some ‘best practices’ going on.

One thought more for browser vendors than web developers (although applies to them too) – would a nav element obey the hierarchy – links to previous and next really only apply at an article or section level, while the nav under the header is sitewide – and my understanding of screen-readers, in particular, is that all nav content should be read at the top of the page before the main content, but I don’t think it would make sense for previous and next to be read until at least after the article heading.

I guess this could be a personal preference thing – or just needs playing around to get some trial and error findings on what works best for most people.

horuskol says

@John Faulds: I agree search is separate to nav – ideally, I think there should be a block-level search element to complement this, but if that’s not available, then I’d settle for nav (after a bit of lobbying for the search element :p ).

Matt Wilcox says

*sigh*

That no one is quite sure of the use case for the nav element speaks volumes on the usefulness of the element itself (in the current spec anyway) and the process by which it’s made its way into the spec.

If you want to enhance semantics, do so in an extensible and flexible way, with very clear rationale. Nav is none of these things. How do you define “major”, it’s relative but no one anywhere seems to know quite what it’s relative to. The site? The page? The concept the article is talking about? Can off-site links be main nav? If that isn’t defined properly then it neuters the usefulness of the semantics.

Leaving the decision of importance to the author is a non-solution.

role=”whatever” would be a far better solution, with none of the arbitrary restrictions (no nav inside footer? why?), poor syntax, and unclear semantics.

Bruce Lawson says

I think a standard way to identify nav is a good idea. Whether or not the html5 element or the ARIA role will win for screenreaders is unknown.

There are some spec wierdnesses about nav, howvever. I don’t understand why it’s allowed in the header but not in the footer. There’s an argument for allowing it both (lots of websites have nav in headers and footers), and an equally compelling argument for allowing it in neither, but I don’t understand one not the other.

Matt Wilcox, on twitter, complained “The nav spec is aribtrary fluff. What is “major”, to whom? in relation to the site or the article? Why the distinction of importance?”

I agree with him. When I mentioned the spec’s previous ambiguous statement that it was for “primary navigation blocks”, I suggested the spec be reworded

only sections that consist of blocks whose primary purpose is navigation around the page or within the site are appropriate for the nav element, so – for example – lists of links to sponsors/ advertisers would not be marked up as nav elements.

but this was rejected.

Tom Leadbetter says

@horuskol a search element eh? Perhaps not a bad shout.

@matt Exactly Matt, the spec is too vague at the moment. You could end up using the nav element dozens of times on a page.

Bruce Lawson says

Not sure we need a search element. there’s already input type=”search” so you can style that with an attribute selector, or a user agent could provide a special keystroke to focus into that.

horuskol says

input type=”search” would be fine for a single element – but what about a more complex search form (with checkboxes and other controls for quick and easy filtering)?

Dan G. Switzer, II says

I basically I agree with Matt’s comments. The looseness of the nav makes it not particularly useful. To me would expect a nav section to be made of up links–not forms–so a search form wouldn’t really comply.

Also, the use of the word “major” to me would imply global areas of navigation, not options that are local to the page (such as breadcrumbs or pagination links.) However, that goes against the second example they show.

I expect that the nav tag will be a mostly ignored tag, unless the companies like Google, start weighting links within the nav tag–in which case the tag will become greatly abused.

The tag could prove useful to accessibility tools, but only if the tag is better defined.

Dominykas says

I currently use the “rule of skip” for the nav element – if you want a “Skip to content” or “Skip navigation” or “Skip to navigation” for a particular element, it belongs in the nav. The spec is quite loose, so I would probably even go as far as putting the “document outline” into the nav.

@Dan: I would rather think that bots will treat it as “non-content”, without adding or removing importance for the links inside nav, but rather putting more weight on keywords outside nav (in the content section). As an example of “keywords in nav” as content problem I would see “related articles”. I don’t want a search results link to an article, which only mentions my keywords inside it’s “Recent posts” section – I’d rather want to go to on of the recent posts directly. E.g. make a search for “eeenas” and select update period of “last 24 hours” – the results are completely irrelevant, and link to articles written in march.

Ian Hickson says

The blunt answer is “use whenever you would have used class=nav”.

DED says

I think the spec is loosely defined on purpose. If you notice they are using qualifiers throughout the explanation of the nav tag. They use terms like ‘necessary’ or ‘need’, both of which are best determined by the author of the code. Semantics are a good thing but if we become zealots about semantics for semantics sake, then the specs will never get written. For one thing, semantics change and are understood in unpredictable ways: notice the idea in the comments about the difference between search and navigation. Take the link itself for example. Way back in `96 Randy Trigg defined a taxonomy for 14 types of links. Yet how would the HTML specs define a link? We need to leave room for the tags to cover multiple uses because there will always be a new way to interpret them. That’s often how we advance or discover new ideas in the software development world.

Matt Wilcox says

@Ian Hickson

Except if you’d have used it inside a <div class=”footer”>

And even given this feedback, it doesn’t mitigate the other problems with using a tag instead of an attribute, or the extremely fuzzy semantics associated with that tag at the moment.

Tom Leadbetter says

@DED I agree with you about arguing semantics for semantics sake.

The point of this article is to get the discussions going, which it has. I think the responses have been useful and thought provoking and hopefully we can get the terminology cleared up a bit.

Adam says

I can accept not having a nav in a footer, it’s almost like footer is a special kind of nav that way.

but it really needs clarification, I don’t see the first example as being that different from the 2nd, where there is a nav around the top links.

Brennan says

Any hooks/improvements for the LINK element (which is one of the oldest ways of handling navigation – i.e. next, previous, up, home)?

Chris Sharp says

Avoiding the merits (or lack of) of the nav element, my question is about the continued use of unordered lists within the nav element.

If we are being honest with ourselves, we must hold our hands up and say that we have been marking up lists of links not because they were true lists, but because all those li’s and ul’s were very handy hooks for style rules. Now that CSS3 is delivering all kinds of goodies like border radius and multiple background images we will be able to style our links without the need for “sliding doors” and the like and thus the links can be set free from the lists.

John Faulds says

If we are being honest with ourselves, we must hold our hands up and say that we have been marking up lists of links not because they were true lists, but because all those li’s and ul’s were very handy hooks for style rules.

I don’t know about that. If styling is turned off, I still want my ‘lists’ of navigation items to look like lists.

bruce says

“If we are being honest with ourselves, we must hold our hands up and say that we have been marking up lists of links not because they were true lists, but because all those li’s and ul’s were very handy hooks for style rules.”

What is a menu but a list of links? Breadcrumb trails are an ordered list of links. The CSS hooks are convenient, but semantically I’d argue that they’re very much lists.

Chris Sharp says

I don’t know about that. If styling is turned off, I still want my ‘lists’ of navigation items to look like lists.

If I want my text to be red when styling is turned off should I use the font element? It will be interesting to see if any browsers add any default style rules to links within a nav.

What is a menu but a list of links? Breadcrumb trails are an ordered list of links. The CSS hooks are convenient, but semantically I’d argue that they’re very much lists.

I do agree that many groups of links are lists. But we can make anything a list and I do, an unordered list of photos, an ordered list of blog posts.

My argument is that the nav element applies enough semantic meaning to a collection of links and that the extra mark up required to make a list is superfluous.

Jonas says

To me the nav tag is defined as loosely as it is because we are talking semantics. Semantics can be very subjective, and so it would make sense that the creator of a site should have the posibility to decide which of the navigation elements are major in his context.
As can be seen above, there are different interpretations and I think the comment made near the beginning – that seeing how users move on your side – might be a good firrst hint

Gary Turner says

This proposed nav element is an example of paving the cow path before any cows have trod it. I have yet to see an example where the element wasn’t superfluous, or didn’t make the markup less semantic and less appropriately structured. When would navigation not be a list? By definition, tables of content, menus, bills of fare, &c. are all lists. How would an additional container that is the one-for-one equivalent of <div class="nav"> improve the structure or meaning of the navigation list?

John Faulds said, … I still want my ‘lists’ of navigation items to look like lists. I agree, and cannot see how a nav element will improve on the structure any more than a non-semantic div element would.

Alohci says

@Gary Turner – Whenever the use of semantic elements is questioned, invariably one ends up discussing assistive technology (AT) and in particular screen readers. What <nav> has that <div class=”nav”> does not is that because <nav> has publicly defined semantics, AT can make use of that to easily allow the skipping of the entire navigation list and thereby go directly to the page content. For users who must experience or navigate the page serially, this is a real boon.

On the other hand, <div class=”nav”> does not have public defined semantics, it may mean “this is a navigation section” or it may imply something else entirely that means something sensible to the page author, in the author’s native language. For any given class name, AT is unlikely to guess unless the false positive rate is extremely low. So for the benefit of the widest possible range of users, <nav> is the better choice.

Gary Turner says

@Alohci: By saying the nav element was equivalent to a div of class nav, I was saying that neither are worth a hill of beans. You bring up assistive technologies. Unless you depend on every possible client recognizing the nav element, and magically knowing when to skip that segment and move presciently to the right spot, you will still require a link that targets a particular id. If you have the link, and you have the target element, what earthly good is a nav element? It is plain and simply redundant, bringing nothing of value to the table.

cheers,

gary

Bruce Lawson says

I disagree Gary.

An assistive technology can make its own “skip links” function; it just needs to go to the first element on a page that is not header, footer, nav. That’s the main content.

It’s not just for assistive tech; I would love to see my phone do this for sites so that it scrolls to the start of the content for me.

ATs and phones can then have a hotkey which goes to nav – by locating the first/ next nav element in the document as that is unambiguous.
,

Gary Turner says

Bruce Lawson spoke at December 5th, 2009 at 11:53 am

> I disagree Gary.

> An assistive technology can make its own “skip links” function; it just needs to go to the first element on a page that is not header, footer, nav. That’s the main content.

Wow! And wouldn’t that cause an intolerable limitation on a document’s structure.

> It’s not just for assistive tech; I would love to see my phone do this for sites so that it scrolls to the start of the content for me.

> ATs and phones can then have a hotkey which goes to nav – by locating the first/ next nav element in the document as that is unambiguous.

For the most part, I dislike microformats as trying to do what xhtml’s author-described elements, or even html5′s new elements should do. This is a case where standardized class attributes would do the job as well as an element, without being redundant.

Good luck with getting ATs to give you the functionality you desire. Most can’t even deal with the implicit connection between labels and the form controls nested in them. That standard’s been around for ten years or so, and is much simpler to recognize than the usage you describe.

cheers,

gary

Bruce Lawson says

“Wow! And wouldn’t that cause an intolerable limitation on a document’s structure.”

Not sure I understand what you mean – what is the limitation, and for whom is it intolerable?

Gary Turner says

I confess a closer reading of your comment would have softened my own a bit. However, the page structure is still affected. Consider this top level sub-site page. If I had floated the toc, it would follow the “major” nav element and the header; not exactly the advantage you speak of. In order for your scenario to work, the page structure must still consider your, as yet, non-existent AT or PDA functionality. Hell, does MSFT’s screen reader make the intrinsic connection between labels and their nested form controls yet? That standard’s only been around for ten years.

Nevertheless, the nav element is still redundant, and brings nothing to the table not otherwise doable.

cheers,

gary

Bruce Lawson says

In the example you give Gary, the Table Of Contents would be in a nav element (it is a TOC with links around your site). So an AT that’s sniffing “main content” would pass over the TOC, regardless of its position within the visual page or source.

The MSFT screenreader argument is entirely unrelated as far as I can see.

James says

Is there a reason why we’re not moving towards using <nav> in place of <ul> or <ol>? Wrapping it around a ul or ol makes it feel a bit redundant.

Oli Studholme says

@James — because if you did that you wouldn’t be able to add things like a heading. It’s also no doubt a little safer in older, stupider browsers ;)

Lee Peterson says

Has anyone noticed a Firefox 3.6 and IE8 bug while using the nav element that doesn’t allow background images to be used with it?

Cragdo says

Tom states that… You are probably used to using something like

When there is no need for the div container as is a block level element already so…

is better markup. A major annoyance with tags like is that is seems to bloat your code as you are wrapping a block level element round a block level element. I am definitely an advocate of HTML5 but surely bloating your code in such a way is a step in the wrong direction.

Cragdo says

Sorry that should read.

Tom states that… You are probably used to using something like

<div id=”nav”>

When there is no need for the div container as is a block level element already so…

<ul id=”nav”>

is better markup. A major annoyance with tags like is that is seems to bloat your code as you are wrapping a block level element round a block level element. I am definitely an advocate of HTML5 but surely bloating your code in such a way is a step in the wrong direction.

Treeshadow says

Would’nt it be more obvious if the nav tag would accept list items.

For example:


<nav>
<li><a href="">Some item</a></li>
</nav>

or if we could use a special nav item tag?


<nav>
<ni href="">Some item</ni>
</nav>

We are the knights who say &ltni> A Shrubbery&lt/ni>!

Extending HTML5 | Programming Blog says

[...] this? While HTML5 has a bunch of semantic elements, including new ones like <article> and <nav>, sometimes there just isn’t an element with the right meaning. What we want are ways to extend [...]

Ajaxian » Extending HTML5 says

[...] this? While HTML5 has a bunch of semantic elements, including new ones like <article> and <nav>, sometimes there just isn’t an element with the right meaning. What we want are ways to extend [...]

Mendelson says

for search forms? no no. Can’t agree with that.

Search != navigation. They are two distinct ways of finding information. There is no use for acessibility nor for crawlers to mark up search as navigation – you can already get at the search by looking the input type.

cptvitamin says

Say you have a list of 5 of the latest news articles on a home page. Would you mark that up as <nav>?

Bow Gardz says

Why is it that we need to add another markup in our already very nested code? If we are going for a more semantic way of coding navigational elements, what if we should just use something like:

Wherein the element ni stands for navigation item or something like that? Rather than use the same ul, li, and a tags…

Mark Boughter says

I almost never use a DIV around my navigation UL so using the NAV tag is extra markup. It adds semantic meaning but it should allow LI as a child.

Richard Clark says

@Ben, looks like the HTML in your comment got stripped, want to post it again?

@Mark, it wouldn’t make sense to allow li as a child of nav. How can you have a list item with no list defined?

Jamie Stevens says

@Richard

I suppose the logical answer would be to create a 4th list type, called NAV (DL being the third type of list)

So a list item could be a child of an Ordered List, an Unordered List, and a Navigation List

Josh says

How about no list element at all.


<nav>
<a href="#">Home</a>
<a href="#">About</a>
<a href="#">Contact</a>
</nav>

You don’t really need those list elements, unless you are concerned about what it will look like with no style applied.

Terry says

Like others pointed out, it’s idiotic having to write followed by then . I don’t know what the guys responsible for HTML5 were thinking. Probably nothing, like so much else in that new HTML version.

Inside a , it should be possible to drop the because it just bloats the code. should stay though, as not every text listed should be part of a clickable link.

Terry says

Again, because all the tags were deleted (smart comment function, really…):

Like others pointed out, it’s idiotic having to write “n a v” followed by “u l” then “l i”. I don’t know what the guys responsible for HTML5 were thinking. Probably nothing, like so much else in that new HTML version.

Inside a “n a v”, it should be possible to drop the “u l” because it just bloats the code. “l i” should stay though, as not every text listed should be part of a clickable link.

Koder says

I have a question about a breadcrumb that comes right after/under de primary navigation:


<div>
<!-- Main Navigation -->
<nav>
<ul>
<li><a href="#">Main Page 1</a></li>
<li><a href="#">Main Page 2</a></li>
<li><a href="#">Main Page 3</a></li>
</ul>
</nav>

<!-- Breadcrumb -->
<nav>
<ul>
<li><a href="#">Home</a></li>
<li><a href="#">Main Page 2</a></li>
<li><a href="#">Sub Page 2.1</a></li>
<li><a href="#">Post title</a></li>
</ul>
</nav>
</div>

Or…


<nav>

<!-- Main Navigation -->
<ul>
<li><a href="#">Main Page 1</a></li>
<li><a href="#">Main Page 2</a></li>
<li><a href="#">Main Page 3</a></li>
</ul>

<!-- Breadcrumb -->
<ul>
<li><a href="#">Home</a></li>
<li><a href="#">Main Page 2</a></li>
<li><a href="#">Sub Page 2.1</a></li>
<li><a href="#">Post title</a></li>
</ul>
</nav>

I think the second one is correct, but I would like to know how you think about it.

Inkfree says

the “nav” element can now accept any form of content as i can see here and here. I always look for discussions here and would love to know what the doctor has to say :) thanks

Sandy Campbell says

When I Googled “nav vs menu”, I didn’t realize how contentious an issue this is! But I actually prefer over because the markup for is simpler. The tag requires that your list items are wrapped with . It’s no different than using a tag. But the tag accepts list items without needing a wrapper. In essence, replaces when you want to make a navigational list. It verifies and displays correctly as a list when CSS is disabled. Whatever styles you have now for will work for .

Sandy Campbell says

Sorry, I didn’t see the note about using brackets, so all my tags were stripped from my previous comment:

When I Googled “nav vs menu”, I didn’t realize how contentious an issue this is! But I actually prefer ‘menu’ over ‘nav’ because the markup for ‘menu’ is simpler. The ‘nav’ tag requires that your list items are wrapped with ‘ul’. It’s no different than using a ‘div’ tag. But the ‘menu’ tag accepts list items without needing a ‘ul’ wrapper. In essence, ‘menu’ replaces ‘ul’ when you want to make a navigational list. It verifies and displays correctly as a list when CSS is disabled. Whatever styles you have now for ‘ul’ will work for ‘menu’.

Hanamiti says

Man, thank you for the explanatory article :) I am slowly migrating from XHTML to HTML5 markup, and you were of real help! Cudos.

Toke Voltelen says

Well. The issue about having the <nav> element being an actual list, is that, in it’s current state it is an area wherein navigational items are placed. No where is it said that the links needs to be in a list, but most developers do this for presentational reasons when there is no styles + accessibility.

I don’t mind that the <nav> is an area-tag rather than a list-tag, as it makes sense to mark up an area that is related for navigation. But the definition of how to use the tag pretty vague. I don’t understand why and bunch of links to key pages in a website in the footer, is less a navigation than the main menu in the header. It is still navigation to important places on the website.

In my oppinion the <nav> should be used for areas that allow the user navigate the site. Clusters of internal links along with descriptive texts and headers. Breadcrumb being an excellent example, as well as the footer links.

mandy says

I had the same question regarding breadcrumbs as koder above, but I liked his second option so I’m going to use that.

Carbonize says

Slightly off topic but given that you are using HTML 5 on this fsite such as the doctype and nav element why are you still using the type attribute for the style and script tags? Neither of these is necessary in HTML 5 as the browser will treat them as CSS and JavaScript by default.

Matthew Trow says

I’ve ended up using nav very sparingly – only in primary & secondary navigation (e.g. top nav and/or side nav)

In fact, I don’t even use it for styling – it’s purely there for screen readers in my code.


<nav>
<ul id="primary">
<li> ...
</ul>
</nav>

In fact, I don’t use any of the new semantic html5 elements for styling (structure) at all – that’s what div is for.

bruce says

“I don’t use any of the new semantic html5 elements for styling (structure) at all – that’s what div is for.”

Any element may be used for styling – that’s why you can hang CSS on p, video, ul, li etc rather than only div.

But you shouldn’t add elements that don’t need to be there just to hang styles off; in that case, use div.

Pragmatically, if you don’t want to use the JavaScript shim for IE6 – 9, don’t try to style the new semantic elements. But that’s to cover an IE bug, not because styles should only go on divs.

Sam says

I’m curious why you use
<nav>
<ul>
<li><a href="…">Nav Link 1</a></li>
<li><a href="…">Nav Link 2</a></li>
</ul>
</nav>

On my site, I much prefer the simpler
<nav>
<a href="…">Nav Link 1</a>
<a href="…">Nav Link 2</a>
</nav>

I for one hate sites that have a link within a tab but the link doesn’t cover the whole tab. I much prefer having the entire tab be the link.

Julien Etienne says

Hmm, quite straight forward:

The idea of:

Is to say “Hey this is the navigation of the website” to (lets say) the robots.

In regards to Bruce Lawson’s comments about the nav not being allowed in the footer, I’m kind of on both sides with that.

I get that the footer isn’t a counterpart of the header. I guess there are so many typical scenarios of list being used in the footer that automatically most people would abuse the nav as an alternative for ul’s & ol’s.

It seems like w3 are trying to “prevent novice use” in most cases.

As mentioned, there’s no need to use with I would assume unless the nav serves as some kind of list content as well.

fridojet says

I use <aside role="searcg"> for search forms.

Gareth says

What really bugs me is the majority, if not all, of navs simply contain an unordered list with its respective items.

Would it not make more ‘semantic’ sense to offer a nav item in the form of <code><ni><a href=”">Item</a></ni></code>

It’s clear to crawl, offers meaning and then doesn’t have the need for extra lists.

Arie Putranto says

SEARCH? Definitely NO! it’s not for a navigational purpose, IMO. Yes, it navigates you to the other part of the website, but well, just think again, is it semantic?

Nigel Nquande says

The original HTML documents recommended “be generous in what you accept”, and it has bedeviled us ever since because each browser accepts a different superset of the specifications. It is the specifications that should be generous, not their interpretation. — Doug McIlroy in The Art of UNIX Programming

It’s all too easy to end up in tag soup.

Personally, I’ve been using <nav> for site-wide links and <menu> for page-specific links (even though <nav> can be used for page-specific links). That approach makes sense to me, although nav elements seem to offer no advantage over <div class=”nav”> for non-AT devices.

@Carbonize : Although they’re treated as CSS or JS by default (even by non-HTML5 browsers), it doesn’t hurt to be specific/ explicit.

Travis says

What about adding the role of navigation to the nav element? Is this redundant? Or is it a good practice for the sake of screen readers?

    Steve Faulkner says

    Hi Travis, the nav element is not yet mapped across all browser to role=navigation, so addition of the role is helpful for AT users. The recommendations table in Using ARIA in HTML provides advice on when the addition of an explicit role is useful.

Ian Y. says

In particular, it is common for footers to have a short list of links to various pages of a site, such as the terms of service, the home page, and a copyright page. The footer element alone is sufficient for such cases; while a nav element can be used in such cases, it is usually unnecessary.

And two out of three examples on the WHATWG‘s page use nav in footer.

Mohammad Karam says

I’m not a html5 pro, so I ask you why should I use “nav” or even why should I use “article” or “aside” etc. instead of “div” ? is it a matter of seo or application developing ?
I’m sorry for this silly question but I really want to know

Lucas Krause says

Yes, that’s exactly what matters. Moreover also screenreaders rely on semantically structured markup.

Lucas Krause says

My answer to the question “Why are the first 3 links in the first example no primary navigation?”:

I think the first example’s first <h1> changes with the the document it is placed in. However, the subsequent links keep the same, regardless of the called document. Therefore they aren’t primary navigation links in context of the called document (article). But the next 3 links, inside of the <nav> are.

In my opinion it would have been better to move the <nav> into a <header> inside of <article> and wrap the first 3 links (in context of the whole doc) into <nav>. This would cause 2 <nav>, each for its own context (whole doc, article).
This is the same solution used in the 2nd example.

skip405 says

Thanks a lot for the article. It got me wondering if we could use the <menu< element to markup the tabs links. I mean you click a tab and see some content… would the following markup be semantic? I doubt that it is, but still :)


<menu<
<li<<button<Button showing tab 1</button<</li<
<li<<button<Button showing tab 2</button<</li<
</menu<
<div class="tabs"<
<div class="tab"<</div<
<div class="tab"<</div<
</div<

From the “nav”-perspective the code looks more natural, imho.

<nav<
<li<<a href="#tab1"<Link to tab 1</a<</li<
<li<<a href="#tab2"<Link to tab 2</a<</li<
</nav<
<div class="tabs"<
<div class="tab"<</div<
<div class="tab"<</div<
</div<

Jed Mao says

I don’t think it’s a good idea to suggest ul and li tags within an already-semantic nav tag. A list is not the most semantic for navigation elements.

Instead, as was previously suggested, I prefer the following:


<nav class="nav">
<a href="/" class="nav__item">Home</a>
<a href="/about" class="nav__item">About</a>
<a href="/blog" class="nav__item">Blog</a>
</nav>

This is both semantically sound as well as BEM friendly. That is, the CSS could look like this:


.nav {
width: 720px;
}
.nav__item {
display: inline-block;
padding: 10px 20px;
}

You say you want a header or a footer? That’s what the HTML5 header and footer tags are for:


<nav class="nav">
<header class="nav__header">
<!-- header content -->
</header>
<a href="/" class="nav__item">Home</a>
<a href="/about" class="nav__item">About</a>
<a href="/blog" class="nav__item">Blog</a>
<footer class="nav__footer">
<!-- footer content -->
</footer>
</nav>

This is OOCSS :)

    Steve Faulkner says

    A list is not the most semantic for navigation elements.

    I don’t understand how you arrive at this conclusion. If links are organised as a list then use a list.

RABP says

Is the element you can put the item article?

Sjoerd Kranendonk says

A list is not the most semantic for navigation elements.

I don’t understand how you arrive at this conclusion. If links are organised as a list then use a list.

Steve, can you clarify why the search box on HTML5 Doctor is embedded in a one item list within the ‘nav’? I understand the reasons of having search inside the ‘nav’. But what is the significance of having another separate ‘ul’ with only one item? It sounds very strange if you listen to it in a screen reader.

    Steve Faulkner says

    Steve, can you clarify why the search box on HTML5 Doctor is embedded in a one item list within the ‘nav’?

    That’s a bug in the code, there is no need to have 1 item lists, thanks for the heads up will see if I can get it fixed.

Join the discussion.

Some HTML is ok

You can use these tags:
<a href="" title="">
<abbr title="">
<b>
<blockquote cite="">
<cite>
<del datetime="">
<em>
<i>
<q cite="">
<strong>

You can also use <code>, and remember to use &lt; and &gt; for brackets.