<nav> vs. <div role="navigation">

Hello,

Which one would you pick over the other and why?

Regards,

-jj. :slight_smile:

At this point, the div since HTML(5) support is still sketchy.

In a few years when IE9 is the dying browser, I’d probably go with nav.

I would pick
<ul role=“navigation”>

because most of the time, your navigation is a list of links. If it isn’t, I would tack the navigation role on whichever container was closest (nesting-wise) to whatever you are calling “navigational thingies”. I would not include a site search form under this, even though it is a valid form of “navigation” for many people. Search forms should already have a role of “search”, as a separate thing.

Bruce Lawson and Remy Sharp’s book on HTML5 really stretched the meaning of “navigation” and were advocating <nav> and navigation roles all over the place… but they have since scaled back, way back.

A note: using a manual role of navigation on a nav tag has been known to screw up the NVDA screen reader (let alone Window-Eyes). Since eventually HTML5 wants to have native roles on most/all elements, in the unforseen future the nav tag should by default have a “navigation” role.

When that happens, user agents should then be able to easily tell the difference between a native role and a landmark (ARIA) role.

Me too!

Besides, <nav> is not an HTML element.

Not yet, anyway. :slight_smile:

role=“” is not an HTML attribute either in that case.

Besides, <nav> is not an HTML element.

HTML5 is not HTML??

Are you not falling for the “living standard” indoctrination??? A pox upon thee and thyne house!

role=“” is not an HTML attribute either in that case.

It’s become my second source of invalid HTML4, right after the tabindex=“-1” for either removing redundant links from tab order or making IE6 actually work with skip links : )

And to think, I used to write valid HTML…

At least it does something at this time.

Are you not falling for the “living standard” indoctrination?

Not really. I’m just saying that something needing a life support system to breathe at all is not really “living”.

That’s a valid reason.

I’d be inclined to use the <nav> but if you needed a <div> inside that to markup the content in the CSS I’d rely on that for styling/coding leaving the <nav> as a bonus for browsers/search engines that recognised it.

leaving the <nav> as a bonus for browsers/search engines that recognised it.

Which currently, so far as I know, none do (FF has an experimental html5 parser that you can switch on… not sure if Opera’s done the same yet).

Firefox has shipped with the HTML5 parser enabled by default since FF4. Ragnarök hasn’t shipped yet but can be tested in a Labs build.

Firefox has shipped with the HTML5 parser enabled by default since FF4.

Ah I’m still on 3.6x.

Ragnarök hasn’t shipped yet but can be tested in a Labs build.

OMIDOG THE END OF THE EARTH IN AN EPIC BATTLE OF FIRE AND ICE AND HTML5!!!

Where the hell have I been?

When IE finally does it they should call it ARMAGEDDON

what is “role” for?

I’ll go with <nav> this is HTML5, the future of web design.
just use ie fix javascript to make it compatible to idiot browsers.

:eek: … why?

what is “role” for?

Two things:
Roles were thought up during XHTML2 to give UA’s better ideas on what the purpose of a tag was.

HTML5 is incorporating these roles and eventually every tag (or maybe just almost every tag) will have a default “role” or a possible set of roles.

However there are also ARIA landmark roles which the author would put manually as an attribute on a tag; these are pretty much for screen reader users. Landmarks generally do the job of skip links except better: users can have the major landmarks announced to them on page load, and can choose to go directly to one of those landmarks (“navigation” would be the main page navigation list, “main” would be the main content (and there is really no HTML5 equivalent here since “main” would be whatever isn’t in some other role), “complimentary” for extra stuff that could sit on its own like company info stuff (not tied directly to the content in the “main” section)).
Roles are also good for turning “stupid tags” like span when used to build widgets (like a slider) into meaningful objects. So when you are building Stuff That Does Stuff on a page out of plain-jane HTML elements (which are not at this point marking up content but building stuff), since there’s no <slider> tag, the role can inform users what the thingie is and what to do with it.

They are of course optional but I’m quite happy with where they are going… this is a great tool for web and web-app developers.

I’ll go with <nav> this is HTML5, the future of web design.
just use ie fix javascript to make it compatible to idiot browsers.

Idiot browsers??

People aren’t just using idiot browsers. They are using the latest of very expensive screen reading technology as well. I suppose you’re willing to pay for their upgrade though.

Personally (this means opinion follows), requiring scripting simply to make a user agent understand markup defeats the whole purpose of decive-independent markup. The whole reason HTML was invented. Why even use HTML? Build the whole thing in Flash or something. If you’re going to tell people they must use your software and hardware of choice just to get access to (still mostly text) content, why not just make everyone use one OS and one browser and be done with all this cross-browser dancing game. Like it was after the first browser wars, when everyone used XP and IE6. Monoculture for the win.

The more I read about Modernizr and the error messages the UA is supposed to generate with the new form types and how you’re supposed to need to access a JS API to make them actually make sense to your users… hell, I might as well use that new Javascript I saw that actually just builds your whole page in Javascript… couple that with Node.js on the back and you can use just one language for absolutely everything. Then avoid actual HTTP by coupling it with Google’s SPDY or something.

The future’s lookin’ awesome, to borrow an overused word from Mozilla.

I am not ready for the apocalypse?

Actually, two reasons:
Every time I upgrade a browser that I actually use for more than just testing, I have to waste a bunch of my time fixing all the stuff they broke, changed, and made retarded (I still have scars from the disaster of the “awesomebar”). This is just a fact of life, but I still like to do it as few times as possible. Crawling through about:config is not exactly my idea of a good time, similar to taking the toilet apart and replacing the float mechanism on the joy scale.

So in this case, not all of my necessary add-ons worked in FF4, and by the time they did, FF4 was suddenly stopped with no further security updates or anything and 5 was out. I didn’t bother looking to see which of my plugins work with 5… I’m pretty sure by they time they do, 5 will be discontinued and 6 will be out.
I donated to Chris Pederick because I think the tool I use the most is the web developer tool bar, but I also use NoScript, Firebug (both of which update pretty well), a plugin to fix the removal of the Properties option (seriously yes a plugin to add back functionality other browsers have that someone thought was a good idea to remove because “only nerds use it”!), Live HTTP Headers (ok this one I could live without but it’s handier than tail -f server logs), and the JuicyStudio Accessibility Toolbar (this one takes time to update). Plus I still have JAWS 10 which still just works better with FF3 (someday, I’ll upgrade to 12 or something better…).

Second reason: like 99% of all software users, I do most of my updates via an automatic updating thingie. So long as I can update my old browser I’m not really willing to just upgrade to a whole new one (because of reason #1, avoiding having to fix everything they broke).

There is FF4 on the separate windows machine here, but it is only used to check that some new bug didn’t totally destroy any of my sites. Apparently IE9 broke some stuff, but I’m poor and can’t afford buying a whole new operating system just to check a single browser, and apparently the company I work for doesn’t care so I guess that’s that.

Eventually they will stop supporting FF3x OR I will upgrade my OS and it’ll just come with whatever the latest FF is and I’ll just have to deal with it.

Meanwhile I do tend to have the latest or near-latest Chrome and Opera simply because the automatic update-thingie does tend to just offer whole new versions instead of doing what Mozilla is doing. But I still can’t WebGL.

Hello,

A bit of hair splitting, but complementary (I noticed the same typo in 320 and Up) is actually tied to the main section, but loosely tied.

complementary:
A supporting section of the document, designed to be complementary to the main content at a similar level in the DOM hierarchy, but remains meaningful when separated from the main content.

:slight_smile:

Got me on both counts:

A bit of hair splitting, but complementary (I noticed the same typo in 320 and Up)

It’s true that I have to go look up the spelling in a search engine before using it on a page, because the JuicyStudio toolbar will happily tell me yup, I have landmarks and one is “complimentary” (which apparently just won’t mean anything lawlz). Meaning I have no easy way of catching it, and I never remember out of my head which one is giving compliments and which one is complementing.

In fact the reason I discovered vim’s :tabdo was specifically to fix 20 documents where I had <footer role=“complimentary”> aaaarg

…is actually tied to the main section, but loosely tied.

Indeed, more like a sidebar. When I first started using roles I had the above (footer was complementary) but later realised it was better off as “contentinfo” as it had site info like links to privacy policy, terms and conditions, etc.

Ha ha, 20 role=“complimentary”. That’s a good one. Note that I could find use for such a role, though.

It seems that a lot of people keep on using “aside” when they mean “complementary” and, as you stated, “complementary” when they mean “contentinfo”.

It seems that a lot of people keep on using “aside” when they mean “complementary”

Those two are awfully close, yes. Except if I were to use <aside> for say a sidebar, I’d only bother adding the role if it was a case where I’d want to add a skip link to it anyway (I’ll add skip links for sighted keyboarders and older sr’s either way).

Or do you mean people are using role=“aside”? Does such a role exist?

Firefox 3.6 will be the next IE 6. Yuppers.