New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do not recommend using nested sections with h1 #169

Closed
chaals opened this Issue Apr 7, 2016 · 17 comments

Comments

@chaals
Collaborator

chaals commented Apr 7, 2016

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 chaals self-assigned this Apr 7, 2016

@chaals chaals added this to the may2016 milestone Apr 7, 2016

@chaals

This comment has been minimized.

Show comment
Hide comment
@chaals

chaals Apr 7, 2016

Collaborator

This should fix the most troubling part of #33

Collaborator

chaals commented Apr 7, 2016

This should fix the most troubling part of #33

@unor

This comment has been minimized.

Show comment
Hide comment
@unor

unor Apr 10, 2016

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 commented Apr 10, 2016

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

This comment has been minimized.

Show comment
Hide comment
@chaals

chaals Apr 10, 2016

Collaborator

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…

Collaborator

chaals commented Apr 10, 2016

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

This comment has been minimized.

Show comment
Hide comment
@Marat-Tanalin

Marat-Tanalin Apr 15, 2016

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 commented Apr 15, 2016

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

This comment has been minimized.

Show comment
Hide comment
@chaals

chaals Apr 16, 2016

Collaborator

@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

Collaborator

chaals commented Apr 16, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@Marat-Tanalin

Marat-Tanalin Apr 16, 2016

@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 commented Apr 16, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@chaals

chaals Apr 16, 2016

Collaborator

@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.

Collaborator

chaals commented Apr 16, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@prlbr

prlbr Apr 16, 2016

Contributor

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.

Contributor

prlbr commented Apr 16, 2016

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

This comment has been minimized.

Show comment
Hide comment
@Marat-Tanalin

Marat-Tanalin Apr 16, 2016

@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 commented Apr 16, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@dylanb

dylanb Apr 17, 2016

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 commented Apr 17, 2016

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?

@Reinmar Reinmar referenced this issue Apr 17, 2016

Closed

Headings #43

@cheshrkat

This comment has been minimized.

Show comment
Hide comment
@cheshrkat

cheshrkat Apr 19, 2016

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.

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 chaals assigned adanilo and unassigned chaals Apr 25, 2016

@chaals

This comment has been minimized.

Show comment
Hide comment
@adanilo

This comment has been minimized.

Show comment
Hide comment
@adanilo

adanilo Apr 29, 2016

Contributor

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.

Contributor

adanilo commented Apr 29, 2016

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

This comment has been minimized.

Show comment
Hide comment
@LJWatson

LJWatson Apr 29, 2016

Collaborator

@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

Collaborator

LJWatson commented Apr 29, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@adanilo

adanilo May 2, 2016

Contributor

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

Contributor

adanilo commented May 2, 2016

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

@travisleithead

This comment has been minimized.

Show comment
Hide comment
@travisleithead

travisleithead May 2, 2016

Member

That editorial change looks like the right thing.

Member

travisleithead commented May 2, 2016

That editorial change looks like the right thing.

@arronei

This comment has been minimized.

Show comment
Hide comment
@arronei

arronei May 3, 2016

Contributor

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

Contributor

arronei commented May 3, 2016

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment