Do not recommend using nested sections with h1

[chaals]

Currently there are two recommended approaches to headings: using the h1 - h6 in a structured nesting order, or using nested <section><h1> blocks relying on the outline algorithm.

Doing this looks right in modern browsers, which apply some simple CSS to make nested h1 elements look similar to h2 - h6 according to the level of nesting. But the CSS used is pretty fragile, and the browsers report the level of heading e.g. through accessibility APIs as h1 whatever their nesting level.

I propose that we make a counter-recommendation not to use nested <section><h1> while browsers do not implement it reliably.

[chaals]

This should fix the most troubling part of #33

[chaals]

This should fix the most troubling part of #33

[unor]

4.3.10. Headings and sections encourages authors to use sectioning content elements explicitly together with heading elements of the appropriate rank (i.e., not h1 everywhere):

Sections may contain headings of any rank, and authors are strongly encouraged to use headings of the appropriate rank for the section’s nesting level.

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.

[unor]

4.3.10. Headings and sections encourages authors to use sectioning content elements explicitly together with heading elements of the appropriate rank (i.e., not h1 everywhere):

Sections may contain headings of any rank, and authors are strongly encouraged to use headings of the appropriate rank for the section’s nesting level.

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.

[chaals]

Yes, but it then provides an outline algorithm and various examples that suggest using

<section>
 <h1>a heading</h1>
 <section>
  <h1>a heading for a subsection</h1>

Which seemed like a good idea, and has certain features that make it attractive.
One of the features that make it unattractive is that it doesn't work. Different people viewing the same content will get very different structures provided to them.

So my proposal is to remove everything that says using sectioning is enough to make the outline algorithm understand the nesting as a way to treat headers relative to each other, since in practice, it isn't.

If you use <section><h1>…</h1>…<section><h1>, user agents will provide different information to different users. It seems that the attempt to change that has failed, and unless browsers are actively interested in fixing that - and it's probably not hard for them to do - we might as well deal with the problem. IMHO…

[chaals]

Yes, but it then provides an outline algorithm and various examples that suggest using

<section>
 <h1>a heading</h1>
 <section>
  <h1>a heading for a subsection</h1>

Which seemed like a good idea, and has certain features that make it attractive.
One of the features that make it unattractive is that it doesn't work. Different people viewing the same content will get very different structures provided to them.

So my proposal is to remove everything that says using sectioning is enough to make the outline algorithm understand the nesting as a way to treat headers relative to each other, since in practice, it isn't.

If you use <section><h1>…</h1>…<section><h1>, user agents will provide different information to different users. It seems that the attempt to change that has failed, and unless browsers are actively interested in fixing that - and it's probably not hard for them to do - we might as well deal with the problem. IMHO…

[Marat-Tanalin]

The issue could probably be solved by finally introducing a levelless heading element — e. g. just h.

<section>
    <h>Some heading</h>
    ...
    <section>
        <h>Heading for the nested section</h>
        ...
    </section>
</section>

This would be free from any backward incompatibilities and would also free us from the current restriction of nesting depth of just six levels (that could be useful e. g. for HTML-based books that may contain far more levels than a regular HTML page).

[Marat-Tanalin]

The issue could probably be solved by finally introducing a levelless heading element — e. g. just h.

<section>
    <h>Some heading</h>
    ...
    <section>
        <h>Heading for the nested section</h>
        ...
    </section>
</section>

This would be free from any backward incompatibilities and would also free us from the current restriction of nesting depth of just six levels (that could be useful e. g. for HTML-based books that may contain far more levels than a regular HTML page).

[chaals]

@Marat-Tanalin agreed - that would be the way to handle this. It requires browsers to implement a new element, and the outline algorithm. Until they are prepared to do something like this we're stuck with the existing h1 - h6 …

[chaals]

@Marat-Tanalin agreed - that would be the way to handle this. It requires browsers to implement a new element, and the outline algorithm. Until they are prepared to do something like this we're stuck with the existing h1 - h6 …

[Marat-Tanalin]

@chaals I suspect support for the new element wouldn’t require too much. display: block and font-weight: bold would probably be enough.

As for outline, isn’t it somewhat fictious and having no [browser] implementations at all?

Update: To be clear, I clearly see how the outline algorithm could be useful for e. g. assistive technologies. The algorithm is, AFAIK, just not yet implemented in browsers. So to add support for a new local-heading element, it would probably be enough in the beginning just to provide some basic default styling. The problem with multiple H1 elements is that we cannot say for sure what’s the actual author’s intention since H1 has semantic meaning inherited from pre-HTML5 versions of the HTML standard, while a new local-by-definition levelless heading element would be free from such legacy. Corresponding semantic data could then be unambiguously extracted and interpreted by e. g. AT (e. g. using a pure-script DOM-based implementation without requiring browser to support that natively) and search engines.

[Marat-Tanalin]

@chaals I suspect support for the new element wouldn’t require too much. display: block and font-weight: bold would probably be enough.

As for outline, isn’t it somewhat fictious and having no [browser] implementations at all?

Update: To be clear, I clearly see how the outline algorithm could be useful for e. g. assistive technologies. The algorithm is, AFAIK, just not yet implemented in browsers. So to add support for a new local-heading element, it would probably be enough in the beginning just to provide some basic default styling. The problem with multiple H1 elements is that we cannot say for sure what’s the actual author’s intention since H1 has semantic meaning inherited from pre-HTML5 versions of the HTML standard, while a new local-by-definition levelless heading element would be free from such legacy. Corresponding semantic data could then be unambiguously extracted and interpreted by e. g. AT (e. g. using a pure-script DOM-based implementation without requiring browser to support that natively) and search engines.

[chaals]

@Marat-Tanalin a visual implementation would be insufficient. It has the same problem as the sectioning outline model we propose to remove - there is nothing reported to accessibility APIs, which for headers is actually an important use case.

The outline has no native browser implementation, which is a problem. But the code isn't complex, it's just a case of whether browsers can do anything useful with it.

One use case would be hierarchical navigation of a document - e.g. by putting the outline into a sidebar, or providing direct keyboard access.

[chaals]

@Marat-Tanalin a visual implementation would be insufficient. It has the same problem as the sectioning outline model we propose to remove - there is nothing reported to accessibility APIs, which for headers is actually an important use case.

The outline has no native browser implementation, which is a problem. But the code isn't complex, it's just a case of whether browsers can do anything useful with it.

One use case would be hierarchical navigation of a document - e.g. by putting the outline into a sidebar, or providing direct keyboard access.

[prlbr]

I support the idea of not recommending to use <h1> everywhere when it hasn’t been implemented in browsers in an accessible way. This may be a good general rule for the future: not to recommend features that have not been implemented well yet when there is an alternative feature that has been implemented well for a long time.

I would prefer @Marat-Tanalin’s idea of using <h> in the sectioning model over using <h1> everywhere. But I can hardly imagine that nobody thought of using a new element, be it <h>, <hx> or something else, before introducing the <h1> everywhere option in the spec. Looking into why it was decided to reuse <h1> might be a good idea before deciding on a new element.

However, I agree with @chaals that a new element should not be introduced for this unless browser vendors agree and implementation happens.

@Marat-Tanalin

that could be useful e. g. for HTML-based books that may contain far more levels than a regular HTML page

How frequent are headings with a far greater depth than six? <H1> to <H6> had already been in HTML in 1991 and it’s still the number of explicit levels we have more than two decades later, although the easy and obvious solution would have been to extend these to, say, <H9> at least. My point isn’t that we shouldn’t improve things, but that we should make sure we’re solving real problems.

[prlbr]

I support the idea of not recommending to use <h1> everywhere when it hasn’t been implemented in browsers in an accessible way. This may be a good general rule for the future: not to recommend features that have not been implemented well yet when there is an alternative feature that has been implemented well for a long time.

I would prefer @Marat-Tanalin’s idea of using <h> in the sectioning model over using <h1> everywhere. But I can hardly imagine that nobody thought of using a new element, be it <h>, <hx> or something else, before introducing the <h1> everywhere option in the spec. Looking into why it was decided to reuse <h1> might be a good idea before deciding on a new element.

However, I agree with @chaals that a new element should not be introduced for this unless browser vendors agree and implementation happens.

@Marat-Tanalin

that could be useful e. g. for HTML-based books that may contain far more levels than a regular HTML page

How frequent are headings with a far greater depth than six? <H1> to <H6> had already been in HTML in 1991 and it’s still the number of explicit levels we have more than two decades later, although the easy and obvious solution would have been to extend these to, say, <H9> at least. My point isn’t that we shouldn’t improve things, but that we should make sure we’re solving real problems.

[Marat-Tanalin]

@prlbr

How frequent are headings with a far greater depth than six?

While six levels may be enough for regular pages, books may potentially have much more nested subchapters. Anyway, removing depth limitation would be just a nice side effect. The main point is to get free from the legacy inherited semantics of H1 as a global heading that is probably one of things that prevent the outline algorithm from finally getting implemented reliably and unambiguously.

[Marat-Tanalin]

@prlbr

How frequent are headings with a far greater depth than six?

While six levels may be enough for regular pages, books may potentially have much more nested subchapters. Anyway, removing depth limitation would be just a nice side effect. The main point is to get free from the legacy inherited semantics of H1 as a global heading that is probably one of things that prevent the outline algorithm from finally getting implemented reliably and unambiguously.

[dylanb]

Given that WCAG has a normative requirement that basically boils down to "it must work on the platforms you need to support", should we be recommending techniques that don't work on all major platforms?

[dylanb]

Given that WCAG has a normative requirement that basically boils down to "it must work on the platforms you need to support", should we be recommending techniques that don't work on all major platforms?

[cheshrkat]

Seems like a good idea to stop recommending the pattern until (if..) it's actually implemented.

I'd back the suggestion to finally add an h element, particularly with an optional level attribute <h level=“7”>Foo</h> (borrowing an idea from Steve's html5-h spec). A fully extensible outline would be useful... it would obviously also work to add more levels, or allow any tag matching the pattern <h*></h*>.

Not saying the ranked headings shouldn't be implemented, though. There are use cases for both section+h and section+ranked headings - you can't always add wrapper elements just to set ideal heading levels.

How frequent are headings with a far greater depth than six?

Large legal documents can exceed six levels. There are also some cases where concatenated documents (eg. for printing) can exceed six. While not common they're definitely out there.

[cheshrkat]

Seems like a good idea to stop recommending the pattern until (if..) it's actually implemented.

I'd back the suggestion to finally add an h element, particularly with an optional level attribute <h level=“7”>Foo</h> (borrowing an idea from Steve's html5-h spec). A fully extensible outline would be useful... it would obviously also work to add more levels, or allow any tag matching the pattern <h*></h*>.

Not saying the ranked headings shouldn't be implemented, though. There are use cases for both section+h and section+ranked headings - you can't always add wrapper elements just to set ideal heading levels.

How frequent are headings with a far greater depth than six?

Large legal documents can exceed six levels. There are also some cases where concatenated documents (eg. for printing) can exceed six. While not common they're definitely out there.

[chaals]

discussion on public-html

[chaals]

discussion on public-html

[adanilo]

Removing the last example just before 4.3.10.1 which has "This final example would need explicit style rules to be rendered well in legacy browsers." in its description looks sufficient since we have the explicit warning at the start of 4.3.10.1. about the outline algorithm. Happy to provide a PR for that if folks agree.

[adanilo]

Removing the last example just before 4.3.10.1 which has "This final example would need explicit style rules to be rendered well in legacy browsers." in its description looks sufficient since we have the explicit warning at the start of 4.3.10.1. about the outline algorithm. Happy to provide a PR for that if folks agree.

[LJWatson]

@adanilo

If you mean removing everything from "This third example is also semantically identical, and might be easier to maintain..." down to the 4.3.10.1 heading, that WFM, but defer to @stevefaulkner @travisleithead and @arronei for an editorial +1

[LJWatson]

@adanilo

If you mean removing everything from "This third example is also semantically identical, and might be easier to maintain..." down to the 4.3.10.1 heading, that WFM, but defer to @stevefaulkner @travisleithead and @arronei for an editorial +1

[adanilo]

@LJWatson yes that's exactly what I meant. I'll create a PR for it.

[adanilo]

@LJWatson yes that's exactly what I meant. I'll create a PR for it.

[travisleithead]

That editorial change looks like the right thing.

[travisleithead]

That editorial change looks like the right thing.

[arronei]

Closing issue based on editorial change. If this needs further investigation into an element that should be taken up in WICG.

[arronei]

Closing issue based on editorial change. If this needs further investigation into an element that should be taken up in WICG.