Help with proper HTML5 navigation syntax

[team1504]

Hi guys,
I was wondering if you could help me figure out the best way to write my navigation in html5.

In HTML4, it looked something like this:

<div id="navigation">
<ul>
<li><a href="#">Link 1</a></li>
<li><a href="#">Link 2</a></li>
<li><a href="#">Link 3</a></li>
<li><a href="#">Link 4</a></li>
<li><a href="#">Link 5</a></li>
</ul>
</div>

I know in html5 they came out with the <nav> tag, So I could write it in HTML5 like this, right?

<nav>
<ul>
<li><a href="#">Link 1</a></li>
<li><a href="#">Link 2</a></li>
<li><a href="#">Link 3</a></li>
<li><a href="#">Link 4</a></li>
<li><a href="#">Link 5</a></li>
</ul>
</nav>

However, I have seen some places that show documentation on using the nav tag properly that completely omit the <ul> tags so they do

<nav>
<li><a href="#">item 1</a></li>
<li><a href="#">item 1</a></li>
</nav>

And other source that omitted the <li> tags as well.

<nav>
<a href="#">item 1</a>
<a href="#"> item 2</a>
</nav>

And finally, someone suggested using the <section> tag instead of <ul> because the list is a section of the navigation.So it would be:

<nav>
<section>
<li><a href="#">Link 1</a></li>
<li><a href="#">Link 2</a></li>
<li><a href="#">Link 3</a></li>
<li><a href="#">Link 4</a></li>
<li><a href="#">Link 5</a></li>
</section>
</nav>

So what I was hoping someone could help me understand is that in proper HTML5 syntax,
1.) does one omit the <ul>, <li>, or both inside a <nav>?
2.) Can <section> be a child of <nav> because I thought < section > was more of a tag for the content than the navigation?


Thanks in Advance and Best Regards,
Team 1504

[Stevie D]

According to http://dev.w3.org/html5/spec/Overvie...he-nav-element, <nav> can't contain <li> elements directly, you need to put a <ul> in there as well.

[zcorpan]

<nav> is a type of <section>, so putting <section> in <nav> is just putting a useless subsection of the navigation section...

A validator would point out where <li> is allowed.

Omitting the list markup means that it's not a list but just a paragraph of links. I guess a list would be better.

[zcorpan]

However, I have seen some places that show documentation on using
...
And other source that omitted the <li> tags as well.
...
And finally, someone suggested using the <section> tag ...

It would be useful if you could point to these bogus recommendations so they can be corrected.

[Stomme poes]

Since I've seen just about all those same combinations (viewing random source), I think this is an awesome question. I'm glad team asked it.

All along I'd figured the times I saw
<nav>
<ul>
<li>....</li>
</ul>
</nav>
was because the redundant <nav> was for the browsers and whatever other user agents who understood it got a bit more semantics (hey it's not just any old list, it's a navigation list), while older UAs could still see it was a list.

Hey Simon, we're thinking it's time for a "What is HTML5 and what is it NOT" sticky thread for the design area (up with the XHTML/HTML one). Want in?

[team1504]

it is just viewing random sources of sites that claim they are using html5

I ended up chosing
<nav>
<ul>
<li><a></a></li>
<li><a></a></li>
... ... ...
<li><a></a></li>
</ul>
</nav>

This is what the dev.w3 showed as most acceptable.

[zcorpan]

Hey Simon, we're thinking it's time for a "What is HTML5 and what is it NOT" sticky thread for the design area (up with the XHTML/HTML one). Want in?

I want half the profit!

I can review it at least... But really the answer to that question is a matter of opinion. To some people the answer is "if it's in w3.org/TR/html5 then yes", to others it's "if it's new and cool and related to the Web, then yes".

[Stomme poes]

to others it's "if it's new and cool and related to the Web, then yes".

And to some Indians are the same as Pakistanis. And to some CSS3 == HTML5. No reason for SitePoint to further that garbage. Anyway I still see you floating around here from time to time doing really nothing but refuting HTML5 myths. Plus all the stuff you miss. HTML5 is the new XHTML, and we needed a sticky about it. It could go ahead and mention (explain) the geo-location, the web storage, blah blah... why not.

You can have half of all the beer and profits the thread generates.

[noonnope]

to my understanding, html5 is nothing about innovation: it's about the cows path. it's nothing about new way: it's about 100% backward compatibility.

so, any html or xhtml you consider, <li> will always go in <ul> or <ol>.

the question is, what's the <nav> to be used for? only for lists? what if your navigation is flash? or silverlight? does <nav> has to be only about lists for navigations? or are you just oversimplifying?

that said, <nav> as a semantic element should contain any construction related to navigation. implying that it replaces <ul> it's a bit moronic. it doesn't replace any old elements, it's a dedicated container for navigation construction on your page. like how <section> doesn't replace <head>, <body> etc.

[Stomme poes]

what if your navigation is flash? or silverlight?

Then you have unleashed the Dark One upon the Lost Souls of Web Development, and the Unholy Child Weeps Tears of Fire and Appbloat.

On a note of All that is Good and Well with the World, JAWS 12 no longer completely ignores content inside <header> tags in Firefox. Note that JAWS costs an arm and a leg to buy or upgrade so I'm sure there are plenty of users who still get no <header> content if they are using Firefox.

[noonnope]

but, as i've growled on previous occasions, i'm convinced flash and silverlight will become serious tools for a web developer, if not the tools.

a simple plug-in to solve all x-UAs compatibility issues? that sounds cheap to me! and don't think i don't get the double meaning of this!

think of this: UAs accepting flash/silverlight plug-in. flash/silverlight accepting html plug-in (or xml, like it is the case now). html renders inside flash/silverlight plug-in 100% the way you write it. and w/o any additional millstones attached to the html.

so flash/silverlight become UAs. like air. adobe air.

[Stomme poes]

Adobe's disregard for Linux (and increasing dislike of Apple); Adobe's closed-source code; Adobe's numerous, uncountable security leaks, breaches and holes (superseded only by the less-mentioned Java holes)... yeah.

I don't let Adobe onto my machine, and it would not surprise me to come across a machine that could not download it. Silverlight is also closed-source and created by The One Who Gave Us IE (http://www.iestolemylife.com), who I really have no desire to help out by spreading their software. But that's me.

All my browsers understand markup, and they don't need assistance from some bloated application I must download just to access the markup. I do not believe I have the freedom to assume all user agents can download some closed-source application in order to simply receive the content of a web page. And when we give someone a url, we ARE promising a web page.

And frankly if you're building some whole big site out of an app like Flash, then it's something that doesn't translate well to markup in the first place (one would assume) like a game or something.

[noonnope]

things change. you assume they will not. that flash will be flash as we know it now forever. or html will be html as we know it forever.

i assume, and it's something logic, that because there are problems, things will change and evolve. and i've made an extrapolation: a plug-in to replace the rendering engine of all UAs.

[Stevie D]

i assume, and it's something logic, that because there are problems, things will change and evolve. and i've made an extrapolation: a plug-in to replace the rendering engine of all UAs.

Would that not make the browser somewhat obsolete? Why bother having a choice of umpteen browsers if everything is actually done by a single plug-in? And who controls the plug-in? What if someone else writes an alternative plug-in? What if browsers decide to give the option to render pages natively? Bear in mind the huge variety of platforms through which people can access the web - think about how many mobile phones have web access but don't fully support Acrobat Reader or Flash.

I don't want to work in a web where everything is controlled by a single plug-in - it would destroy a huge part of what makes the web such a success.

[noonnope]

i feel the thread should split somewhere

I don't want to work in a web where everything is controlled by a single plug-in - it would destroy a huge part of what makes the web such a success.

but it already is. it's a single rendering engine (like in Gecko/Trident - flash/silverlight) (think of it as a plug-in) controlling the web you work on right now.

And who controls the plug-in? What if someone else writes an alternative plug-in? What if browsers decide to give the option to render pages natively?

actually that's the problem you're facing today: someone else writes an "alternative plug-in": Trident, Webkit, Gecko, Presto etc. that's why we need a unified implementation. a unified solution.

[Stevie D]

actually that's the problem you're facing today: someone else writes an "alternative plug-in": Trident, Webkit, Gecko, Presto etc. that's why we need a unified implementation. a unified solution.

And, without going down the route of proprietary code, how are you going to stop anyone else building a new plug-in?

[noonnope]

And, without going down the route of proprietary code, how are you going to stop anyone else building a new plug-in?

i'm not going to.

why should i? the adoption of a solution is a natural selection process. like when choosing an UA. why do you believe we only have flash and silverlight? and who's stopping you now to use an UA or another? or who's stopping others building new UAs? i really don't see a point in there.

but the beauty with these plug-ins managing html is that when a better plug-in comes along, i'm not tied up to the UA. all i have to do is to apply the plug-in which, hopefully, will ensure x-UAs behaviour.

all i have to do is to write up my markup once and users coming from different backgrounds will see the same one thing.

why is this good? because those that are stuck with an UA (the current UA's crisis) can actually benefit from modern markup w/o an graceful degradation effort from the developer's part. win-win.

and you'll write your standard html markup once, and users from different backgrounds will all see the same one thing. i believe that was the point with this whole web platform, right?