Firstly, very sorry if this is not a "true" stackoverflow question. But it's something I've always wondered about...
When you code a navigation bar for a site (html) I've read that it is very good practice, if not the ONLY practice to implement it using the list tag. e.g.
<ul>
<li> Home </li>
<li>About Us</li>
<li>Blog</li>
<li>Contact Us</li>
</ul>
And then apply the necessary styling that displays the list horizontally and so on and so forth.
But is this standard set in stone or does one only do it this way if it's the best option to do so... Because currently I have a navigation bar to do that is not your 'standard' nv bar so to speak, and it's a little bit of a mission to implement it as a list. A few link tags placed in some divs will work nicely. But of course I do not want to do this that method if it's going to make people point and laugh at me...
Thanks in advance!
Why use lists for site navigation?
Part of designing a site using web standards involves the use of semantically correct code. To quote "Brainstorms and Raves":
Good HTML structure is based on logic, order, and using semantically correct markup. If you have a heading use the heading element, beginning with the H1 element. If you have a paragraph, use a paragraph element. If you have a list, use a list item element.
At a structural level, site navigation is simply a list of links to other areas of the site. Therefore, the best method for marking up site navigation is (arguably) to use a list element.
If you use good HTML structure, then text-based browsers, screen readers, non-CSS supporting browser, browsers with CSS turned off and search bots will be able to access your content more easily.
A nice article on this is here
Related
Right now I am working on the website of a project working with handicapped people and looking for a mobile navigation with great accessibility and a no-js fallback. First i was thinking about using the :target-pseudoclass to open and close the navigation, but I cant open a sub-navigation this way since the main-nav closes if it looses the target. Then I was looking at the checkbox hack but there I get a roblem with the accessibility since Checkboxes or Radio-Buttons have another use case, a different way of control and also they are form elements, you should not use outside a form. Is there any clean and accessible way to get such a navigation working?
I hve a navigation like thw following:
<nav>
<ul>
<li>
Link
<ul class="sub-menu">
<li>
</li>
</ul>
</li>
</ul>
</nav>
The navigation can be quite big so I dont want the sub menus to be visible the whole time (if possible), so that you dont need to scroll such along time.
This is not a question to give me the exact code, I just need some hints to find a way for an easy accessible no-js mobile navigation with sub-menus (maybe with an example)
(navigation layout picture)
I have the navigation-layout of tabs and sub-tabs, which i want to make accessible via text-reader/lynx. It consists of the main pages "Startseite", "Über", "Interessant", "Orte", as well as the sub-pages "Linköping", "München" and "Baustelle". The logical structure would thus be:
Startseite
Über
Interessant
Linköping
München
Baustelle
Orte
But since I use a layout of several div-tags, it only yields this in lynx:
Startseite
Über
Interessant
Linköping
München
Baustelle
Orte
The questions (or solutions I don't know how to implement yet) now are:
(1) how do I improve my layout to make it accessible via text-reader/lynx
... or
(2) how do I adjust a layout of unorderd lists and sub-lists (see code) too look like my current tabbed navigation-layout?
<nav>
<ul id="mainpages">
<li>Startseite</li>
<li>Über</li>
<li>Interessant
<ul id="sub1">
<li>Linköping</li>
<li>München</li>
<li>Baustelle</li>
</ul>
</li>
<li>Orte</li>
</ul>
</nav>
keep in mind that my main tasks is making it text-reader/lynx accessible. I though of using a layout like this, since it is easily styled with #some_ul_id {display: inline-block}:
<nav>
<ul id="mainpages">
<li>Startseite</li>
<li>Über</li>
<li>Interessant</li>
<li>Orte</li>
</ul>
<ul id="sub1">
<li>Linköping</li>
<li>München</li>
<li>Baustelle</li>
</ul>
</nav>
My third question is:
(3) Is this good practice? Should I do it?
It is the easiest way, though solution (2) would be nicer, since it is more logical.
From an accessibility perspective, the way to markup the solution so that it semantically represents what you are trying to achieve is to use the WAI-ARIA menubar, menu and the various menuitem roles. You should also use the aria-haspopup="true" attribute to show sub-menus and the aria-expanded attribute to track when the menu is expanded. In order to achieve the semantic markup of the hierarchy, you will want to have hierarchical lists as this is the easiest way to represent the hierarchy in an understandable way.
Here is a link to a full dynamic ARIA menu example http://dylanb.github.io/bower_components/a11yfy/examples/menu.html
You will need to ensure that each menu item is keyboard focusable using an href attribute on an anchor tag will do this for you as long as you look for the 'click' event and don't do anything funky with mousedown/mouseup etc.
One way to achieve this could be to absolutely position the sub-menu – of course that requires that you know beforehand that there’ll be enough space, so that items don’t go over multiple lines (resp. you have an alternative at hand for smaller screens via media queries).
So you would position the outer ul (or the nav itself) relative, and then on :hover over a main menu item you make the sub-ul visible, that is positioned absolutely in such a way that it comes to lay underneath the line of main menu items – like this: http://jsfiddle.net/0rpyLqtn/
Other slight variations are easily imaginable; if you don’t want “blank space” underneath the single line of main menu items, you could f.e. give that ul a border-bottom instead of a margin-bottom, and have the border color of it visible at all times, like this: http://jsfiddle.net/0rpyLqtn/1/
Since you have accessibility in mind, you might also want to pay attention to how this kind of menu behaves on devices that do not have a “mouse” as input device. Getting such a menu to be accessible via keyboard can be tricky, and on touchscreens a menu based on :hover might not work that well either. Anyhow, such issues have been discussed on the net already, so with a little research you should be able to find solutions/workarounds for these issues as well.
In HTML5, I know that <nav> can be used either inside or outside the page's masthead <header> element. For websites having both secondary and main navigation, it seems common to include the secondary navigation as a <nav> element inside the masthead <header> element with the main navigation as a <nav> element outside the masthead <header> element. However, if the website lacks secondary navigation, it appears common to include the main navigation in a <nav> element within the masthead <header> element.
If I follow these examples, my content structure will be based on the inclusion or exclusion of secondary navigation. This introduces a coupling between the content and the style that feels unnecessary and unnatural.
Is there a better way so that I'm not moving the main navigation from inside to outside the masthead <header> element based on the inclusion or exclusion of secondary navigation?
Main and Secondary Navigation Example
<header>
<nav>
<!-- Secondary Navigation inside <header> -->
<ul>
<li></li>
</ul>
</nav>
<h1>Website Title</h1>
</header>
<nav>
<!-- Main Navigation outside <header> -->
<ul>
<li></li>
</ul>
</nav>
OnlineDegrees.org is an example site that follows the above pattern.
Main Only Navigation Example
<header>
<h1>Website Title</h1>
<nav>
<!-- Main Navigation inside <header> -->
<ul>
<li></li>
</ul>
</nav>
</header>
Keyzo.co.uk is an example site that follows the above pattern.
Excerpts from Introducing HTML5 — Added on 02-Feb-11, 7:38 AM
Introducing HTML5 by Bruce Lawson and Remy Sharp has this to say about the subject:
The header can also contain navigation. This can be very useful for site-wide navigation, especially on template-driven sites where the whole of the <header> element could come from a template file.
Of course, it's not required that the <nav> be in the <header>.
If depends largely on whether you believe the site-wide navigation belongs in the site-wide header and also pragmatic considerations about ease of styling.
Based on that last sentence, it appears that Bruce Lawson—author of the chapter those excerpts are from—admits that "pragmatic considerations about ease of styling" yield a coupling between the content and the style.
It's completely up to you. You can either put them in the header or not, as long as the elements within them are internal navigation elements only (i.e. don't link to external sites such as a twitter or facebook account) then it's fine.
They tend to get placed in a header simply because that's where navigation often goes, but it's not set in stone.
You can read more about it at HTML5 Doctor.
I do not like putting the nav in the header. My reasoning is:
Logic
The header contains introductory information about the document. The nav is a menu that links to other documents. To my mind this means that the content of the nav belongs to the site rather than the document. An exception would be if the NAV held forward links.
Accessibility
I like to put menus at the end of the source code rather than the start. I use CSS to send it to the top of a computer screen or leave it at the end for text-speech browsers and small screens. This avoids the need for skip-links.
It's a little unclear whether you're asking for opinions, eg. "it's common to do xxx" or an actual rule, so I'm going to lean in the direction of rules.
The examples you cite seem based upon the examples in the spec for the nav element. Remember that the spec keeps getting tweaked and the rules are sometimes convoluted, so I'd venture many people might tend to just do what's given rather than interpret. You're showing two separate examples with different behavior, so there's only so much you can read into it. Do either of those sites also have the opposing sub/nav situation, and if so how do they handle it?
Most importantly, though, there's nothing in the spec saying either is the way to do it. One of the goals with HTML5 was to be very clear[this for comparison] about semantics, requirements, etc. so the omission is worth noting. As far as I can see, the examples are independent of each other and equally valid within their own context of layout requirements, etc.
Having the nav's source position be conditional is kind of silly(another red flag). Just pick a method and go with it.
#IanDevlin is correct. MDN's rules say the following:
"The HTML Header Element "" defines a page header — typically containing the logo and name of the site and possibly a horizontal menu..."
The word "possibly" there is key. It goes on to say that the header doesn't necessarily need to be a site header. For instance you could include a "header" on a pop-up modal or on other modular parts of the document where there is a header and it would be helpful for a user on a screen reader to know about it.
It terms of the implicit use of NAV you can use it anywhere there is grouped site navigation, although it's usually omitted from the "footer" section for mini-navs / important site links.
Really it comes down to personal / team choice. Decide what you and your team feel is more semantic and more important and the try to be consistent. For me, if the nav is inline with the logo and the main site's "h1" then it makes sense to put it in the "header" but if you have a different design choice then decide on a case by case basis.
Most importantly check out the docs and be sure if you choose to omit or include you understand why you are making that particular decision.
To expand on what #JoshuaMaddox said, in the MDN Learning Area, under the "Introduction to HTML" section, the Document and website structure sub-section says (bold/emphasis is by me):
Header
Usually a big strip across the top with a big heading and/or logo.
This is where the main common information about a website usually
stays from one webpage to another.
Navigation bar
Links to the site's main sections; usually represented by menu
buttons, links, or tabs. Like the header, this content usually remains
consistent from one webpage to another — having an inconsistent
navigation on your website will just lead to confused, frustrated
users. Many web designers consider the navigation bar to be part of
the header rather than a individual component, but that's not a
requirement; in fact some also argue that having the two separate is
better for accessibility, as screen readers can read the two features
better if they are separate.
I think the simpliest way to answer this is to check the MDN Web Docs and other web standards sites.
TL;DR
there is no right or wrong. It depends on what you build.
This is a question that every web developer asks himself at some point. I had asked myself the question several times. To answer this question, I looked at the source code of Stackoverflow. And SO has the nav tag inside the header tag.
Which is absolutely right here, because if you look at the structure of the view of the top bar, it quickly becomes clear that this is the right way to go. Here you can simply work with the flexbox design. Which in turn would only work with a superordinate tag if both tags were not nested. Which would unnecessarily bleach the DOM. like:
<div class="flex">
<header></header>
<nav></nav>
</div>
On the other hand, there are headers that are simply a large image with a logo inside. Or a whole line with the logo. Here it doesn't matter whether the nav tag is above or below the header tag.
Conclusion: The tags only have a semantic meaning and are not a specification for a template structure. You build the template according to your ideas or the expectations of the users.
Both cases are right!
<!-- case 1 -->
<body>
<header></header>
<nav></nav>
<main></main>
</body>
<!-- case 2 -->
<body>
<header>
<nav></nav>
</header>
<main></main>
</body>
Live Example
HTML5 <menu> element
HTML5:
<menu type="list">
<li> Sign Up </li>
<li> Log In </li>
</menu>
I want to add a signup / login menu to my website.
Would using <menu> be semantic?
Should I use <ul> instead?
Edit: I'm using semantic HTML5. Browser support is irrelevant.
As I'm sure you're aware:
The menu element represents a list of commands.
It really just depends on how you define "list" and "commands." Are "Login" and "Sign up" commands? Or are they list items? Personally I think they're commands. A list (ul or ol) is more akin to something longer, two items just don't seem to make a list, to me. Login and Sign up seem like commands because they're what Stephen Krug, in Don't Make Me Think calls "Utilities":
Utilities are links to important elements of the site that aren't really part of the content hierarchy.
These are contrasted with what he calls "Sections":
links to the main sections of the site: the top level of the site's hierarchy [navigation]
This makes sense semantically: You use <nav> for Krug's "sections" (navigation) and <menu> for utilities or commands (Log in, Sign Up, Search, etc.)
I don't think it's going to matter too much. There are a lot of options you can choose, even the new <nav> tag. But an unordered list certainly isn't going to wreak havoc on your code or not pass HTML5 validation.
I still use unordered lists for my navigations. This includes websites with a top heading nav, sidebar, and footer links. But speaking in semantics, I would recommend the nav element over menu.
In HTML5, I know that <nav> can be used either inside or outside the page's masthead <header> element. For websites having both secondary and main navigation, it seems common to include the secondary navigation as a <nav> element inside the masthead <header> element with the main navigation as a <nav> element outside the masthead <header> element. However, if the website lacks secondary navigation, it appears common to include the main navigation in a <nav> element within the masthead <header> element.
If I follow these examples, my content structure will be based on the inclusion or exclusion of secondary navigation. This introduces a coupling between the content and the style that feels unnecessary and unnatural.
Is there a better way so that I'm not moving the main navigation from inside to outside the masthead <header> element based on the inclusion or exclusion of secondary navigation?
Main and Secondary Navigation Example
<header>
<nav>
<!-- Secondary Navigation inside <header> -->
<ul>
<li></li>
</ul>
</nav>
<h1>Website Title</h1>
</header>
<nav>
<!-- Main Navigation outside <header> -->
<ul>
<li></li>
</ul>
</nav>
OnlineDegrees.org is an example site that follows the above pattern.
Main Only Navigation Example
<header>
<h1>Website Title</h1>
<nav>
<!-- Main Navigation inside <header> -->
<ul>
<li></li>
</ul>
</nav>
</header>
Keyzo.co.uk is an example site that follows the above pattern.
Excerpts from Introducing HTML5 — Added on 02-Feb-11, 7:38 AM
Introducing HTML5 by Bruce Lawson and Remy Sharp has this to say about the subject:
The header can also contain navigation. This can be very useful for site-wide navigation, especially on template-driven sites where the whole of the <header> element could come from a template file.
Of course, it's not required that the <nav> be in the <header>.
If depends largely on whether you believe the site-wide navigation belongs in the site-wide header and also pragmatic considerations about ease of styling.
Based on that last sentence, it appears that Bruce Lawson—author of the chapter those excerpts are from—admits that "pragmatic considerations about ease of styling" yield a coupling between the content and the style.
It's completely up to you. You can either put them in the header or not, as long as the elements within them are internal navigation elements only (i.e. don't link to external sites such as a twitter or facebook account) then it's fine.
They tend to get placed in a header simply because that's where navigation often goes, but it's not set in stone.
You can read more about it at HTML5 Doctor.
I do not like putting the nav in the header. My reasoning is:
Logic
The header contains introductory information about the document. The nav is a menu that links to other documents. To my mind this means that the content of the nav belongs to the site rather than the document. An exception would be if the NAV held forward links.
Accessibility
I like to put menus at the end of the source code rather than the start. I use CSS to send it to the top of a computer screen or leave it at the end for text-speech browsers and small screens. This avoids the need for skip-links.
It's a little unclear whether you're asking for opinions, eg. "it's common to do xxx" or an actual rule, so I'm going to lean in the direction of rules.
The examples you cite seem based upon the examples in the spec for the nav element. Remember that the spec keeps getting tweaked and the rules are sometimes convoluted, so I'd venture many people might tend to just do what's given rather than interpret. You're showing two separate examples with different behavior, so there's only so much you can read into it. Do either of those sites also have the opposing sub/nav situation, and if so how do they handle it?
Most importantly, though, there's nothing in the spec saying either is the way to do it. One of the goals with HTML5 was to be very clear[this for comparison] about semantics, requirements, etc. so the omission is worth noting. As far as I can see, the examples are independent of each other and equally valid within their own context of layout requirements, etc.
Having the nav's source position be conditional is kind of silly(another red flag). Just pick a method and go with it.
#IanDevlin is correct. MDN's rules say the following:
"The HTML Header Element "" defines a page header — typically containing the logo and name of the site and possibly a horizontal menu..."
The word "possibly" there is key. It goes on to say that the header doesn't necessarily need to be a site header. For instance you could include a "header" on a pop-up modal or on other modular parts of the document where there is a header and it would be helpful for a user on a screen reader to know about it.
It terms of the implicit use of NAV you can use it anywhere there is grouped site navigation, although it's usually omitted from the "footer" section for mini-navs / important site links.
Really it comes down to personal / team choice. Decide what you and your team feel is more semantic and more important and the try to be consistent. For me, if the nav is inline with the logo and the main site's "h1" then it makes sense to put it in the "header" but if you have a different design choice then decide on a case by case basis.
Most importantly check out the docs and be sure if you choose to omit or include you understand why you are making that particular decision.
To expand on what #JoshuaMaddox said, in the MDN Learning Area, under the "Introduction to HTML" section, the Document and website structure sub-section says (bold/emphasis is by me):
Header
Usually a big strip across the top with a big heading and/or logo.
This is where the main common information about a website usually
stays from one webpage to another.
Navigation bar
Links to the site's main sections; usually represented by menu
buttons, links, or tabs. Like the header, this content usually remains
consistent from one webpage to another — having an inconsistent
navigation on your website will just lead to confused, frustrated
users. Many web designers consider the navigation bar to be part of
the header rather than a individual component, but that's not a
requirement; in fact some also argue that having the two separate is
better for accessibility, as screen readers can read the two features
better if they are separate.
I think the simpliest way to answer this is to check the MDN Web Docs and other web standards sites.
TL;DR
there is no right or wrong. It depends on what you build.
This is a question that every web developer asks himself at some point. I had asked myself the question several times. To answer this question, I looked at the source code of Stackoverflow. And SO has the nav tag inside the header tag.
Which is absolutely right here, because if you look at the structure of the view of the top bar, it quickly becomes clear that this is the right way to go. Here you can simply work with the flexbox design. Which in turn would only work with a superordinate tag if both tags were not nested. Which would unnecessarily bleach the DOM. like:
<div class="flex">
<header></header>
<nav></nav>
</div>
On the other hand, there are headers that are simply a large image with a logo inside. Or a whole line with the logo. Here it doesn't matter whether the nav tag is above or below the header tag.
Conclusion: The tags only have a semantic meaning and are not a specification for a template structure. You build the template according to your ideas or the expectations of the users.
Both cases are right!
<!-- case 1 -->
<body>
<header></header>
<nav></nav>
<main></main>
</body>
<!-- case 2 -->
<body>
<header>
<nav></nav>
</header>
<main></main>
</body>