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?
Until user agents (including assistive technologies) render adjacent links distinctly, include non-link, printable characters (surrounded by spaces) between adjacent links.
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.
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.
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.
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.
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.
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.
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.
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…
“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.”
“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.
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?
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.