Obsolete <hgroup>

[sideshowbarker]

Dropping hgroup will allow us to achieve our collective long-sought goal of dropping the current still-unimplemented-after-15-years HTML outline algorithm — and replacing it with something better, as proposed in #3499.

It turns out that the problem we seem to be trying to solve with hgroup isn’t a problem that authors are actually asking us to solve — that is, lack of a standard element for marking up subheadings isn’t an actual significant pain point for authors.

And it also turns out that hgroup is just a consequence/by-product/artifact of the current HTML outline algorithm that’s necessary only so far as the current HTML outline algorithm is necessary. And so, if we don’t actually need the current HTML outline algorithm, then it follows that we also don’t need hgroup.

Use-counter data shows that hgroup is anyway only used in around 0.2% of documents (two-tenths of one percent).

So as far as the question about what authors should use to mark up subheadings, if they can’t use hgroup: Authors aren’t actually using hgroup now anyway — at least, literally 99.8% of them aren’t using hgroup — so the answer is: authors can keep on using whatever else they’re already choosing to use now to mark up subheadings, and that they’re already apparently happy with. (If authors weren’t happy with what they’re already using, they would have already switched to using hgroup.)

---

/acknowledgements.html ( diff )
/browsers.html ( diff )
/browsing-the-web.html ( diff )
/canvas.html ( diff )
/common-dom-interfaces.html ( diff )
/common-microsyntaxes.html ( diff )
/comms.html ( diff )
/custom-elements.html ( diff )
/dnd.html ( diff )
/dom.html ( diff )
/dynamic-markup-insertion.html ( diff )
/edits.html ( diff )
/embedded-content-other.html ( diff )
/embedded-content.html ( diff )
/form-control-infrastructure.html ( diff )
/form-elements.html ( diff )
/forms.html ( diff )
/grouping-content.html ( diff )
/history.html ( diff )
/iana.html ( diff )
/iframe-embed-object.html ( diff )
/image-maps.html ( diff )
/imagebitmap-and-animations.html ( diff )
/images.html ( diff )
/index.html ( diff )
/indices.html ( diff )
/infrastructure.html ( diff )
/input.html ( diff )
/interaction.html ( diff )
/interactive-elements.html ( diff )
/introduction.html ( diff )
/links.html ( diff )
/media.html ( diff )
/microdata.html ( diff )
/named-characters.html ( diff )
/obsolete.html ( diff )
/origin.html ( diff )
/parsing.html ( diff )
/references.html ( diff )
/rendering.html ( diff )
/scripting.html ( diff )
/sections.html ( diff )
/semantics-other.html ( diff )
/semantics.html ( diff )
/server-sent-events.html ( diff )
/structured-data.html ( diff )
/syntax.html ( diff )
/system-state.html ( diff )
/tables.html ( diff )
/text-level-semantics.html ( diff )
/timers-and-user-prompts.html ( diff )
/urls-and-fetching.html ( diff )
/web-messaging.html ( diff )
/web-sockets.html ( diff )
/webappapis.html ( diff )
/webstorage.html ( diff )
/window-object.html ( diff )
/workers.html ( diff )
/worklets.html ( diff )
/xhtml.html ( diff )

[mtrootyy]

The following sentence should be added to the section of "The h1, h2, h3, h4, h5, and h6 elements".

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.

Ref: http://web.archive.org/web/20201112031837/https://www.w3.org/TR/html53/sections.html#the-h1-h2-h3-h4-h5-and-h6-elements

[sideshowbarker]

I believe the existence of hgroup is the only thing blocking us from being able to proceed with #3499 (replacing the current, broken HTML outline algorithm with something better).

[sideshowbarker]

The following sentence should be added to the section of "The h1, h2, h3, h4, h5, and h6 elements".

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.

Ref: http://web.archive.org/web/20201112031837/https://www.w3.org/TR/html53/sections.html#the-h1-h2-h3-h4-h5-and-h6-elements

Adding that is orthogonal to the scope of this PR, which is strictly about first just removing hgroup, and secondarily about adding some suggestion for what to use in place of it — which I think the text at https://github.com/whatwg/html/pull/6462/files#diff-41cf6794ba4200b839c53531555f0f3998df4cbb01a4d5cb0b94e3ca5e23947dR115312 does sufficiently.

The question of whether it should be OK or not to use h1–h6 to mark up subheadings is a separate concern. It may be something to add to #3499, once the patch in that PR is updated to drop hgroup. Or it may merit a separate issue.

But certainly I don’t think is should be included in this PR — we shouldn’t make it be something that could end up blocking this PR. We don’t need to block this PR on getting resolution on that part.

On top of that, I’m not sure I agree myself that h1–h6 shouldn’t be used to mark up subheadings. At least not yet. I’d need to learn — or re-learn, be reminded — about why it’s bad, and who/how it ends up being bad for as far as user experience.

And speaking as a maintainer of a conformance checker, I’m not enthusiastic in general about adding document-conformance restrictions that can’t be checked programmatically — because for that class of restricions, we have no way to alert authors that they’re violating a spec requirement.

That said, I can imagine some ways I could make the HTML checker emit a warning for that “h1–h6 elements must not be used to markup subheadings” case of the spec were to normatively require it. But I would not be enthusiastic about adding such a check. The fact that the HTML checker doesn’t check for it currently hasn’t seemed to cause any observable problems.

But I can say from experience that trying to add it to the checker would likely create a problem of authors being annoyed by the checker warning about using h1-h6 for subheadings — because I’m certain many authors don’t agree with that, and would consider it a false positive, and a bug in the checker. And they would file bugs against the checker asking for it to be removed.

[prlbr]

It turns out that the problem we seem to be trying to solve with hgroup isn’t a problem that authors are actually asking us to solve — that is, lack of a standard element for marking up subheadings isn’t an actual significant pain point for authors.

In my humble opinion, authors were asking standards editors to solve it, but they messed this one up. WHATWG and W3C didn't agree on a solution, which confused authors. Furthermore, the particular way hgroup has been standardized has been criticized from the beginning on due to accessibility problems.

The problem isn't hgroup per se, but that hgroup required sub-headings to be coded as h2/h3/h4/... elements, which made a bad practice that had occurred in the wild and hurt accessibility suddenly mandatory. The idea was to pave cow-paths I think, which is nice when the path does not take a detour through a mine-field, as it did in this case.

Sorry, historical lamentations aren't helpful most of the time, but let's not pretend that author demand wasn't/isn't there either.

And it also turns out that hgroup is just a consequence/by-product/artifact of the current HTML outline algorithm that’s necessary only so far as the current HTML outline algorithm is necessary. And so, if we don’t actually need the current HTML outline algorithm, then it follows that we also don’t need hgroup.

hgroup is supposed to make screen readers not announce sub-headings coded as h2/h3/h4/... as headings h2/h3/h4/.... Have any screen readers implemented this?

Use-counter data shows that hgroup is anyway only used in around 0.2% of documents (two-tenths of one percent).

That's a lot on the web, isn't it?

So as far as the question about what authors should use to mark up subheadings, if they can’t use hgroup: Authors aren’t actually using hgroup now anyway — at least, literally 99.8% of them aren’t using hgroup — so the answer is: authors can keep on using whatever else they’re already choosing to use now to mark up subheadings, and that they’re already apparently happy with. (If authors weren’t happy with what they’re already using, they would have already switched to using hgroup.)

The logic is flawed. Not using hgroup may simply be the lesser evil here, it doesn't mean that authors are happy. For example, I've implemented this for a few years in software now:

<div role=group>
<h1>Heading</h1>
<p>Subheading</p>
</div>

It works, but I would have much preferred to implement a standard HTML element for this standard task, which would be more comfortable for users of my software to style. The reason I haven't switched to hgroup is that I would have had to turn the sub-heading into a h2/h3/h4, a bad practice that would hurt more than hgroup helps. But having sth. like

<hgroup>
<h1>Heading</h1>
<p>Subheading</p>
</hgroup>

would have been great.

[domenic]

Hi @sideshowbarker; sorry for the long delay in reviewing this. Thanks for starting the conversation with a concrete PR. I'm excited to work with you on landing this, and the subsequent outling algorithm work.

There are two major points to discuss:

1. The edits to the CSS rules do not seem to be correct.

   • Implementations do make hgroup display: block.
   • I'm not so sure about unicode-bidi; that section of the rendering rules seems undertested. (E.g. I don't see corresponding rules for h1 in Blink's UA styleshet.)
   • The deletions of the various hN + hgroup rules need tests. I don't see them in Blink's UA stylesheet, so deleting them is probably correct, but it'd be good to check.

2. It's not clear whether obsoleting is the right move, versus changing this into a semantics-only/styling hook element (with no accessibility implications). In the latter case, we'd encourage using <hgroup> + <h1> + <p> for subheadings, I think.

   Other examples of semantics-only/styling hook elements with no special accessibility mappings that I can find are: <address>, <section> in most cases, <cite>, <time>, ....

   Keeping <hgroup> in this capacity might help serve the 0.2% of documents (which, as @prlbr points out, is a pretty significant number) which are looking for a way to mark up subheadings. Basically, all of @prlbr's comment is along these lines, and I think we should consider it as a serious alternative.

   The counterargument is that the well has been poisoned by too many years of <hgroup> being used with <h2>s, and we should not try to make the best of it, but instead just try to get rid of it. I can sympathize with that, but I'm unsure how to weigh it against the expressed author desire for some way of grouping together headings and subheadings for semantic and styling purposes. If we don't repurpose <hgroup> in this way, it seems unlikely we'll ever get another element that serves that role.

   On balance I lean slightly toward repurposing <hgroup> as a semantics-only/styling hook, but I defer to you as the one doing the work to take that input and other community discussion and do what you think is best.

[sideshowbarker]

@domenic Thanks, and I’m just ACKing this for now, because I’ve got extremely limited free cycles righ now, so know it’s gonna be a while before I could go back and make updates myself on this. (I have been meaning for a long time now to respond to @prlbr’s comments — but haven’t managed to even make time for that yet…)

I would still personally prefer that we drop hgroup altogether — but short of that, I would be satisfied if we could at least get the spec to a state such that it no longer defines hgroup in a way that blocks us from removing the outline algorithm. I believe the changes suggested in #6462 (comment) would allow that. Am I right?

If that’s correct, then I would also be happy if somebody else cared enough to step in and pick up work on this PR, and make those suggested changes. I think that would get it landed faster — and so also help us get more quickly to the goal of being able to remove the outline algorithm.

But if nobody else is able to step in, I will get back this eventually — I just think it’s unlikely I’ll be able to get back to it myself any time this month.

[domenic]

I believe the changes suggested in #6462 (comment) would allow that. Am I right?

Yep. hgroup would no longer have any impact on the new heading-based outline algorithm.

[dpk]

So as far as the question about what authors should use to mark up subheadings, if they can’t use hgroup: Authors aren’t actually using hgroup now anyway — at least, literally 99.8% of them aren’t using hgroup — so the answer is: authors can keep on using whatever else they’re already choosing to use now to mark up subheadings, and that they’re already apparently happy with. (If authors weren’t happy with what they’re already using, they would have already switched to using hgroup.)

This is a poor answer for those of us in that 0.2%. I have been using <hgroup> for over a decade. If there is a real solution that really works accessibility-wise, I will adopt that instead. But I still don’t understand how the alternative proposals will actually resolve the issue that <hgroup> was designed for all along.

What happened, for example, to the proposal in #5002? (Sorry, discussion about the question of outlines, accessibility and <hgroup> seems spread out in different places so it’s hard for me to know what communis opinio currently is.)