I'm taking over website maintenance for a utility company. The previous developer used far more <div>s than I would. Most make sense to me, but I'm puzzling over this one:
<html>
<head></head>
<body>
<div id="wrapper">
<!-- All of the page content - header, footer, whatever -->
</div>
</body>
</html>
Everything in the <body> tag is surrounded by an additional named <div>. There's nothing before it or after it.
Is there a benefit to having a <div> there? My understanding is that all styling could be applied directly to <body> with the same effect. Even JavaScript could do identical things if I just declared <body id="wrapper">, couldn't it?
It's usually used for the sake of styling, e.g.,
body{
background-color: #FFF;
}
#wrapper{
background-color: #000;
width: 80%;
margin: 0 auto;
}
The above is for a simple ~10% left and right white border on the page.
Although slightly OT, there is no HTML5 element for this. I have seen <main> used in its place, however, quoting from the MDN article for <main>:
The main content area consists of content that is directly related to,
or expands upon the central topic of a document or the central
functionality of an application. This content should be unique to the
document, excluding any content that is repeated across a set of
documents such as sidebars, navigation links, copyright information,
site logos
Related
I'm using some very simple html that I would expect to produce a sidebar, but the text in the sidebar simply appears as a next paragraph on the same page. True in both Chrome and Safari.
<!DOCTYPE html>
<html>
<body>
<section>
<p>
This is the main content. I'm not content to have main content without a sidebar.
</p>
<aside>
<p>
As an aside, I want this to be at the side.
</p>
</aside>
</section>
</body>
</html>
Do I need to add styling elements? Based on the documents I wouldn't have thought so. I have also tried this with a much longer 'section' text, to no avail. I've also tried the <sidebar> tag.
From the HTML 5 specification:
The aside element represents a section of a page that consists of content that is tangentially related to the content around the aside element, and which could be considered separate from that content. Such sections are often represented as sidebars in printed typography.
It is not something that effect visually like other HTML tags.
Consider to use Flexbox
#section {
display: flex;
flex-direction: row;
}
<!DOCTYPE html>
<html>
<body>
<section id="section">
<p>
This is the main content. I'm not content to have main content without a sidebar.
</p>
<aside id="aside">
<p>
As an aside, I want this to be at the side.
</p>
</aside>
</section>
</body>
</html>
You can also try to use float.
These html5 tags,
<section>, <main>, <nav>
and so on, have no impact on the browser, it's like writing
<div>
.
The sole purpose of their existence is to make your source code more readable.
By the way, I do not think that actually exists.
You will need to use CSS for this. The semantic HTML tags - section, article, aside, etc... do not have a lot of impact on the rendering of the page. Some of them usually just add a default display: block style, but that's about it.
When do I put headings inside a header element? I can't understand it, sometimes it seems to me that each heading has to be between header tags.
Let's take this sidebar as example :
How to code it?
<aside>
<header>
<h1>How to format</h1>
</header>
</aside>
or
<aside>
<h1>How to format</h1>
</aside>
See the specification of the header element:
A header element is intended to usually contain the section's heading
(an h1–h6 element), but this is not required. The header element can
also be used to wrap a section's table of contents, a search form, or
any relevant logos.
So you can have many header elements in a page (it's not limited to the top of the page), and you can use it around headings, but it's optional. This means both of your examples are correct.
The header tag is for what displays at the top of the page of the page-what is sometimes called the banner. So put your h1-h6 tags in it when they are in the banner of your page.
Tags like header and footer are basically just div's renamed for organizational sanity. In the future search engines and browsers may look for header and footer tags to help them process and display information better. For now, it lets you avoid staring at a bunch of div tags.
<html>
<head>
</head>
<body>
<header> Web page Banner</header>
<div>Content</div>
<footer>Web page bottom </footer>
<body>
</html>
Instead of this...
<html>
<head>
</head>
<body>
<div> Web page Banner</div>
<div>Content</div>
<div>Web page bottom </div>
<body>
</html>
<header> give us some great added semantic value in order to describe the head of a section.
You can use multiple headers in a web page, each of which will then become the <header> for that section of the document. So, using a <header> depends on the complexity of the section. The more complex it is, the more necessary the header element becomes.
a <header> typically contains at least (but not restricted to) one heading tag (<h1> – <h6>).
hope it helps
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>
I don't like how the fragment identifier jumps to the actual point of where the content begins on the page. It looks awkward having the box start right at the top of the screen. It kind of bugs me. So I was using an anchor with a name attribute above it, set to display: block so that it would pay attention to the 10px margin on the top of the box below it. Using this method, it essentially jumped down to that content, with 10px spacing between the start of the content and the actual top edge of the browser window.
<a name="some-text"></a>
But it seems that I'm no longer allowed to do this in HTML5, as when I try to validate the page, I get this nice warning:
The name attribute is obsolete. Consider putting an id attribute on the nearest container instead.
I can't just change all the name attributes to id attributes because it becomes an empty hyperlink rather than a named anchor (I've also tried, the display: block no longer gets applied to it).
So, given a group of divisions, like so:
<div>Content</div>
<div>Content</div>
<div>Content</div>
<div>Content</div>
and assuming that they all have a 10px margin applied to the top of them, is there any way to re-apply the IDs to them so that when I use fragment identifiers to jump to different spots, it still includes the 10px space between the content and the top edge of the browser window?
Note: I've tried applying the ID directly to each division, but the browser ignores the margin on the element when determining where to jump.
I didn't get you right at first, let me try again. You say:
I can't just change all the name attributes to id attributes because it becomes an empty hyperlink rather than a named anchor (I've also tried, the display: block no longer gets applied to it).
I don't really understand where is the problem here or why would you like it to use display: block. Its purpose as I and apparently the W3C see it is a placeholder, it should act as an anchor like it did in HTML4, only using id instead of the name attribute.
If you'll run this simple html through the W3C's markup validator you'll see it is valid html5.
<!DOCTYPE HTML>
<html lang="en-US">
<head>
<meta charset="UTF-8">
<title></title>
</head>
<body>
<a id="test"></a>
</body>
</html>
So it comes down to these two options:
a. I didn't get something right, I'm sorry and hope you'll be able to correct my mistake.
b. You are going out of your way to accomplish things that could be easily achieved.
Use padding could avoid this problem. As margin is not included in the content boundaries, so the browser would ignore it.
<!doctype html>
<html>
<head>
<style type="text/css">
body {
margin: 0;
padding: 0;
}
div {
padding-top: 10px;
}
</style>
</head>
<body>
<div id="1">How can I jump to a point slightly above the fragment identifier?<br/>
up vote 2 down vote favorite</div>
<div id="2">
I don't like how the fragment identifier jumps to the actual point of where the content begins on the page. It looks awkward having the box start right at the top of the screen. It kind of bugs me. So I was using an anchor with a name attribute above it, set to display: block so that it would pay attention to the 10px margin on the top of the box below it. Using this method, it essentially jumped down to that content, with 10px spacing between the start of the content and the actual top edge of the browser window.</div>
<div id="3">
But it seems that I'm no longer allowed to do this in HTML5, as when I try to validate the page, I get this nice warning:</div>
<div id="4">
The name attribute is obsolete. Consider putting an id attribute on the nearest container instead.</div>
<div id="5">
I can't just change all the name attributes to id attributes because it becomes an empty hyperlink rather than a named anchor (I've also tried, the display: block no longer gets applied to it).</div>
<div id="6">
So, given a group of divisions, like so:</div>
<div id="7">Content</div>
<div id="8">Content</div>
<div id="9">Content</div>
<div id="10">Content</div>
<div id="11">
and assuming that they all have a 10px margin applied to the top of them, is there any way to re-apply the IDs to them so that when I use fragment identifiers to jump to different spots, it still includes the 10px space between the content and the top edge of the browser window?</div>
<div id="12">
Note: I've tried applying the ID directly to each division, but the browser ignores the margin on the element when determining where to jump.</div>
<div id="13">
html fragment-identifier</div>
</body>
</html>
.spacer{height:25px;}
Place an element with a class that has the height you want immediately after the anchor.
Fiddle example. http://jsfiddle.net/calder12/sJEkQ/3/
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>