Content bug: <hgroup> a valid HTML element that can be used

[j9t]

What page(s) did you find the problem on?

<hgroup>

MDN URL: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/hgroup

Specific page section or heading?

• Introductory warning
• Usage notes

What is the problem?

The main argument relies on a petitio principii: The element should not be used because AT wouldn’t support it—but AT may not support it because it’s not used. No data or rationale is provided to explain the situation or the conclusion.

Furthermore, while the article acknowledges that <hgroup> is part of the WHATWG’s Living Standard, it also says the W3C had removed it. As the only normative standard is the WHATWG’s version, and as it never really mattered what the W3C does in their (now deprecated) forks, this part of the argument is misleading.

What did you expect to see?

Information about the hgroup element based on the (WHATWG) specification and augmented by data.

Eventually, a side note pointing out what specific support is still seemed missing.

Did you test this? If so, how?

n/a

[ennioVisco]

Adding more on this issue, note that the Usage Note's banner is misleading, as it links to a W3C suggestion that is unfortunately not available since W3C is now directly linking to WHATWG (see announcement here for the details - 28th May 2019).

As reported in the note, WHATWG is actually saying the opposite of W3C, which means the link says the opposite of the banner!

Quite hard to get how one should use hgroup today, but perhaps this is part of the goal 😂

[wbamberg]

Sorry to be slow replying. I'm not sure what's best here and would be happy to hear more views. But it seems to me that this is not that clear cut.

There seem to be three reasons we might want to discourage <hgroup>:

1. it's dropped by the W3C specs. This I agree is no longer relevant, and we should drop all that
2. it's not supported by assistive technologies: I think this is (if true) a legitimate reason for not using it. Yes, maybe it's not supported by AT because it's not widely used. Even so, if it's not supported by AT, then it isn't accessible, and that's a reason not to use it, isn't it?
3. one of the main reasons to use it is to work with the outline algorithm, but the outline algorithm isn't supported by any browsers.

At least it seems worth giving the last two as drawbacks about using this feature. I think maybe we could lose the warning at the start and the categorical language "should not be used", and just cover these in "Usage notes".

[silane]

If the reason we discourage is no browser support for outline algorithm, we should also discourage nav or aside or some other tag that has no visual difference other than semantic meaning or outline. Why only hgroup is discouraged?

Also I don't think low support by AT is right reason to discourage the tag. The web technology is advancing day by day. At first, no new features are supported by any browsers or other relevant software (including AT). But as the time goes, the new feature becomes popular and the number of implemented software increases. Eventually, the feature becomes widely available and can be used without concern. That's how web is advancing.

So I agree with @wbamberg's last line. I think we should remove the warning at top and should not be used term.

[ennioVisco]

The reason why it should not be used is simply because there is no consensus about its full meaning. Take a look at this issue for example whatwg/html#5002.

How does it affect the internal hierarchy? Does it require the introduction of the concept of subheadings? Is it a heading by itself?

All these questions come to people that take special care in learning all the aspects of the html semantics. Imagine how even less clear this is for an average developer.

[silane]

Then that correct reason should be written in the page. I didn't know there are argument about the meaning of hgroup. If that is a major problem, describe it in the MDN page and that will help a lot of people aware of actual problem of hgroup and help reaching the conclusion whether hgroup should be in the HTML or not.

[aardrian]

There seem to be three reasons we might want to discourage <hgroup>:
[…]
2. it's not supported by assistive technologies: I think this is (if true) a legitimate reason for not using it.
Yes, maybe it's not supported by AT because it's not widely used. Even so, if it's not supported by AT, then it isn't accessible, and that's a reason not to use it, isn't it?

To clarify, it is not supported by browsers. Assistive technology gets its information from browsers. Browsers parse the DOM, bundle it up in an accessibility tree, and pass that off to AT (though in this context it is mostly screen readers) using platform accessibility APIs. The <hgroup> element has no mapping in the accessibility APIs, so there is nothing here for AT to do.

3. one of the main reasons to use it is to work with the outline algorithm, but the outline algorithm isn't supported by any browsers.

The Document Outline Algorithm has (finally) been removed from the WHATWG HTML spec: #7829 replace current outline algorithm with one based on heading levels

[dev-nicolaos]

To clarify, it is not supported by browsers.

To clarify further, "the extra outline-related a11y features" are not supported in browsers. The element itself is supported, and now its semantic purpose...

The hgroup element represents a heading and related content. The element may be used to group an h1–h6 element with one or more p elements containing content representing a subheading, alternative title, or tagline.

...and allowed content...

Zero or more p elements, followed by one h1, h2, h3, h4, h5, or h6 element, followed by zero or more p elements, optionally intermixed with script-supporting elements.

...are clearly defined, thanks to the PR @aardrian referenced.

Relevant section of the spec: https://html.spec.whatwg.org/multipage/sections.html#the-hgroup-element

If it'd be helpful, I can take a stab at reworking the <hgroup> page to clean up some of the confusion in light of the recent developments.

[aardrian]

…The element itself is supported…

In what way? Or, rather, what does <hgroup> do differently for users than a <div>?

[dev-nicolaos]

…The element itself is supported…

In what way? Or, rather, what does <hgroup> do differently for users than a <div>?

It is supported in the sense that it is a valid HTML element. As to what it does differently for users, I don't think it has any behavioral differences. The new version of the spec seems to indicate it has semantic value and a desired usage pattern, but no explicit A11y functionality.

[aardrian]

It is supported in the sense that it is a valid HTML element.

It has been a valid HTML element for some time now, though it still has no browser support.

As to what it does differently for users, I don't think it has any behavioral differences.

It does not. Again, unless there is some implementation I am unaware of.

The new version of the spec seems to indicate it has semantic value and a desired usage pattern, but no explicit A11y functionality.

It has a desired usage pattern, but it has no accessibility features and conveys no programmatic semantics. It is, as far as users and browsers are concerned, a <div>.

I still agree the entry should be updated for its new definition in the WHATWG HTML specification, but the note that it does nothing should be retained. Until browsers identify an intent to implement, it is a functionally generic.

[dev-nicolaos]

It has been a valid HTML element for some time now, though it still has no browser support.

Until browsers identify an intent to implement, it is a functionally generic.

What work are you imagining browsers need to do in order to consider <hgroup> implemented/supported? UA styles? It's supported in browsers the same way other elements which don't have built in A11y features are, which is what we should expect given the new spec.

I do agree that a note clarifying <hgroup> doesn't bring programmatic A11y features could be helpful, but that's doesn't mean developers shouldn't use it if they are trying to represent the semantic situation documented in the spec.

[aardrian]

What work are you imagining browsers need to do in order to consider

implemented/supported?

Sorry you are correct. When I said "support" I meant exposing it to users in a programmatic way. But since its new definition functionally makes it no different than a <div>, browsers' current support happens to satisfy it.

Whether or not developers choose to use it is then up to their own preferences, since it will not affect users on its own.

I still believe that lack of programmatic meaning should be explicitly noted in a warning since for years the fiction of the Document Outline Algorithm has caused many a dev to think it does something for the user.