This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 7557 - add "type" attribute to <nav> to distinguish between navigation blocks that should be skipped and blocks that should be read out
Summary: add "type" attribute to <nav> to distinguish between navigation blocks that s...
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: All All
: P2 enhancement
Target Milestone: Needs Impl Interest
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
Keywords: NE
Depends on:
Reported: 2009-09-09 18:35 UTC by Michael[tm] Smith
Modified: 2014-09-26 21:09 UTC (History)
6 users (show)

See Also:


Description Michael[tm] Smith 2009-09-09 18:35:44 UTC
It would be useful to have a "type" attribute on <nav> with the enumerated values "primary" and "secondary".

Rationale and use case:

Many documents contain different classes of navigational content. In most documents that provide such classes of navigational content, the main difference is between primary navigation and secondary navigation.

The distinction between what constitutes primary navigation and what constitutes secondary navigation is of course not universal, but one way to describe the distinction would be: Primary navigation is the main set of navigational links for a site -- the important stuff that consistently and prominently appears in the same page on every page of a site -- and secondary navigation is the less important stuff that appears less prominently and perhaps less consistently and may not always be in the same place on every page of site.

In the section defining <nav> in the current draft spec itself, one of the examples (currently the second example there) shows a case of <nav> being used to mark up both some primary navigation and some secondary navigation. So that seems to help support the argument that it would be useful to have a standard means to mark up the different between those two classes of navigation.

Also, as the note at the beginning of the section on <nav> mentions, UAs such as screen readers [or, by the way, browsers on mobile handsets] can use the <nav> element as a way to determine what content on the page to initially skip and/or provide on only on request [in the same of browsers on mobile devices, they might, for example, want to provide access to such navigation through a soft-key menu on the device, instead of rendering it in the main text flow of the page].

But for such UAs, it would be useful to have a means to distinguish primary navigation from secondary navigation; for example, they might want to make the main navigation more easily skippable or available through other means, but  keep the secondary navigation within the main text flow.

So the use case here is basically to enable users to have a different user experience for primary navigation and secondary navigation in cases where it makes sense for them to -- and thus for page authors and UAs that want to allow end users a different user experience of primary navigation and secondary navigation, to provide a standard means for making the distinction between the two.
Comment 1 Michael[tm] Smith 2009-09-09 19:50:40 UTC
(In reply to comment #0)
> Primary navigation is the main set of
> navigational links for a site -- the important stuff that consistently and
> prominently appears in the same page on every page of a site

Make that, "prominently appears in the same *place* on every page of a site".
Comment 2 Ian 'Hixie' Hickson 2009-09-18 21:56:04 UTC
I think we should wait to have more implementation experience with <nav> as it is today before adding more features to it.
Comment 3 Maciej Stachowiak 2010-03-14 14:50:55 UTC
This bug predates the HTML Working Group Decision Policy.

If you are satisfied with the resolution of this bug, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:

This bug is now being moved to VERIFIED. Please respond within two weeks. If this bug is not closed, reopened or escalated within two weeks, it may be marked as NoReply and will no longer be considered a pending comment.
Comment 4 public-rdfa-wg 2013-01-24 06:33:50 UTC
This bug was cloned to create HTML WG bug 19060.
Comment 5 Ian 'Hixie' Hickson 2013-03-19 17:33:32 UTC
Are there any browsers interested in implementing this?
Comment 6 Ian 'Hixie' Hickson 2014-09-26 21:09:55 UTC
Closing for lack of interest. Even ARIA doesn't really have a way to do this.