The HTML5 <nav> element

[sdt76]

In another conversation, it was brought up that <nav> adds useless code, like this:

<nav>
<ul>
<li>Link</li>
</ul>
</nav>

To me that does seem pointless. But the HTML5 spec does say that the element does not have to contain a list and they provide this example:

A nav element doesn't have to contain a list, it can contain other kinds of content as well. In this navigation block, links are provided in prose:

<nav>
 <h1>Navigation</h1>
 <p>You are on my home page. To the north lies <a href="/blog">my
 blog</a>, from whence the sounds of battle can be heard. To the east
 you can see a large mountain, upon which many <a
 href="/school">school papers</a> are littered. Far up thus mountain
 you can spy a little figure who appears to be me, desperately
 scribbling a <a href="/school/thesis">thesis</a>.</p>
 <p>To the west are several exits. One fun-looking exit is labeled <a
 href="http://games.example.com/">"games"</a>. Another more
 boring-looking exit is labeled <a
 href="http://isp.example.net/">ISP™</a>.</p>
 <p>To the south lies a dark and dank <a href="/about">contacts
 page</a>. Cobwebs cover its disused entrance, and at one point you
 see a rat run quickly out of the page.</p>
</nav>

If that is the case, would this mean that it is possible to write the navigation this way:

<nav>
<a href....>
<a href....>
<a href....>
</nav>

Then, target <nav> as you would targeted <ul>, and target the internal <a> as you would <li>. Personally, though, I like having the three targets of <ul>, <li> and <a>, whereas the above reduces that by one, and the previous adds one unnecessary. But would the above cause any unexpected problems?

[TechnoBear]

If that is the case, would this mean that it is possible to write the navigation this way:

<nav>
<a href....>
<a href....>
<a href....>
</nav>

Then, target <nav> as you would targeted <ul>, and target the internal <a> as you would <li>. Personally, though, I like having the three targets of <ul>, <li> and <a>, whereas the above reduces that by one, and the previous adds one unnecessary. But would the above cause any unexpected problems?

I think it would run foul of accessibility guidelines:

Until user agents (including assistive technologies) render adjacent links distinctly, include non-link, printable characters (surrounded by spaces) between adjacent links.

[sdt76]

Yeah, that's what I figured. No loss to me, but I was just wondering.

[Stevie D]

If that is the case, would this mean that it is possible to write the navigation this way:

<nav>
<a href....>
<a href....>
<a href....>
</nav>

Then, target <nav> as you would targeted <ul>, and target the internal <a> as you would <li>. Personally, though, I like having the three targets of <ul>, <li> and <a>, whereas the above reduces that by one, and the previous adds one unnecessary. But would the above cause any unexpected problems?

I don't think <nav> can contain inline elements or text itself, but only block-level elements. All the examples given on w3.org show only block-level content, but the "content model" is described as "flow content", but that is not actually defined anywhere that I can see. For comparison, <blockquote> is also "flow content", but <p> is "phrasing content". But then <div> and <li> are also "flow content", so that doesn't necessarily help.

The example on w3schools shows the <nav> directly containing <a> elements, separated by pipe symbols, which hardly seems to be the great leap forward for semantics, accessibility and separation of presentation from content that we would want to see.

[sdt76]

I don't think <nav> can contain inline elements or text itself, but only block-level elements. All the examples given on w3.org show only block-level content, but the "content model" is described as "flow content", but that is not actually defined anywhere that I can see. For comparison, <blockquote> is also "flow content", but <p> is "phrasing content". But then <div> and <li> are also "flow content", so that doesn't necessarily help.

Interesting. Hypothetically, can that be addressed by styling the <a> as display:block?

The example on w3schools shows the <nav> directly containing <a> elements, separated by pipe symbols, which hardly seems to be the great leap forward for semantics, accessibility and separation of presentation from content that we would want to see.

Of course not. I usually use border-left styling for that.

[Open Source]

I haven't heard about it before, but i have read your post and wondered about it, as its very helpful for us.
I have read that Html 5 brought very new tags, and its really very helpful specially for Designers.
And i don't think it cause any Problem for me.

[TechnoBear]

Interesting. Hypothetically, can that be addressed by styling the <a> as display:block?

I don't think so. That only changes the display; the element remains an in-line element.

[Stevie D]

Interesting. Hypothetically, can that be addressed by styling the <a> as display:block?

Nope. It's still an inline element, regardless of what styling you apply to it. In just the same way, you couldn't have

<table>
<div><span>stuff...

table div {display:table-row;}
table div span {display:table-cell;}

Remember that CSS is an optional hint as to how the author would like the page to be displayed, it doesn't affect the code or the page structure at all.

[xhtmlcoder]

In the land of Fred the A element is basically flow content and most elements that are used in the body of those documents and applications are categorised as flow content though typically an outline would make sense.

[sdt76]

Nope. It's still an inline element, regardless of what styling you apply to it. In just the same way, you couldn't have

<table>
<div><span>stuff...

table div {display:table-row;}
table div span {display:table-cell;}

Remember that CSS is an optional hint as to how the author would like the page to be displayed, it doesn't affect the code or the page structure at all.

Then what is the logic behind the idea that we can only nest inline elements in <nav> if they themselves are nested in block level elements? That seems worse than just using a DIV with A elements for nav because right or wrong, at least you get a choice. I don't understand the reasoning.

[Stevie D]

Then what is the logic behind the idea that we can only nest inline elements in <nav> if they themselves are nested in block level elements? That seems worse than just using a DIV with A elements for nav because right or wrong, at least you get a choice. I don't understand the reasoning.

Just the same as the logic that says you can't have loose text or inline objects directly in <blockquote>, <section> or <header>. The containers are there to divide the page into sections, and then within each of those sections, you use the appropriate block-level elements to hold the text.

[sdt76]

The reason its weird to me is that dividing the page is what DIVs and UL do already without the added restraints right? So why not just stick with those rather than have to place a block level within a block level? I suspect there is something I am not understanding correctly.

[sdt76]

I guess what doesn't make sense to me is this: <nav> seems to be created to be a DIV with the built-in semantic of being "navigation." The strange thing is, we don't build our navigations in DIVs but in lists and <nav> does not replace <ul>. So what is the point?

One of the reasons I asked the question is because I thought NAV was supposed to structurally replace the <UL> system of navigation where you have to remove the default formatting of bulleted lists and change alot of behaviors, because <ul>s were never imagined to be used to create navigation right? It's kind of like how we used tables for layout, but that wasn't the intended purpose way back in the cave man days. We found a way to create navigation from <ul> when CSS was developed, when it was defaulted as a bulleted list. Semantically a navigation is a list, but I had thought the idea of the new <nav> tag was to encourage the use of that tag with a series of <a> elements as above, rather than the <ul> element.

That's why I am confused as to the whole point of the new tag.

[emmons]

In another conversation, it was brought up that <nav> adds useless code, like this:

<nav>
<ul>
<li>Link</li>
</ul>
</nav>

To me that does seem pointless. But the HTML5 spec does say that the element does not have to contain a list and they provide this example:



If that is the case, would this mean that it is possible to write the navigation this way:

<nav>
<a href....>
<a href....>
<a href....>
</nav>

Then, target <nav> as you would targeted <ul>, and target the internal <a> as you would <li>. Personally, though, I like having the three targets of <ul>, <li> and <a>, whereas the above reduces that by one, and the previous adds one unnecessary. But would the above cause any unexpected problems?

Personally, I will stick to my <ul>'s, but maybe this was implemented for ease-of-use or to make it easier for beginners, since, most of the time you will be using lists for navigation anyway...

[sdt76]

Man, I hope that's not their reason....

[emmons]

Man, I hope that's not their reason....

Pretty soon it's going to look like this:

<navigation>

<link>link</link>
<link>link</link>
<link>link</link>

</navigation>

lol...

[sdt76]

I did notice this in the spec:

"User agents (such as screen readers) that are targeted at users who can benefit from navigation information being omitted in the initial rendering, or who can benefit from navigation information being immediately available, can use this element as a way to determine what content on the page to initially skip and/or provide on request."

[Stomme poes]

"User agents (such as screen readers) that are targeted at users who can benefit from navigation information being omitted in the initial rendering, or who can benefit from navigation information being immediately available, can use this element as a way to determine what content on the page to initially skip and/or provide on request."

Because the nav element is getting a native role of "navigation". You can manually add that role to anything (within reason, and so long as your added role doesn't conflict with the element's default role), but that's what they're talking about there.

However roles are a separate thing from the intended semantics.

Yes, you could
<nav>
<h2>Product pages</h2>
<ul>
<li><a href="foo">hammers</a></li>
<li><a href="foo">nails</a></li>
<li><a href="foo">awesome power tools rawr</a></li>
</ul>

<h2>Offices Worldwide</h2>
<ul>
and so on...
</ul>
</nav>

It might be better to think of nav as a replacement for a div you would have around a navigation section of your page. The current idea for a website's main menu is indeed the "extra" wrap:
<nav>
<ul>
site menu here...
</ul>
</nav>

Since other than the role nothing else is (yet) more semantic about nav, plus all the trouble it gives to crappier screen readers like Window Eyes, I'm just sticking to

<ul role="navigation">
for now. It works in newer screen readers on newer browsers today. Roles rule. Navigation is specifically a landmark role, so users with new enough software can (if they're aware of it) navigate the web page using those as hooks to jump around (esp handy if the page doesn't have any skip links).

Another bit salvaged from the sunken XHTML2 wreckage.

[sdt76]

Since other than the role nothing else is (yet) more semantic about nav, plus all the trouble it gives to crappier screen readers like Window Eyes, I'm just sticking to

<ul role="navigation">
for now. It works in newer screen readers on newer browsers today. Roles rule. Navigation is specifically a landmark role, so users with new enough software can (if they're aware of it) navigate the web page using those as hooks to jump around (esp handy if the page doesn't have any skip links).

Another bit salvaged from the sunken XHTML2 wreckage.

Would the <NAV> tag help SEO? For example, do you know if the search engine developers could use that to create more relevant results since DIV is meaningless to acomputer, but <NAV> has semantic meaning, isn't HTML5 really about preparing for the future of the Semantic Web as envisioned by Tim Berners-Lee? It's a concept that I am starting to understand more now, and seeing how it has more possibilities that we can experience now. Does that mean that HTML5 is essentially laying the groundwork, the path, for computer interaction to become much more advanced in the future? If that is the case, maybe I can understand now, why HTML5 is introducing tags that may add extra markup, and don't seem to have perceived value now, but are setting the stage for the future. I am open to that.

Does the "role" attribute bring semantic meaning to the computer itself?

[Stevie D]

Would the <NAV> tag help SEO? For example, do you know if the search engine developers could use that to create more relevant results since DIV is meaningless to acomputer, but <NAV> has semantic meaning, isn't HTML5 really about preparing for the future of the Semantic Web as envisioned by Tim Berners-Lee? It's a concept that I am starting to understand more now, and seeing how it has more possibilities that we can experience now. Does that mean that HTML5 is essentially laying the groundwork, the path, for computer interaction to become much more advanced in the future? If that is the case, maybe I can understand now, why HTML5 is introducing tags that may add extra markup, and don't seem to have perceived value now, but are setting the stage for the future. I am open to that.

In theory, elements like <nav> and <header> do open the way for a more semantic web. In terms of SEO, Google is pretty smart already, and I'm sure has good enough pattern recognition to be able to identify the navigation menu, header content and boilerplate footer on 95% + of websites, so it's unlikely to offer much of a benefit, especially as Google will still need to keep on figuring out sites that don't use the new elements.

It could be a great benefit to assistive technology (just like ARIA roles), but I suspect it will be a long while before that starts to make itself felt in the real world.

[sdt76]

In theory, elements like <nav> and <header> do open the way for a more semantic web. In terms of SEO, Google is pretty smart already, and I'm sure has good enough pattern recognition to be able to identify the navigation menu, header content and boilerplate footer on 95% + of websites, so it's unlikely to offer much of a benefit, especially as Google will still need to keep on figuring out sites that don't use the new elements.

I did come across this quote from Google Webmaster Central:

"Our general strategy is to wait to see how content is marked up on the web in practice and to adapt to that. If we find that more and more content uses HTML5 markup, that this markup can give us additional information, and that it doesn’t cause problems if webmasters incorrectly use it (which is always a problem in the beginning), then over time we’ll attempt to work that into our algorithms…."

It could be a great benefit to assistive technology (just like ARIA roles), but I suspect it will be a long while before that starts to make itself felt in the real world.

To me it's sort of hazy as to what people expect the fabled Semantic Web to actually do. It's hard to get a handle on what people like Berners-Lee actually expect the results to be in 10 years or so. Like you said, if I use quotation marks, I am able to find exactly what I want on Google 99% of the time, or it probably isn't even on the web. I'd like the believers of the Semantic Web to actually give some concrete ideas that are unique, that have some "wow" factor. So far, while I am far from poo-poing the idea, I just shrug right now.

[Stomme poes]

Does the "role" attribute bring semantic meaning to the computer itself?

Not that I know of. The browser's accessibility layer passes it on to accessibility technology. But it wouldn't be passed on to a calendar application on that computer. The new semantics might, in the future, but so far as I know roles are pretty much created for Accessibility Technologies.

[deathshadow60]

Any way you look at it, NAV is just idiotic bloat in it's current form -- being used and abused for content that either already has perfectly good meanings on it,

Much like 99% of the new tags from HTML 5, it's all a bunch of BS being used to sell books and videos on the new hype, while not providing ANY tangible advantages over the existing recommendation specs.

I really feel sorry for anyone duped into believing otherwise.

[Stomme poes]

I really feel sorry for anyone duped into believing otherwise.

I'm waiting for my flying car, and user agents who understand these new semantics and then also other applications on my computer so information can be passed between them.
Who knows, it could happen. Something more than, if you stuff a gazillion spans with classes all over the place, Google will index and display your site with Rich Snippets info.

[sdt76]

Yeah, right now it does seem pointless other than the additional semantics, which don't seem to have much use right now anyway, other than screen reader agents adopting them, which I hear they are busy doing. Apparently, HTML5 give us the option of having several document outlines in one page? But again, I am not sure I understand the benefit of that yet either. Also, implementation of that is inconsistent and sometimes requires creating H elements, just to hide them with CSS, so that the document outlines will make sense. So that's pretty clumsy and confusing right now too.