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>
Related
Typically you only want one H1 per page for screen readers. But I have seen a trend where the site logo in a header has an H1 around it and a separate main headline on a page also has an H1. Is this acceptable or is there a better way to handle this?
WCAG compliance
From a perspective of WCAG and compliance, this is acceptable, you can have multiple h1s on a page, it is still in the HTML5 spec.
Conventions for headings
However, convention and best practices advises there is only one, visible <h1> on a page and that <h1> should accurately describe the current page.
The main reason for this is assistive technology, namely screen readers.
Someone who uses a screen reader is likely to navigate by sections, links or headings using shortcuts. Obviously in this cases headings is the bit we are focusing on.
They use the keys 1-6 to cycle through headings. When landing on a page the first thing they might do is press "1" to get to the main heading on the page.
If pressing "1" instead reads out the site logo it might be confusing and they may think the site structure is wrong and instead start cycling <h2>s with the "2" key. This may take them a little while to realise the page structure is not typical.
It may only take a minute or so before a screen reader user realises the strange structure of your site, so it doesn't make it inaccessible, but in terms of user experience it isn't great.
Convention for company logos as part of the <header>
The convention for a logo is to wrap it in a hyperlink and point it to the home page. Expected behaviour is key for accessibility.
The simplest form of this would be:
<header>
<!-- logo wrapped in anchor pointing to home page -->
<a href="homepage">
<!-- notice the alt text is the purpose of the link so the link has descriptive link text. -->
<img src="yourlogo.jpg" alt="{company name} homepage" />
</a>
<nav>
<!-- ul with all nav items -->
</nav>
</header>
So whoever started that trend needs to stop it, it doesn't even make sense from an SEO perspective so I am not sure why someone started that if it is indeed a trend!
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
I'm trying to work out how I can make my CSS as de-coupled from my HTML as possible. The way to do that would be to write the basic layout elements in the HTML in a standard way, so that different CSS files could know exactly what the mark-up it's working with will look like without having seen it.
So I was wondering if there exist anywhere a set of standards for how you should name your layout elements and what order to put them in. E.g. a sensible way to mark-up my page would be as follows (note that I'm using HTML5 elements and following the theory that you should never use IDs for CSS rules):
<body>
<div class="container"> <!-- central "squeeze" for the content -->
<header>
<img class="logo" />
<nav class="primary"></nav> <!-- main navigation -->
</header>
<aside class="pre"></aside> <!-- left column -->
<article class="main"></article> <!-- central main content -->
<aside class="post"></aside> <!-- right column -->
</div>
</body>
Many pages use something similar to this basic layout. But as you can see, the name of the "container" or "primary" class will vary a lot, as will the use of <aside> for columns. Also, there are probably variances in ordering, like some people would put the <nav> element after the <header> rather than inside it, or the column elements inside the <article> element.
Does anyone know of any work that's been done to standardise the ordering and naming of these commonly used layout elements? Like a microformat or something?
I don't think there is an absolute standard, since no two websites are the same.
Allright, some are, but that's not the point. :)
Anyway, since the CSS is made specifically to markup that single website, you can't actually decouple it in such detail. You won't find some ready made CSS sheets that you can just plugin your website to place all those navigation containers.
I think the best way is to come up with a standard for yourself and stick to it. I hope you would be able to find better names than the often used but quite abstract 'container'. And maybe, some day, it will become the defacto standard.
I'm looking at the BBC site, and putting together something following a similar overall pattern, and determining how to mark it up appropriately is stumping me somewhat.
The BBC consists of several what could be considered sites in their own right:
http://www.bbc.co.uk
http://www.bbc.co.uk/comedy/
http://www.bbc.co.uk/news/
www.bbc.co.uk/[a-lot-more-stuff]
(these could all be subdomains instead - indeed, this is the case for me - but the URLs are not important)
Each of these is essentially self-contained, with its own content, menu and look and feel. However all of them are tied together by the use of the (slightly variable but mostly) static header bar. This contains the header "BBC" along with links to all of the various sub-sites.
So the question is, how should this be marked up. I see several different options:
The main BBC header is the site's main <header> and <nav>. This is sort of correct, because it is but it ends up essentially de-emphasising the importance of the sub-site's actual content. When it boils down to it (to use the examples above), the title "Comedy" and associated menu is the main content of the page, not the BBC bar.
Make the sub-sites' header and navigation the ones which are marked up within <header> and <nav>. This feels better, but it then opens up the question as to what the BBC bar now is? An option is to use an <aside>, which then contains its own <header> and <nav>. As far as I know, this is fine for the header but having that other <nav> element is still weird. Better option than the above?
Do the same as number 1 (BBC bar has the main <header> and <nav>), but mark up the rest of the page inside an <article> element. The spec indicates that the article element is to be used for items which make sense on their own, which is the case here. And it'll also make sense for it to have its own <header> (and <nav>? Is this pushing it somewhat?) But this seems to be stretching the definition of an 'article' rather further than its dictionary definition allows.
To me, having given it some thought and thrown some ideas back and forth on Twitter, number 2 seems the best of these options. However the idea of essentially putting the contents of an <aside> as the top element on the page (visually and in markup, since it seems to make most logical sense this way) doesn't quite sit right with me.
Am I overlooking an obvious solution or is this an usual enough pattern that it does make itself as difficult as it seems? And surely I can't be the only one to puzzle over this?
Thanks for any thoughts.
The main header should be, as you pointed out, marked up in <header> and <nav>.
I would then mark each additional page content in an <article> containing it's own <header> and <nav>. Ignore the dictionary definition of article, it doesn't really apply here. It's fine to have more than one <nav> element on a page, as long as its contents navigate within the site, that makes sense.
Putting the top header in an <aside> also doesn't seem to be correct to me as the content isn't stand alone.
Just my thoughts on the subject!
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>