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!
Related
I am displaying articles on my document, and displaying links to other articles at the bottom.
HTML looks something like this:
<article>...</article>
<article>...</article>
...
<article>...</article>
<aside>
Other recent articles
<div> ... </div>
</aside>
I think the links to other articles should be , because it is defined in MDN as:
a section of the page with content connected tangentially to the rest, which could be considered separate from that content.
But the name <aside> seems to imply that the element should be either on left or right side. Can it be in the bottom?
With HTML, you should always think of your usage of tags as structural, not presentational.
So don't think of <aside>'s name as a physical description. Think of it in terms of its purpose in structuring content: to associate tangentially related content to the main content. That has nothing to do with where it's placed on the physical page design.
If you're designing your page with media queries, for example, I bet your mobile view isn't going to put an <aside> on either side of the screen because there is not enough room. You'll likely position <aside> content after the main content. But when you scale up to a desktop-sized screen, you have plenty of room to put that content on the left or right side (if you want, but you're not forced to!).
I also think back on Shakespeare's usages of asides: the characters would pause from the main play to talk directly to the audience about what they were thinking or what was going on. (Kevin Spacey's character does it a lot in House of Cards too.)
Update: I also looked up the definition of the word "aside":
a remark that is not directly related to the main topic of discussion.
"the recipe book has little asides about the importance of home and family"
The term "aside" is used in a similar vein to how one might say "on a side note" (in fact, that is what the <aside> element is designed for). It doesn't necessarily imply that the content must be laid out on the left or right side — that is a layout concern which has little to do with content semantics. If your layout calls for aside content to be placed at the bottom, you are free to style it accordingly.
As an aside (heh), if it is a set of navigation links, you may want to mark it up as a <nav> instead, but that is up to you.
I think you can interpret aside in different ways. As in, if the content wasn't there, the main point of the page could still be understood. Thus, aside should hold anything tangentially related to the content.
Ask yourself, if you remove the content within aside, will the meaning of the page stay the same?
We have a crawler that is crawling hundreds of thousands of pages per week. Currently to get the data from the crawled HTML we manually take a look at the HTML and see that "OK, Data A is within <div class=".info-list"> and Data B is inside <h1>", and then we use a parser to parse the data from those div's.
I guess this is the most common way to parse crawled HTML for most people, but it means that we have to know the HTML structure of all the pages and domains that we crawl. So it is not very scalable.
If we could just figure out what div the "main content" is, so that we can ignore other things such as "Relevant products" or "Relevant articles", or "Main menu" and so on, we could easily parse the data in the same way as we do now but without having to specify the exact div names and position of each data.
So... How do we figure out which is the "main div" of a page?
I'm pretty sure that Google does this. They definitely know position of elements on a page, and if something is positioned in the "main content" or in the footer for example. How can they know this?
The methods that I can see to do this in a large scale is:
Render the page and look for the largest div's and start from there. But to render millions or hundreds of thousands of pages is not really cheap and efficient.
Try to figure it out from the content of every div. For example, the div with most links inside of it is probably the menu. The div with most text inside of it is probably the main content. But this gets really tricky if the content is like:
<body>
<div class="maincontent">
<div class="post-header">
<h1>Header of post</h1>
</div>
<div class="short-description">
Hello World!
</div>
<div class="long-description">
Hello New World!
</div>
</div>
</body>
Obviously the div we want to identify as the "main content" is <div class="maincontent">. But if we look for the div that have "most text". It would be .long-description.
This is starting to become quite a long question. But my point is, it's really hard to figure out which part of a website that is the "main content". And I'm asking any smart people out there to help me come up with a decent way to find out what div or divs that is probably containing the most important content of the page.
EDIT: I guess one way of rendering it is not to render every single page. But to render the domain. For example. If the domain structure is http://example.com/post/1-post-name/ I can save a render of that, and next time I find a page that is http://example.com/post/2-post-name/ I know that it probably have the same HTML template as the first one, and the "largest div" is probably the same.
So what techinique to do this server side? I mean to render it and to save the sizes and position of all the elements. I guess this seems to be a pretty decent way of doing it on large scale.
I would try multiple approaches. For example start with the obvious - is there an id="content" or class="main_content" ? Use it! Look for ids and classes that are common for big content blocks and if they exist then use them. If not then move on to less certain tests.
Next try narrowing things down. is there a <header> or <nav> tag? ignore that and everything above it. Ignore a <footer> or a class="sidebar"
Make some rules, let them run, and then manually expect what comes back and look for patterns when you're pulling too much or things are being left out. Adjust your rules and write new ones based on that.
At that point you might even let the ones get past all your tests go to a short list where you check them by hand and create domain specific rules where you can point out the exact div you want to use. You can still be very efficient with some human intervention, and visually looking over 8 sites out of 50 is still a pretty good deal.
I didn't really find a great way to decide which div is the "main content" yet, however I found PhantomJS which lets you render the page you are crawling on server side, and be able to use Javascript and jQuery to get sizes and positions of elements on the page you are crawling.
So by using PhantomJS you can definitely get which div is the "largest", which div is on top or bottom or center, which is a long way already on solving this issue of finding out which div on a page that is the "main content".
I have an assignment due in on the 18th of August 2014, and have now been told that I need to add certain section elements to my website. However, I do not know how to use them. what are the header, nav, main, article, aside, and footer elements use for and how do I use them in my website?
Since HTML is a Markup Language, there are specific tags that it outlines which are essentially considered "the right ones to use" in different places of your code. For example, if you were to put a navigation bar in your site, you would use the "nav" tag to outline the section in your code that contains the navigation bar code, but you could just as easily use a "div" without causing any different behavior. Now with that said,
Nav: The section that is usually just the top section of your page that holds links to different parts of your site (see the top of this page, however if you look at this page's source code you will notice they do not even use nav tags as specifically named tags such as these are not mandatory, you can simply use divs all over the place but that is not a good practice)
Header: The banner section if you will where the title of the page and other global information pertaining to the page exists (ie the a large representation of your site's logo or number of visitors for your site)
Main: The actual content of your site (the main content)
Article: Think of this as a blog post which typically consists of text and maybe an image
Aside: Usually inline with an article or some other block of text used to insert additional information (ie fun facts)
Footer: The bottom of your page which also contains links like the header, but usually are more verbose as well as copyright information (Stack overflow has a rather large one if you scroll to the bottom of this page)
You can read more about these specific tags here: Quackit - HTML 5 Tags and good luck with your project.
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>
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>