Автор MasterНа чтение 39 минПросмотров134Опубликовано
What are sectioning roots? Let’s take a look at this HTML5 feature and whether or not sectioning roots are important to your webpages.
Sectioning roots were introduced in HTML5 (formerly referred to by the W3C as HTML 5, but now branded without a space). Knowing all about them are not going to be important to your daily work as a designer or developer.
Here is a run-down of the very specific, yet short definition.
Section roots break out sections of a document into their own separate outlines. They are ‘root’ objects that have no ancestors.
These elements can have their own outlines, but the sections and headings inside these elements do not contribute to the outlines of their ancestors.
Does it Matter to Me?
Right now, not really. I am always a proponent of quality, semantic coding. Therefore, I build sites with the best markup I can and pay attention to these structures even when it doesn’t change the result.
Sectioning roots are purely for outlining purposes. With the body tag being the main element, there is actually very little to worry yourself with and it certainly won’t affect the look of your page.
Assistive technology certainly doesn’t concern itself with these semantics yet and search engines don’t seem to react either. These things are destined to be picked up eventually, so start coding properly now and be ahead of the curve.
2 Answers
December 4, 2017 1:08am
It’s in MDN here. I just dived deeped and sunk.
Citation from MDN:
It doesn’t seem like the phrase «sectioning root» ever appears in the video. If I’m missing something, could you provide the time index were this occurs?
The video does talk about the «project root», that’s referring to the top-level folder on the disk where all files and other folders are stored. This is not related to the organization of tags in the HTML file.
HTML: Sectioning, Headings, Accessibility & (A Bit Of) SEO
The Document Outline
TL;DR: Outlines are generated using heading levels and (in HTML5) sectioning elements. We want a good document outline for SEO and accessibility.
What Is A «Sectioning Element»?
Alright this is the fun part. There’s two types of sectioning elements: Sectioning Root and Sectioning Content.
Sectioning Root
Sectioning root is a container that provides a scope for the discrete content sections that will be defined within it. Each sectioning root gets its own individual outline.The top level sectioning root of any page is formed by its <body> tags, so there is always an outline generated for any webpage, starting from the <body> tags and working through the sections it is broken into.
Sectioning root tags include:
So the issue is that anytime you use one of these elements you generate a new document outline. That doesn’t mean that you shouldn’t use them, it means they should be used purposefully as a powerful tool.
Sectioning Elements (The «Discrete Content Sections of a Root»)
Each sectioning root is broken into a series of content sections. These sections are created by placing sectioning content element tags around discrete pieces of content. Sectioning content elements are nestable and semantic. The type that should be used depends on the nature of the content it will contain.
Sectioning content tags include:
Heading Content
Text-only labels for sections of content. In the absence of sectioning content tags, the presence of a heading tag will still be interpreted as the beginning of a new content section.
What Does The Spec Say?
«These elements represent headings for their sections.
The semantics and meaning of these elements are defined in the section on Headings and sections.
These elements have a rank given by the number in their name. The h1 element is said to have the highest rank, the h6 element has the lowest rank, and two elements with the same name have equal rank.
h1–h6 elements must not be used to markup subheadings, subtitles, alternative titles and taglines unless intended to be the heading for a new section or subsection. Instead use the markup patterns in the Common idioms without dedicated elements section of the specification.»
Key Takeaways of the Heading Element
Heading elements label their section.
Heading elements should NOT be used to markup subheadings, subtitles alternative titles and taglines UNLESS it’s a title for a new section.
Be intentional with your use of the h1-h6 elements.
Styling does not dictate heading level.
Make your best judgements when assigning heading level, but work with your content creators to determine proper heading levels.
Tying It All Together
We like to make modular components, but we need to keep in mind how the overall page flows. Work with your team and designers to determine how content will be sectioned and be intentional with how you use HTML5 sectioning elements. Just because we have super cool elements doesn’t mean we should use them all the time.
When in doubt a <div> has no semantic meaning
Testing
Want to test your document outline? Go here: HTML 5 Outliner. There’s also a Chrome Extension.
SEO
New crawlers and SEO algorithms take into account HTML5 sectioning elements and leverage their functionality when taking SEO into account. The rule of «only one H1 per page» is dying. Work with your teams to educate them on this topic and fight for accessibility. Need some reading material? Here ya go.
Resources
This repository has been archived by the owner on Jul 30, 2019. It is now read-only.
alrdytaken opened this issue
Mar 24, 2017
· 8 comments
Comments
Heading content defines the header of a section (whether explicitly marked up using sectioning content elements, or implied by the heading content itself).
This part of the specification implies that sectioning content is needed to define a section explicit.
4.3.1. The body element, Categories: Sectioning root.
This part defines <body> as non-sectioning content but sectioning root.
Foo (heading of explicit body section, containing the «Grunt» paragraph)
Now in this example 27 according to the specifications <body> is an explicit section
Authors are also encouraged to explicitly wrap sections in elements of sectioning content, instead of relying on the implicit sections generated by having multiple headings in one element of sectioning content. <body> <h1>Apples</h1>
And if this example fulfills its advice to wrap headings in sectioning content <body> must be sectioning content.
The other possibility would be that all sectioning roots shall have there own headings just like sectioning content do, but this also isn’t documented anywhere. And also in the examples none of the sectioning roots, except of <body> are marked up using headings.
alrdytaken
changed the title <body>: Clarify or fix the use of terms «explicit», «implicit» and «sectioning content»
<body>: Add sectioning content to its categories
Mar 24, 2017
From the 5.1 spec: «»Heading content defines the header of a section (whether explicitly marked up using sectioning content elements, or implied by the heading content itself).»»
(1) — To be more clear, it should probably state: «(whether the section is explicitly marked up using sectioning content elements, sectioning root elements, or implied by the heading content itself).»
The reason for the second bold part lies within the definition of sectioning root elements:
Continuing an existing section, when a sectioning root element is entered, would mean that a sectioning root element would contribute to the outline of an ancestor. As a consequence, a new section must be created each time such an element is entered (begins). And, in order to make any sense, this new section must also end when the sectioning root element is exited (ends).
So because a sectioning root element defines the beginning of a section, and a point beyond which that section cannot reach, you can state that, in addition to sectioning content elements, sectioning root elements also define/create explicit sections — the spec is just not too clear about that.
From the 5.1 spec: «»Authors are also encouraged to explicitly wrap sections in elements of sectioning content, instead of relying on the implicit sections generated by having multiple headings in one element of sectioning content.»»
<div data-snippet-clipboard-copy-content="
A
B
«>
<section>
<h1>A</h1>
<h2>B</h2>
</section>
The actual intention behind this statement seems to be: Explicitly mark the beginning and the end of your sections. Do not trust that an outline reader will split your document into sections the way you imagine that it will be done. Some outline reader might do it differently, because where an implied section ends is not always that obvious.
So this paragraph, by itself, does not state that <body> is (also) a sectioning content element.
From the 5.1 spec: «»Each sectioning content element potentially has a heading and an outline.»»
(2) — When I read both definitions, I simply ignore the «can have» (root elements) and «potentially has» (content elements) parts, because the algorithm will always start a new outline/section when entering a sectioning root element, or a sectioning content element. It should be stated as a fact, not as a possibility.
(3) — What I am missing here is the clarification that sections and headings of sectioning content elements do contribute to the outlines of their ancestors.
The definition of sectioning content and the definition of sectioning root elements both state that these elements have an outline. This is consistent with the definition of an outline:
Both groups of elements have at least one common characteristic: Any element of sectioning content, and any sectioning root element, has an outline. This common characteristic is what made you, alrdytaken, believe that the <body> element could be «a hybrid of sectioning content and sectioning root».
Unfortunately, this point of view ignores the other characteristic of those elements, which clearly distinguishes them from one another: The outline of a sectioning content element contributes to that of an ancestor, the outline of a sectioning root element does not. As a consequence, the <body> element can not be both at the same time.
The way I see it, a sectioning root element (in general) marks content that is (more or less) self-contained and somewhat loosely connected to the content that surrounds it. A sectioning content element on the other hand extends its surrounding content.
With that in mind, the <body> element has more in common with a sectioning root element: Because it is the topmost element, there is no content surrounding it, that a <body> element could extend. As a result, the <body> element can not be a sectioning content element (instead of a sectioning root element).
I still believe that properly defining the common characteristics of both element types, and maybe even including the heading content type (crazy talk, I know), could be the key to move forward. The question is, how far would you be willing to take it, because a proper definition will, without a doubt, require changes that could no longer be seen as non-substantive.
Okay, so I took a new approach to this.
Makes sense to me
Now I assume that this is true:
A section is invoked by the appearance of either a sectioning content or a sectioning root.
A section potentially has a heading associated with it.
A section defines the scope of an optional <heading> and <footer>.
This makes perfect sense and corresponds with all example codes.
Needs rework in my opinion, proposal A
Though, I propose to update some explaining text, which I feel is misleading:
The first element of heading content in an element of sectioning content or sectioning root represents the heading for that section. https://www.w3.org/TR/html51/sections.html#sectioning-roots
Authors are also encouraged to explicitly wrap sections in elements of sectioning content or sectioning root, instead of relying on the implicit sections generated by having multiple headings in one element of sectioning content or sectioning root. https://www.w3.org/TR/html51/sections.html#sectioning-roots
Heading content defines the header of a section (whether explicitly marked up using sectioning content or sectioning root elements, or implied by the heading content itself). https://www.w3.org/TR/html51/dom.html#sectioning-content
Also, I suggest to add sectioning root to kinds of content. Personally I’d rename 3.2.4.2.3. Sectioning content to 3.2.4.2.3. Sections and add 3.2.4.2.3.1 Sectioning content and 3.2.4.2.3.2 Sectioning root, knowing that it breaks the consistency of all kinds of content being named boo content at the moment.
Needs rework in my opinion, proposal B
Another option of course would be to add sectioning content to Categories: of each sectioning root and reducing the definition of sectioning root to no more more as
Creates a new outline whose sections don’t particpate in its ancestors outlines.
We only need to adjust one explaining text now:
Sectioning content elements which are not sectioning root elements are always considered subsections of their nearest ancestor sectioning root or their nearest ancestor element of sectioning content, whichever is nearest, regardless of what implied sections other headings may have created.
(Assigned two people. Whoever decides to take it should unassign the other)
edent
removed their assignment
Feb 20, 2018
We’re closing this issue on the W3C HTML specification because the W3C and WHATWG are now working together on HTML, and all issues are being discussed on the WHATWG repository.
If you filed this issue and you still think it is relevant, please open a new issue on the WHATWG repository and reference this issue (if there is useful information here). Before you open a new issue, please check for existing issues on the WHATWG repository to avoid duplication.
Whether you’re a webmaster or a web designer, there’s a question you’ve most likely either asked or answered many times over the years. That question is, «How many <h1> tags can I use per page, and how exactly should I implement them?»
There are generally two reasons this question is asked. The first and most common is for SEO purposes; ensuring content is formatted in the best way possible to aid search engine indexing. The second is technical correctness; ensuring that markup is written in accordance with the appropriate W3C spec.
With the advent of HTML5 the answer to this question has significantly changed in both SEO and technical regards. It’s now not only possible to have multiple <h1> level headings per webpage that will make sense to search engines, but in most cases it’s actually the recommended course.
However, because the HTML5 spec is not all that widely understood yet, there is still a lot of advice floating around, some even written very recently, based on the rules of pre-HTML5 web design.
In this tutorial we’re going to clear up some misconceptions. We’ll take an in-depth look at what HTML5 means for <h1> tag usage, as well as how you can take advantage of the enhancements now available to create web pages that are more semantically rich and well-structured than ever before.
The Pre HTML5 «Single
Tag» Rule
For a long time it was considered one of the cardinal rules of HTML and SEO that each individual page of a site should have one <h1> level heading, and one only. Additionally, the rule prescribed that this singular <h1> heading should denote the primary subject matter of the page.
A pre-HTML5 version of this website would therefore be marked up something like this:
Why Headings Matter
Despite the long-time heavy focus on <h1> tags, they were never an element that operated in isolation, independent of the rest of the document. There is a reason behind the importance of careful heading tag placement in both the HTML5 and pre-HTML5 eras, and that is the generation of document outlines.
Document outlines are something akin to a table of contents for a website. They are automatically generated from the markup on any given webpage.
Prior to HTML5, document outlines were generated from your use of heading tags <h1> through to <h6>. Every use of a heading would imply the beginning of a new section of content.
1. (document) The proper use of peanuts
1. (h2) How to eat peanuts
1. (h3) Superior peanut eating methods
2. (h2) Incorrect application of peanuts
The first <h1> element is considered the label for the entire document. The subsequent headings are considered the labels for sections of content within that document, forming a tree beneath it.
The above example is simple enough, but in the wild webpages are rarely this simple. When we need more complex content presentation we run into the big problem with pre-HTML5 markup, and the reason it was previously necessary to use only one <h1> level heading per page.
In the example above we have a single topic being discussed: «The proper use of peanuts». But what if this topic is being discussed on a page with multiple articles of equal importance, as you might see on a blog for example?
Take this html with a second article displayed, (each article is wrapped in <div> tags):
1. (document) The proper use of peanuts
1. (h2) How to eat peanuts
1. (h3) Superior peanut eating methods
2. (h2) Incorrect application of peanuts
2. (h1) Boiling beans
1. (h2) Is boiling beans really worth it?
Now, even though there are two articles of equal importance on the page, the first article’s heading «The proper use of peanuts» is still interpreted as the label representing the entire document simply because it is the first one encountered. This would thus indicate that the entire subject matter of the page is «The proper use of peanuts» even though the second article is about a totally different topic.
The typical way to combat this was to create a catch-all heading with <h1> tags wherever multiple sections of content of equal importance were displayed, in an attempt to represent them all to the greatest extent possible. For example:
Note the addition of the generalized <h1> tagged heading, and the demotion of each subsequent heading down one level.
1. (document) Legume Literature Blog
1. (h2) The proper use of peanuts
1. (h3) How to eat peanuts
1. (h4) Superior peanut eating methods
2. (h3) Incorrect application of peanuts
2. (h2) Boiling beans
1. (h3) Is boiling beans really worth it?
Problems Caused by Pre-HTML5 Document Outlines
This document outline, though it’s the best that could be done pre-HTML5, presents some significant problems:
The generalized label for the whole page dilutes relevance. We have the <h1> tagged «Legume Literature Blog» title acting as the label for the whole page, and yet the text of this heading gives only a generalized representation of the content. This dilutes the ability of search engines to interpret the actual subject matter on the page and in turn its relevance to search phrases.
Separate articles are seen as subsections of a single piece of content. There is no way to distinguish the two articles on the same page as equally important and self-contained entities. They are both seen as a part of a single overall piece of content, even though they are not.
Different markup is required in different site areas. Should a visitor view one of the articles by itself, as can be done on a typical blog, the markup would have to be reworked so the <h1> tags are applied to the article title instead of the site title, as I demonstrated with my example business website in the previous section.
There are restrictions on the nature of the document label/site title. In many cases a site title, (which tends to play the role of document label even in HTML5), may not relate to a page’s content in any meaningful way. For example, I might run a blog with the site title «Kezz Says» and it might display one article on HTML coding and another on cute puppies. In this case it would not make sense for the site title to be interpreted as representing either of these articles, so I would have to change the name of my blog. This can be a problem, particularly if a site wishes to brand itself with a name that may be memorable, but not necessarily meaningful.
This is where HTML5 comes along to save the day and solve each of these problems.
The HTML5 Document Outline Algorithm
If you consider each of the problems just described above, they all have a common and somewhat simple root: The assumption that each web page is a singular document with a singular topic requiring only a singular label.
The equally simple solution to these problems would come from the ability to indicate if a webpage had discrete sections, potentially with multiple topics each with their own meaningful label.
If it were possible to specify that each article on a page was separate, this would make it possible to label them with meaningful headings that accurately represented their contents, and give each one the same weight of importance.
If it were possible to make it clear when a site title was not representative of the page’s content, the problem of diluting relevance would be solved.
With a clear indication in place of the difference between the site title, articles and article titles, it would no longer be necessary to change markup from one area to another. A <h1> tagged site title could keep its <h1> tags throughout the site.
And because it would be made clear if the site title didn’t represent the article content on the page, it would be possible to set it to anything at all, no matter how abstract.
HTML5 makes all these things possible through the introduction of its semantic elements and the HTML5 document outline algorithm.
Key Aspects of the HTML5 Document Outlining Algorithm
Sectioning root: A sectioning root is a container that provides a scope for the discrete content sections that will be defined within it. Each sectioning root gets its own individual outline.The top level sectioning root of any page is formed by its <body> tags, so there is always an outline generated for any webpage, starting from the <body> tags and working through the sections it is broken into.
Sectioning content: Each sectioning root is broken into a series of content sections. These sections are created by placing sectioning content element tags around discrete pieces of content. Sectioning content elements are nestable and semantic. The type that should be used depends on the nature of the content it will contain. (We’ll discuss how to use each sectioning content element further on.)
Heading content: Text-only labels for sections of content. In the absence of sectioning content tags, the presence of a heading tag will still be interpreted as the beginning of a new content section..
Heading tags: <h1>, <h2>, <h3>, <h4>, <h5>, <h6>
Understanding how these aspects of HTML5 are used is relatively straightforward, and the process typically goes much like this:
The sectioning root of the document is formed by its <body> tags.
Within that sectioning root, the document is broken into sectioning content, e.g. by wrapping articles with the <article> tags.
Heading tags are placed into the content sections as required, with the first heading tag in any section acting as the label for that section.
There are many other aspects to the HTML5 document outline algorithm. Extensive information on these is available on W3C.
However, with just the aspects listed above, we are able to solve all the problems described in the previous section of this tutorial.
Solving the Old Document Outline Problems
<!DOCTYPE html> added to invoke HTML5
<article> tags have been added wrapping each article, replacing the generic <div> tags
Article headings have been changed from <h2> up to <h1> tags
The other heading tags in each article have been adjusted up one level in kind
A branded/non-meaningful site title is used
1. (document) Whackamoon Legumes!
1. (article) The proper use of peanuts
1. (h2) How to eat peanuts
1. (h3) Superior peanut eating methods
2. (h2) Incorrect application of peanuts
2. (article) Boiling beans
1. (h2) Is boiling beans really worth it?
The first thing you may notice is the appearance of the (article) element in the outline, and next to those the headings for each of our articles.
The appearance of the (article) element next to our article headings, rather than the heading tags as we saw before, tells us these things are now occurring in the outline:
Each article has been recognized as a self-contained piece of content with equal weight of importance to one another.
The article headlines are now being correctly matched to the articles as meaningful labels that represent their subject matter.
Because the articles are correctly labeled with their own headings, the site title is no longer being interpreted as representative of the content in those articles.
This means that all the problems we outlined earlier in this tutorial have immediately been solved:
Solved: The generalized label for the whole page dilutes relevance. We no longer have any dilution of relevance from generalized labels, as the label of each article is clearly associated with it.
Solved: Separate articles are seen as subsections of a single piece of content. The page is no longer seen as one singular piece of content, because the presence of the article tags indicates where the page is broken into independent sections.
Solved: Different markup is required in different site areas. Because all the <h1> tags used in the markup are now correctly interpreted, and we no longer have to worry about labels diluting relevance, we no longer need to apply different tags to the site title—it can remain tagged at <h1> level throughout.
Solved: There are restrictions on the nature of the document label/site title. Because the site title is no longer interpreted as a label for the article content we’re free to set it to anything we like. It no longer has to act as a «catch-all» representative for all the content on the page, so it can be an abstract or branded title that doesn’t relate to the article content at all.
Why Multiple
Tags Are Correct
You can also now see from the HTML5 document outline generated by our markup that it is perfectly fine to use as many <h1> tags as your document calls for; that is one per sectioning root or content section.
You can also see from this example how it would be less correct to use only one set of <h1> tags in this example, and that multiple sets of <h1> tags more accurately represent the content.
If you still had <h1> tags applied only to the site title, and <h2> tags applied to your article titles, the outline of your articles would be thrown out.
This is because by marking up your article headlines with <h2> tags you are effectively saying they are level two headings, even though they are actually level one headings within the scope of the <article> section.
In turn, the second level subheadings of your articles would necessarily be marked up with <h3> tags incorrectly setting them to level three, your third level headings marked up with <h4> tags and so on.
It is permissible by the HTML5 spec to use lower level headings than <h1> to label a section, and sometimes you may want to for presentation reasons, such as displaying a smaller sized heading in a sidebar blogroll section. However, I would recommend doing this only in the case of minor, non-article/content sections of your site where it’s not a priority for heading levels to produce a document outline that effectively forms a table of contents.
The best thing to do in all cases is carefully consider the content at hand, and determine the best way to section and label it based on what you now know about the HTML5 document outlining algorithm.
HTML5’s New
Usage Rules
Yes, it’s true. You can now use as many sets of <h1> tags as are required, via HTML5. But that doesn’t mean they should be freely added in arbitrary locations.
Just as there were rules of <h1> tag usage that came from old document outlines, so too are there now new rules based on the HTML5 document outlining algorithm.
Here they are at a glance:
Use one set of <h1> tags per sectioning root or content section.
There should always be a <h1> level heading between the opening <body> tag and the first content section, to label the overall document.
When a <h1> level heading is to be used to label a content section, it should be the first heading that appears in the section, because the first heading is always interpreted as the section’s label.
If a <h1> level heading is used to label a content section, any other headings used in that section should be H2 or lower in order to create an accurate document outline.
As I mentioned above, section labels don’t absolutely have to be <h1> tags. The HTML5 spec permits any heading tag to act as the label for a section, from <h1> through to <h6>. Again however, I always recommend using <h1> level tags to markup article content.
About Sectioning Content Element Tags
There are only four sets of element tags you can use to denote content sections within your webpage, but they can be a little tricky to wrap your mind around at first.
<article>
<section>
<nav>
<aside>
The two you are likely to use the most are <article> and <section> tags. They are similar to one another, but with an important distinction.
<article> tags should be used where a piece of content could be taken out of a page completely and still make sense by itself with no surrounding content.
<section> tags, on the other hand, should be used for content that is grouped together according to a theme, but makes sense only in the context of the content surrounding it.
For detailed examples on how to use each of these tags, take a moment to check out these W3C pages:
<aside> tags could effectively be described as the «everything else» element for content that is neither article, section nor navigation. W3C prescribes this tag for use when something is tangentially related to the content around it, but is separate from the main content of the page, such as sidebars, blogrolls and so on.
Dealing With Taglines
We now know that in HTML5 we can happily use <h1> tags on our site titles in every area of our sites. However, despite it being a common practice, technically speaking <h2> tags shouldn’t be used for standalone subheadings or taglines.
W3C has this to say:
h1–h6 elements must not be used to markup subheadings, subtitles, alternative titles and taglines unless intended to be the heading for a new section or subsection.
The reason for this is that the HTML5 document outline always interprets a heading tag as beginning a new section of content, whether sectioning content tags are wrapped around them or not.
For a while there was a work-around to this whereby <h2> tags could be used for a tagline if they were grouped with the main heading inside a set of <hgroup> tags. However, the <hgroup> is being removed from the HTML5 spec and its use will cause code to fail validation checks.
So now the best way to handle taglines is just to use <div> or <p> tags and apply CSS to make them look like taglines, achieving your presentation goal without negatively affecting your document outline.
Further HTML5 Elements to Employ
In this tutorial we’ve been focusing on <h1> tags in HTML5 and how the new document outlining algorithm works. For that reason I haven’t touched on any HTML5 elements that are not assessed by the document outlining algorithm.
However, I would be remiss if I did not point you in the right direction on a few of the most valuable HTML5 tags you can employ in your markup to make it even more semantically rich.
The <main> Element
The <main> element should be used once per page to indicate the main content area of that page.
If you are displaying a group of articles, it would wrap around all those articles. For example:
More information: The Main Element
The <header> Element
The <header> element can be used at the beginning of any sectioning root, or content section, to group introductory content for that section.
You could use it to wrap your site title and tagline, or an article title and blog category. For example:
More information: The Header Element
The <footer> Element
The <footer> element is basically the inverse of the <header> element, in that it can be used at the end of any sectioning root, or content section, to group supplementary content for that section.
More information: The Footer Element
Wrapping Up
In conclusion, let’s take a look at our original business website example and see how it could now be marked up using what we have learned:
This simple example shows just how easy it is to use an understanding of the HTML5 document algorithm to solve the old problems surrounding use of <h1> tags, and to ensure the content of your webpages is more accurately communicated than ever before.
Recommended reading
Recommended tools
Did you find this post useful?
If you care about semantic HTML and the document outline, it makes sense to use h1 for the logo (assuming that the logo represents the site name).
Why? See the next three steps.
1. Without headings
A simple, common HTML5 document without headings could look like:
In the document outline, each section gets an entry (which is, semantically, equivalent to a heading). So the outline, without using any heading elements, is:
Now let’s give the article a heading element. It doesn’t matter which one, but HTML5 recommends to use a heading element that corresponds to the nesting level, i.e., h2 in this case: <h2>My first blog post</h2>.
And for the sake of this example, let’s give the nav a heading, too (h2 for the same reasons), although it typically doesn’t need one if it’s the only navigation: <h2>Navigation</h2>
The document outline doesn’t change, it just gets labels:
1. untitled <body>
1.1 "My first blog post"
1.2 "Navigation"
3. … and for body
But what is with the untitled body entry? It longs for a heading! What heading could it possibly get? The site name! Why? Because the page doesn’t contain page-specific content (like the main content) only, but also site-wide content (like the header, the footer, and the navigation). And a site heading allows us to represent this in the outline.
So the heading for the body sectioning root would typically be the site name (<h1>Alice’s blog</h1>), which can of course also be a logo (<h1><img src="logo.png" alt="Alice’s blog" /></h1>).
1. "Alice’s blog"
1.1 "My first blog post"
1.2 "Navigation"
My answers to related questions:
The outline of your example
The outline which https://gsnedders.html5.org/outliner/ generated is not correct.
The correct outline of your example markup is:
1. Document (<body> without heading)
1.1. Navigation (<nav> without heading)
2. "Homepage" (implicit section opened by <h1>)
2.1. Navigation (<nav> without heading)
I recommend the «HTML5 Outliner» for checking your outline, or the W3C validator (check «outline»).
(See https://github.com/hoyois/html5outliner/issues/7 for details why the outline you quoted is not correct.)
Site-related vs. page-related content
Your observation is correct: mixing page-related sections and site-related sections can be problematic. But exactly because of this, the advice that the main content should get a h1 is not a good advice if you care about the outline.
A page from a typical website has site-wide parts like the header, the navigation, and the footer. To get them in scope of a heading, you should use the heading for the body sectioning root, which then represents the site.
<body>
<header>
<h1>Example Site</h1> <!-- could be your logo’s 'alt' -->
</header>
<main>
</main>
<footer>
</footer>
</body>
Now the Document has a heading («Example Site»), and unless you add another h1 to the body sectioning root, this will be the only top-level entry in the outline — everything else will be in its scope.
Now we can add a nav (for the site-wide navigation):
<header>
<h1>Example Site</h1> <!-- could be your logo’s 'alt' -->
<nav></nav>
</header>
(It’s important that the nav, or any other section, comes after the body-heading.)
And an article (if the main content of that page is e.g. a blog posting):
<main>
<article></article>
</main>
The article heading could be a h1, but HTML5 recommends to use heading elements of the corresponding rank (depending on your use of sectioning elements), i.e., h2 in this case.
If you are not convinced that the site name should be the document heading (i.e., the h1 for the body), note that HTML5 encourages authors to use sectioning content elements (article, aside, nav, section) explicitly.
If you have a site-wide navigation in nav, this would be in scope of this top-level entry (if it comes after the blog posting), or in scope of an untitled document heading (if it comes before the blog posting). The first variant is wrong (the site-wide navigation has nothing to do with the blog posting), the second one is not ideal, because you have multiple top-level entries, and the first one has no label.
If you would stop using nav, your navigation would still be in scope of a heading. It would either be part of the unlabeled document entry, or part of the main content. Both is, of course, not ideal.
So, my advice based on the HTML5 W3C Recommendation:
Use a h1 (for the body sectioning root) with your site name/logo.
Use nav for your navigation (site-wide as well as page-wide), use article/section for your content.
Give each article/sectionone heading element (starting with h2).