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

Add heading-focused outlines and :heading #3499

Open
wants to merge 4 commits into
base: master
from

Conversation

7 participants
@annevk
Member

annevk commented Feb 23, 2018

This makes a number of fairly big changes:

  • Introduces a heading and heading level concept.
  • Replaces the outline algorithm with a document headings concept.
  • Requires document headings to not skip heading levels and start
    with heading level 1.
  • Introduces a :heading pseudo-class selector.
  • Introduces a :heading(level) functional pseudo-class selector.
  • Does away with the section concept (except insofar it's needed to
    influence the heading level of h1/hgroup).
  • Does away with sectioning roots.

Tests: ...

Fixes #83.


/dom.html ( diff )
/form-elements.html ( diff )
/grouping-content.html ( diff )
/index.html ( diff )
/indices.html ( diff )
/infrastructure.html ( diff )
/interactive-elements.html ( diff )
/links.html ( diff )
/sections.html ( diff )
/semantics-other.html ( diff )
/tables.html ( diff )

Add heading-focused outlines and :heading
This makes a number of fairly big changes:

* Introduces a heading and heading level concept.
* Replaces the outline algorithm with a document headings concept.
* Requires document headings to not skip heading levels and start
  with heading level 1.
* Introduces a :heading pseudo-class selector.
* Introduces a :heading(level) functional pseudo-class selector.
* Does away with the section concept (except insofar it's needed to
  influence the heading level of h1/hgroup).
* Does away with sectioning roots.

Tests: ...

Fixes #83.
@js-choi

This comment has been minimized.

Show comment
Hide comment
@js-choi

js-choi Feb 23, 2018

It’s wonderful that this is being, at last, concretely fleshed out.

I’m also interested in heading-level ranges in the pseudo-class, such as :heading(>=3). Should I raise this in a new issue, or would commenting in this pull request or in #83 be okay?

js-choi commented Feb 23, 2018

It’s wonderful that this is being, at last, concretely fleshed out.

I’m also interested in heading-level ranges in the pseudo-class, such as :heading(>=3). Should I raise this in a new issue, or would commenting in this pull request or in #83 be okay?

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Feb 23, 2018

Member

@js-choi I'd prefer new issues for enhancements on top #83 / this PR as they can be added later. It's always good for the initial take to be as simple as possible.

Member

annevk commented Feb 23, 2018

@js-choi I'd prefer new issues for enhancements on top #83 / this PR as they can be added later. It's always good for the initial take to be as simple as possible.

Show outdated Hide outdated source

annevk added some commits Feb 25, 2018

<p>When the nearest ancestor <span>sectioning content</span> or <span>sectioning root</span>
element is <span>the body element</span>, then it applies to the whole page.</p>
<p>When the nearest ancestor <span>sectioning content</span> or <code>body</code> element is
<span>the body element</span>, then it applies to the whole page.</p>
<p class="note">The <code>footer</code> element is not <span>sectioning content</span>; it doesn't
introduce a new section.</p>

This comment has been minimized.

@JoshTumath

JoshTumath Mar 17, 2018

For the header note, you removed the phrase '; it doesn't introduce a new section.' Should it be removed for this note for the footer as well?

@JoshTumath

JoshTumath Mar 17, 2018

For the header note, you removed the phrase '; it doesn't introduce a new section.' Should it be removed for this note for the footer as well?

This comment has been minimized.

@annevk

annevk Mar 18, 2018

Member

Yeah, or maybe I should update both to say that header/footer does not contribute to a heading's heading level. I guess doing another search through the document for "section" in general wouldn't hurt either.

@annevk

annevk Mar 18, 2018

Member

Yeah, or maybe I should update both to say that header/footer does not contribute to a heading's heading level. I guess doing another search through the document for "section" in general wouldn't hurt either.

@cookiecrook

This comment has been minimized.

Show comment
Hide comment
@cookiecrook

cookiecrook commented Mar 21, 2018

@stevefaulkner @alice for additional review.

@chaals chaals referenced this pull request Apr 1, 2018

Closed

Update outline algorithm #794

<p>Thus, when an <code>article</code> element starts with a <code>nav</code> block and only later
has its heading, the result is that the <code>nav</code> block is not part of the same section as
the rest of the <code>article</code> in the outline. For instance, take this document:</p>
<p>A <code>header</code> elements do not influence the <span>document headings</span> of a

This comment has been minimized.

@sideshowbarker

sideshowbarker Apr 2, 2018

Member
<p>A <code>header</code> elements do not influence the <span>document headings</span> of a

…should be:

<p><code>header</code> elements do not influence the <span>document headings</span> of a

…this is, drop the A

@sideshowbarker

sideshowbarker Apr 2, 2018

Member
<p>A <code>header</code> elements do not influence the <span>document headings</span> of a

…should be:

<p><code>header</code> elements do not influence the <span>document headings</span> of a

…this is, drop the A

@sideshowbarker

This comment has been minimized.

Show comment
Hide comment
@sideshowbarker

sideshowbarker Apr 3, 2018

Member

As far as the algorithm at https://whatpr.org/html/3499/sections.html#heading-level that assigns levels to headings, I think that for some normal cases of hgroup usage, it breaks author expectations by unintuitively assigning a level that’s different from what authors intend/assume.

For example, consider the following document:

<h1>Screenplays for Kubrick movies from the 1960s</h1>
  <p>The following are some details on movies Stanley Kubrick directed in the 1960s.
  <h2>Spartacus</h2>
    <p>1960; screenplay by Dalton Trumbo, based on a novel by Howard Fast.
  <h2>Lolita</h2>
    <p>1962; screenplay by Vladimir Nabokov, based on his own novel.
  <hgroup>
    <h2>Dr. Strangelove</h2>
    <h3>or: How I Learned to Stop Worrying and Love the Bomb</h3>
  </hgroup>
    <p>1964; screenplay by Kubrick, loosely based on a novel by Peter George.
  <h2>2001: A Space Odyssey</h2>
    <p>1968; screenplay by Kubrick and Arthur C. Clarke, based on a Clarke short story.

Given the above, the algorithm at https://whatpr.org/html/3499/sections.html#heading-level assigns a heading level of 1 to the h1 heading, and a heading level of 2 to every one of the h2 headings except the heading Dr. Strangelove (or: How I Learned to Stop Worrying and Love the Bomb) — which it instead assigns a heading level of 1 (due to the fact the author chose to put an hgroup element around the h2 title and h3 subtitle for that movie).

It doesn’t seem at all intuitive for the title to be assigned a heading level of 1 (effectively making it the same level as the title of the entire document) instead of being signed a heading level of 2 (keeping it at the same level as the headings with other movie titles.

I don’t think authors/developers would expect that title to be a level 1 heading — I think instead what they’d expect it to be a level 2 heading like the other titles in the list. And in fact that’s the level the old/existing outline algorithm in the spec would assign it.

Member

sideshowbarker commented Apr 3, 2018

As far as the algorithm at https://whatpr.org/html/3499/sections.html#heading-level that assigns levels to headings, I think that for some normal cases of hgroup usage, it breaks author expectations by unintuitively assigning a level that’s different from what authors intend/assume.

For example, consider the following document:

<h1>Screenplays for Kubrick movies from the 1960s</h1>
  <p>The following are some details on movies Stanley Kubrick directed in the 1960s.
  <h2>Spartacus</h2>
    <p>1960; screenplay by Dalton Trumbo, based on a novel by Howard Fast.
  <h2>Lolita</h2>
    <p>1962; screenplay by Vladimir Nabokov, based on his own novel.
  <hgroup>
    <h2>Dr. Strangelove</h2>
    <h3>or: How I Learned to Stop Worrying and Love the Bomb</h3>
  </hgroup>
    <p>1964; screenplay by Kubrick, loosely based on a novel by Peter George.
  <h2>2001: A Space Odyssey</h2>
    <p>1968; screenplay by Kubrick and Arthur C. Clarke, based on a Clarke short story.

Given the above, the algorithm at https://whatpr.org/html/3499/sections.html#heading-level assigns a heading level of 1 to the h1 heading, and a heading level of 2 to every one of the h2 headings except the heading Dr. Strangelove (or: How I Learned to Stop Worrying and Love the Bomb) — which it instead assigns a heading level of 1 (due to the fact the author chose to put an hgroup element around the h2 title and h3 subtitle for that movie).

It doesn’t seem at all intuitive for the title to be assigned a heading level of 1 (effectively making it the same level as the title of the entire document) instead of being signed a heading level of 2 (keeping it at the same level as the headings with other movie titles.

I don’t think authors/developers would expect that title to be a level 1 heading — I think instead what they’d expect it to be a level 2 heading like the other titles in the list. And in fact that’s the level the old/existing outline algorithm in the spec would assign it.

@sideshowbarker

This comment has been minimized.

Show comment
Hide comment
@sideshowbarker

sideshowbarker Apr 3, 2018

Member

As far as hgroup and what the heading-level algorithm should do with instead of what the current patch in this PR branch does: I think the algorithm should just ignore hgroup. That is, h2-h6 headings should always just get assigned their corresponding 2-6 heading level, with no regard for whether they have an hgroup parent and ancestor sectioning content elements.

The original/current purpose of hgroup is pretty closely bound to the existing/old outline algorithm — in that hgroup was created as a kind of necessary consequence of the fact the outline algorithm introduced the idea that headings create (conceptual) subsections (regardless of whether the headings happen to be marked up with section elements or other sectioning-content elements).

So in that model, it was necessary to ensure that a (conceptual) subsection would not be created by a heading an author intended as a subheading. Thus in the outline algorithm, that’s the effect hgroup has: It just prevents a new subsection from being created in the outline.

But if we dispense with the conceptual model of headings creating subsections (as the patch in this PR branch does), then we no longer need a way to prevent a heading from creating a subsection. So we need longer need hgroup to have any effect. It can (should) basically just become a no-op.

And if we don’t have hgroup actually doing anything, then logically the next question to consider is whether we should keep hgroup around at all. Personally, I think we shouldn’t — I think instead we should deprecate/obsolete it along with dropping the outline algorithm it was designed for. Use-counter data from the HTML checker shows that only around 0.2% of documents are using hgroup anyway.

And if we drop hgroup then the next question to consider is what authors should use to mark up subheadings. I think the answer to that is, they should use whatever they’re already using — because I think it’s clear that among the 99.8% of documents that aren’t using hgroup, there is some significant percentage that have subheadings but that the authors have chosen not to use hgroup to mark up.

In other words, instead of using hgroup, it seems that authors are largely either not putting any extra markup around heading+subheading groups at all or else they’re just a div or p around them.

So I think the vast majority of authors who are using subheadings in their documents aren’t going to care whether we drop hgroup — because they’re not using it anyway.

But all that said, I don’t feel strongly that we must drop hgroup. I guess keeping it around for continued use by the small number of authors who are using it would not do a lot of harm.

However, I do feel strongly that if we keep hgroup it must have not affect on the assignment of heading levels — for the reasons I give in #3499 (comment)

Member

sideshowbarker commented Apr 3, 2018

As far as hgroup and what the heading-level algorithm should do with instead of what the current patch in this PR branch does: I think the algorithm should just ignore hgroup. That is, h2-h6 headings should always just get assigned their corresponding 2-6 heading level, with no regard for whether they have an hgroup parent and ancestor sectioning content elements.

The original/current purpose of hgroup is pretty closely bound to the existing/old outline algorithm — in that hgroup was created as a kind of necessary consequence of the fact the outline algorithm introduced the idea that headings create (conceptual) subsections (regardless of whether the headings happen to be marked up with section elements or other sectioning-content elements).

So in that model, it was necessary to ensure that a (conceptual) subsection would not be created by a heading an author intended as a subheading. Thus in the outline algorithm, that’s the effect hgroup has: It just prevents a new subsection from being created in the outline.

But if we dispense with the conceptual model of headings creating subsections (as the patch in this PR branch does), then we no longer need a way to prevent a heading from creating a subsection. So we need longer need hgroup to have any effect. It can (should) basically just become a no-op.

And if we don’t have hgroup actually doing anything, then logically the next question to consider is whether we should keep hgroup around at all. Personally, I think we shouldn’t — I think instead we should deprecate/obsolete it along with dropping the outline algorithm it was designed for. Use-counter data from the HTML checker shows that only around 0.2% of documents are using hgroup anyway.

And if we drop hgroup then the next question to consider is what authors should use to mark up subheadings. I think the answer to that is, they should use whatever they’re already using — because I think it’s clear that among the 99.8% of documents that aren’t using hgroup, there is some significant percentage that have subheadings but that the authors have chosen not to use hgroup to mark up.

In other words, instead of using hgroup, it seems that authors are largely either not putting any extra markup around heading+subheading groups at all or else they’re just a div or p around them.

So I think the vast majority of authors who are using subheadings in their documents aren’t going to care whether we drop hgroup — because they’re not using it anyway.

But all that said, I don’t feel strongly that we must drop hgroup. I guess keeping it around for continued use by the small number of authors who are using it would not do a lot of harm.

However, I do feel strongly that if we keep hgroup it must have not affect on the assignment of heading levels — for the reasons I give in #3499 (comment)

@sideshowbarker

This comment has been minimized.

Show comment
Hide comment
@sideshowbarker

sideshowbarker Apr 3, 2018

Member

To reinforce the points I made in #3499 (comment) about hgroup having any purpose outside the context of the old/existing outline algorithm, I want to note the following specific change this patch makes; it takes the following (non-normative) text (emphasis added):

The point of using hgroup in these examples is to prevent the h2 element (which acts as a secondary title) from creating a separate section of its own in any outline

…and changes it to this:

The point of using hgroup in these examples is to prevent the h2 element (which acts as a secondary title) from creating a separate heading of its own.

On the face of it the phrase prevent the h2 element from creating a separate heading doesn’t make sense (in contrast to the phrase prevent the h2 element from creating a separate section of its own in any outline, which does make sense).

What I mean is, the h2 element does in fact create a separate displayed heading of its own in any visual rendering of the document (unless we’re end up deciding to have hgroup affect how UAs do the default visual rendering of headings, which I hope we’re won’t…).

So it’s unclear what that explanation prevent the h2 element from creating a separate heading of its own means. I guess one solution to that would be to just drop that explanation. But if we do that, then we’d need to come up with some other explanation for the point of using hgroup in the examples. However, as I pointed out in #3499 (comment), I don’t think there is any good point to using hgroup that we could explain in a way similar to the way we explained in the context of the (old) outline algorithm.

So I think that argues for dropping the hgroup examples, and I guess for dropping hgroup — since it doesn’t make much sense to have an element in the language that we can’t explain the purpose for well and that we can’t come up with good examples for that wouldn’t make just as much sense as examples where the hgroup is replaced with div or whatever).

Member

sideshowbarker commented Apr 3, 2018

To reinforce the points I made in #3499 (comment) about hgroup having any purpose outside the context of the old/existing outline algorithm, I want to note the following specific change this patch makes; it takes the following (non-normative) text (emphasis added):

The point of using hgroup in these examples is to prevent the h2 element (which acts as a secondary title) from creating a separate section of its own in any outline

…and changes it to this:

The point of using hgroup in these examples is to prevent the h2 element (which acts as a secondary title) from creating a separate heading of its own.

On the face of it the phrase prevent the h2 element from creating a separate heading doesn’t make sense (in contrast to the phrase prevent the h2 element from creating a separate section of its own in any outline, which does make sense).

What I mean is, the h2 element does in fact create a separate displayed heading of its own in any visual rendering of the document (unless we’re end up deciding to have hgroup affect how UAs do the default visual rendering of headings, which I hope we’re won’t…).

So it’s unclear what that explanation prevent the h2 element from creating a separate heading of its own means. I guess one solution to that would be to just drop that explanation. But if we do that, then we’d need to come up with some other explanation for the point of using hgroup in the examples. However, as I pointed out in #3499 (comment), I don’t think there is any good point to using hgroup that we could explain in a way similar to the way we explained in the context of the (old) outline algorithm.

So I think that argues for dropping the hgroup examples, and I guess for dropping hgroup — since it doesn’t make much sense to have an element in the language that we can’t explain the purpose for well and that we can’t come up with good examples for that wouldn’t make just as much sense as examples where the hgroup is replaced with div or whatever).

@prlbr

This comment has been minimized.

Show comment
Hide comment
@prlbr

prlbr Apr 3, 2018

As a note to @sideshowbarker's comment:

<hgroup> would have been interesting to me if It had not forced me to use <hx> as a sub-heading.

I understand that using <hx> as a sub-heading was a pattern that had been found in the wild, but as far as I can remember it has been a pattern that accessibility experts have always criticized – similar to using <table> for purely presentational reasons instead of for tabular data. Standardizing this as the correct way to do it has been an unfortunate choice.

In my opinion what we have now is a badly designed <hgroup> element besides an overloaded <header> element which serves two different purposes with different semantics, depending on whether it is “scoped to the <body>” or not.

“Scoped to the <body>”, the <header> element has an implied role=banner, meaning that it represents content that is rather site-oriented than page-specific. But when it’s not scoped to the <body>, it represents a group of introductory stuff to the nearest main/section/article/etc. it resides in, so it is specific for where it is “scoped to”.

What I would have liked to have: An element for site-oriented content, say <header>, and an element that groups the heading of a page or section with other introductory stuff, say <hgroup>.

prlbr commented Apr 3, 2018

As a note to @sideshowbarker's comment:

<hgroup> would have been interesting to me if It had not forced me to use <hx> as a sub-heading.

I understand that using <hx> as a sub-heading was a pattern that had been found in the wild, but as far as I can remember it has been a pattern that accessibility experts have always criticized – similar to using <table> for purely presentational reasons instead of for tabular data. Standardizing this as the correct way to do it has been an unfortunate choice.

In my opinion what we have now is a badly designed <hgroup> element besides an overloaded <header> element which serves two different purposes with different semantics, depending on whether it is “scoped to the <body>” or not.

“Scoped to the <body>”, the <header> element has an implied role=banner, meaning that it represents content that is rather site-oriented than page-specific. But when it’s not scoped to the <body>, it represents a group of introductory stuff to the nearest main/section/article/etc. it resides in, so it is specific for where it is “scoped to”.

What I would have liked to have: An element for site-oriented content, say <header>, and an element that groups the heading of a page or section with other introductory stuff, say <hgroup>.

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Apr 5, 2018

Member

@sideshowbarker @prlbr I think we need some kind of answer for subheadings though.

Member

annevk commented Apr 5, 2018

@sideshowbarker @prlbr I think we need some kind of answer for subheadings though.

@prlbr

This comment has been minimized.

Show comment
Hide comment
@prlbr

prlbr Apr 11, 2018

I think we need some kind of answer for subheadings though.

w3c chose to add a section on subheadings etc. for common idioms without dedicated elements.
https://www.w3.org/TR/html52/common-idioms-without-dedicated-elements.html#subheadings-subtitles-alternative-titles-and-taglines

A new element <hsub> was a favorite of some people in the past:
https://www.w3.org/html/wg/wiki/ChangeProposals/hSub

prlbr commented Apr 11, 2018

I think we need some kind of answer for subheadings though.

w3c chose to add a section on subheadings etc. for common idioms without dedicated elements.
https://www.w3.org/TR/html52/common-idioms-without-dedicated-elements.html#subheadings-subtitles-alternative-titles-and-taglines

A new element <hsub> was a favorite of some people in the past:
https://www.w3.org/html/wg/wiki/ChangeProposals/hSub

in one element of <span>sectioning content</span>.</p>
<p>Authors are encouraged to avoid a <span>sectioning content</span> element <var>section</var>
without a <span data-x="concept-heading">heading</span> descendant whose nearest ancestor
<span>sectioning content</span> element is not <var>section</var>.</p>

This comment has been minimized.

@carmacleod

carmacleod Apr 17, 2018

This sentence is difficult to parse. Does "ancestor" refer to the heading? or the section? Does the sentence simplify to "Avoid sections without headings." ?
Can you please rewrite this one?

@carmacleod

carmacleod Apr 17, 2018

This sentence is difficult to parse. Does "ancestor" refer to the heading? or the section? Does the sentence simplify to "Avoid sections without headings." ?
Can you please rewrite this one?

This comment has been minimized.

@carmacleod

carmacleod Apr 17, 2018

Also, maybe it should be inside a "Note", to be consistent with other "Authors are encouraged to..." notes.

@carmacleod

carmacleod Apr 17, 2018

Also, maybe it should be inside a "Note", to be consistent with other "Authors are encouraged to..." notes.

@carmacleod carmacleod referenced this pull request May 22, 2018

Closed

Labelling of Landmarks #1

zcorpan added a commit to web-platform-tests/wpt that referenced this pull request Jun 8, 2018

HTML: add a test for :heading
Part of whatwg/html#3499.

This does not yet test :heading().
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment