HTML5 nav tag correct usage

Question

<ul class="mainMenu">     <li><a href="#">Home</a></li>     <li><a href="#">Forum</a></li>     <li><a href="#" class="mainSelected">Construct</a></li>     <li><a href="#">Arcade</a></li>     <li><a href="#">Manual</a></li> </ul> <ul class="subMenu">     <li><a href="#">Homepage</a></li>        <li><a href="#">Construct</a></li>     <li><a href="#" class="underSelected">Products</a></li>     <li><a href="#">Community Forum</a></li>     <li><a href="#">Contact Us</a></li> </ul> 

Is it more semantically correct to have a <nav> around both these <ul> individually, or should one nav wrap both?

Also would it be appropriate to use the nav tag to wrap around my footer menu items?

Answer 1

To quote the specs:

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 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, without a nav element.

So feel free to wrap both in a single nav tag. Don't wrap the footer but use the footer tag here :)

Read the specs here: http://dev.w3.org/html5/spec/Overview.html#the-nav-element

Answer 2

The search for the reason for nav has been going on for years now. Just google around right now and you'll find dates on the question that go back to its introduction. The one actual use for nav that I've found so far is to associate it with style in css. Before you say, there are better ways to do that, consider that programmers aren't the only people doing page markup. To a commercial artist who designs web pages for a living, it's better to have one simple tag than to think about classes and sub-classes. If you've followed the discussion among various groups for a while, you would have a feeling that I could very well be right about this. Many page developers are all about style - they're artists, not programmers.

A bit more confirmation: If you look at the new structural tags in HTML5, you can easily get the idea that the committee wanted well defined major elements of a page. Each major element can look and behave differently. If you want to design a typical web page, then it can be quite convenient if someone has already given names to page section tags so you can get right down to the business of styling them. Throw in a nav tag in the part of the page where you provide a navigation section. What's that, you ask? It's not one of the other already pre-defined sections like footer or sidebar. Here's a tutorial showing where the author believes the navigation section is - right where you'd expect it.

That's fine. If I want to build a page that's just like a million other pages, and my only concern is over making my color choices and artistic elements different from others, the whole thing is pretty routine. As a programmer, I don't always want that. I want flexibility to accomplish whatever the envisioned functionality needs in a logical and easy to use way. Would be nice if that's easier rather than harder. So, just to give a bit of contrast to show that there are two sides to this story - I lament the loss of framesets and frames in HTML5. iFrames are poor substitutes.

The winners who are interested in style without much concern for designable structure and functionality have always wanted to push development into css, which is not a programming language. RE: loss of frames, looks like I'll be pushed all the way back to the days when most web pages were structured by tables; except they want me to define tables in css rather than with tags in the page. They seem to be doing everything possible to block any headway on dynamic pages; allowing only full page reloads to restructure things. (Not true if you want to fade from one picture to another withing the same page structure.)

Perhaps I've said a bit more than required to answer the question, but I thought it would be useful to broaden a bit into the overall context.