I disagree with this bug. 

It would be wrong to make fundamental changes to the hgroup definition in this way. In your proposal the example adds more content to the h1 element than should be used - if the sub heading is part of the main heading then there shouldn't be a sub heading at all, as reading the code suggests all the content is all part of the h1. 

Wrapping a heading and sub heading with hgroup links the two headings, which wouldn't otherwise be linked (thus read independently of each other) and helps identify the main, or shortened heading, from the overall heading. 

In the example in the spec, Dr. Strangelove is the main heading of the film (and the shortened reference) where Dr. Strangelove, Or: How I Learned to Stop Worrying and Love the Bomb is the full film title (with the second part being a sub heading). 
I understand some of the confusion around hgroup but the spec is clear on it's use. The confusion seems to be around when it would be used which, in reality, wouldn't actually be that often. 

The example you proposed is different to how the spec should be understood as you are suggesting the subheading tag content is part of the h1 element whereas the spec refers to related headings on a page, separating a directly linked subheading with a more individual heading, for example there is no indication of heading relationships in the below code:

<h1>Page title</h1>
<h2>Page sub heading</h2>
<h3>Navigation</h3>

When adding hgroup the page title and page sub heading is grouped as related content and separated from the navigation heading:

<hgroup>
<h1>Page title</h1>
<h2>Page sub heading</h2>
</hgroup>
<h3>Navigation</h3>

> Doesn't support the use case of multiple subheadings of different weights.

Couldn't you just nest the <subhead> elements?

Krijn suggested using <small>. Advantage is that the default styling is closer and we do not need a new element. Disadvantage is that the meaning of <small> depends on the context, but I am not sure that is a problem. (You could even argue that <small> serves the purpose of clarifying text.)

This seems unnatural to me to have the subheading be a child of the heading, rather than a sibling.  I'd prefer we just simply drop the hgroup element and have the heading and subheadings be siblings within the header element.

The problem with having them as children is that it can result in unwanted styling inheritance, where the styles for the heading would have to be reversed explicitly for the subheading.  It also makes some styles difficult to achieve.

Consider for example where the author wants a stylish bottom border below the main headings, optionally followed by a subheading.  With the subhead as a child of the h1, the bottom border would instead be placed below the subheading.

Similarly, consider a case where the author wants the main heading to have a background color or image, but which should not appear behind the subheading.  With the subhead as a child of the h1, the background would naturally be behind both.  It would be possible to position the subheading outside of the box, but that creates unnecessary complexity.

The common examples of subheadings I've seen in the wild have always been done using sibling elements, and that's how I've always done them myself when I've needed them.  Consider for example, the way Slashdot have marked up theirs:

<div id="logo" >
  <h1><a href="//slashdot.org"><span>Slashdot</span></a></h1>
  <div id="slogan"><h2>News for nerds, stuff that matters</h2></div>
</div>

(Slightly reduced version of slashdot's header)

I've never seen any site use any pattern similar to this proposed <subhead> element and it seems likely to confuse authors more than hgroup.  It seems likely that the obvious error of placing the subhead as a sibling of the heading element will be quite common, and also makes much more sense.

e.g.  The pattern should be like this:

<section>
  <header>
    <h1>Main Heading</h1>
    <XXX>Subheading</XXX>
  </header>
  ...
</section>

(Where <XXX> is used as a placeholder for whichever element or element/attribute combination we decide to use, whether that simply be any <h2> to <h6> element, those elements with a subhead="" attribute, a new <subhead> element, or whatever else.)

Educator perspective:

I have made some research into what pattern is most obvious to people having little experience in HTML, but are in the learning process = my students. A made this research with 8 students, all who have studied web design and markup for about 150 hours.

The purpose was to see what pattern was most intuitive to understand and would lead to the least amount of misunderstanding and bad usage. The methodology was as follows:

1. I explained the rationale, i.e. that subtitles/taglines should not be considered individual headers, and be hidden in outline algorithms.

1b. I explained that such outline algorithms have (at least) two use cases and pointed to Wikipedia generating outlines for longer articles (intra page navigation) and explained how users of AT (especially screen readers) use headers to skim through pages and jump between sections.

I got the impression that the use cases were understood.

2. Trying my very best to be neutral, I presented the following alternatives to them:

a. hgroup with h1+h2 as the spec stands today.

b. h1+h2 but no hgroup, saying that and h2 immediately following an h1 is changed because of its position.

c. hgroup with h1 + sibling "subhead" (of any name)

d. h1 with "subhead" child element (this bug).

3. I asked the following questions:
a. Does any pattern make immediate sense to you, i-e. would you intuitively understand it even if it had not been explained?
b. Could you envision a situation where the markup you've created got destroyed because the pattern is too fragile? (It was hard to explain this neutrally as a test giver, since I had to give examples.)

Half of the group of students gravitated towards example c, which they thought was the clearest. When asked if we really need TWO new tags to describe what after all is a very simple semantic case, they back peddled, opting for a combination of b and c, i.e. a h1 element immediately followed by a subhead element.

1/4 of the group immediately preferred pattern d (this bug). 1/4 could not decide what pattern they preferred.

Having h2 change its value depending on being inside hgroup (a) or position (b) was generally confusing. No student liked this idea. It was considered an extra threshold that would make HTML harder to learn.

When the discussion shifted to consideration b (is the pattern robust or fragile), every student preferred alternative d (this bug). The only objection was a gut feeling that hn-elements should not have children at all, which was abandoned during the follow up conversation. This gut feeling was identified as a driving factor for students choosing alternative c or the b+c combination in the first place, making at least 2 students change their "vote" in favor of (d).

What I can say with certainty from my research is that elements should not alter their meaning depending on position. An h2 should not be something else just because it is trailing an h1 or is put inside an hgroup. This does confuse learners. Of the two, using hgroup is the least confusing option, since it is explicit.

I can also say with certainty, that my students all agreed that some kind of wrapping was needed (c or d), otherwise the markup would be fragile. Especially the students who considered using WYSIWYG editors, or providing such options to their customers. (I have students who build CMSs in PHP providing that through CKeditor.) Having subhead elements as siblings to the real header would deteriorate when customers start to use such tools.

No student could immediately envision an UI or mechanism that would alleviate such concerns. Having to educate customers was considered something they did not look forward to doing.

Thus, if the subhead is not a child of the header, it must be wrapped. In the end there was agreement that option (d) made most sense, followed by option (c).

But the question remains, do we really wish to add TWO elements in order to mark up subheaders/taglines? That consideration would disqualify option (c), leaving option (d) as the winner.

However, since this confirms my own opinion, it could easily be argued that I was not neutral in conducting the research. I have not seen anyone else even attempting to do a similar thing, though, and my findings should not be totally dismissed just because they echo my opinion. It could also be that my opinion was well informed, since i know what is teachable and what is hard to teach from my now quite extensive experience.

Thus, I would be the first to admit that this research is woefully incomplete. Thus, my primary suggestion is still the one I gave in bug 11828 - drop hgroup from the spec for now and wait until more research has been done.

(In reply to comment #0) 
> * It is slightly less verbose

Minimally so, given that most people would probably end up using a <span> around the main heading in order to get easier styling control.


> * It is easier to style with CSS. <hgroup> requires detailed knowledge of the
> markup structure whereas with <subhead> and a :heading(n) selector, one can do:
> 
> :heading(n) {/*rules for the heading*/}
> :heading(n) > subhead {/*special rules for the subheading*/} 

As opposed to:

   h1 { ... }
   hgroup h2 { ... }

...this doesn't seem simpler.

Also, I think it would probably end up being really:

   h1 span.main { ... }
   h1 subheading { ... }

...vs:

   hgroup h1 { ... }
   hgroup h2 { ... }

...which is at least a wash, if not more confusing, IMHO.


> * It is semantically less confusing. There is no ambiguity about whether the
> <hgroup> is the heading element or the child <hx>. That means it is more
> obvious what a :heading selector will select, and more obvious how
> accessibility APIs will map the various elements.

I don't think this confusion exists with anyone except the spec weenies amongst us, and the spec weenies will find the answer unambiguously in the spec.


> * It arguably has better fallback semantically (if not visually, although that
> is easier to fix using CSS; see above). A legacy UA will consider the whole
> thing to be one heading rather than several headings with a
> possibly-nonsensical parent-child relationship as in the <hgroup> case.

I'm not sure the semantic fallback really matters. <hgroup> has significantly better graceful degradation in real use cases, even without CSS.


> * It preserves the invariant that all <hx> elements represent headings, which
> may make certain tools easier to write. I also think it makes the outline
> algorithm slightly easier to implement.

The outline algorithm doesn't even mention <hgroup>, so I'm not sure it would make much difference at all. The only complexity <hgroup> adds is in getting text out when you need just a single string, and that is pretty minimal complexity, at least compared to the outline algorithm.


> * It seems harder to use incorrectly. The only obvious mistake that one could
> make would be to use <subhead> outside a <hx> element which would be relatively
> harmless (semantics of <div>).

Given how <h1> is misused, I don't see any reason to think that misuse of any proposal here would end up being appreciably worse.


> The main disadvantages I can think of are:
> 
> * It makes it slightly harder to determine the text of a heading (need to walk
> the tree skipping <subhead> elements). On the other hand simple properties like
> .textContent should be considered inadequate anyway since alt text should be
> considered part of the heading text.

It makes generic algorithms for grabbing text inadequate too. In fact, I'd say it basically means you have the same complexity problem as <hgroup> mentioned earlier.


> * Doesn't support the use case of multiple subheadings of different weights.
> This seems like a very minor use case that could be addressed in the future if
> it is significant.

The spec itself in certain incarnations has three levels of headings, so wouldn't be able to use this (but does use <hgroup>, at least when not published by the W3C).


(In reply to comment #5)
> Educator perspective:

Thanks for this, it's quite interesting information. Please continue to provide these insights!


> 3. I asked the following questions:
> a. Does any pattern make immediate sense to you, i-e. would you intuitively
> understand it even if it had not been explained?
> Having h2 change its value depending on being inside hgroup (a) or position (b)
> was generally confusing. No student liked this idea. It was considered an extra
> threshold that would make HTML harder to learn.

This is interesting, because it contradicts what we see in the wild: what people tend to do when they have subheadings (assuming they use anything other than <div>s) is use an <h1> immediately followed by an <h2>.


> What I can say with certainty from my research is that elements should not
> alter their meaning depending on position.

Agreed, though I don't think the meaning of <hx> change with <hgroup>, at least not at the level Web developers would look at it. They're still headings with different "weights" (intentionally not using a term of art like "rank"). <hgroup> just groups them together, like <form> does to a bunch of <input>s, or <datalist>, <select>, and <optgroup> do (in various ways) to a bunch of <option>s.


> I can also say with certainty, that my students all agreed that some kind of
> wrapping was needed (c or d), otherwise the markup would be fragile.

Option (a) presumably also addresses that need.


> No student could immediately envision an UI or mechanism that would alleviate
> such concerns. Having to educate customers was considered something they did
> not look forward to doing.

Well we can all empathise with that.


EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale:

I don't really see what problem the proposals here solve. <hgroup> is unambiguous, easy to style, has great graceful degradation, paves an existing cowpath (one in particular widely used by the W3C's own documents), is not especially verbose, not especially complicated... and it's documented in tutorials, and used by some newer sites. It's not something that comes up all the time, so it's not something that must be understood by new authors immediately, but when they do see it it's pretty self-explanatory, and easily searched for ("hgroup" is not a common word like "subhead").

We discussed the new sectioning elements years ago, shook out the obvious problems, and now it's long past time to stop bikeshedding these decisions and just move on.

mass-move component to LC1