[Bug 11731] Replace <hgroup> element with a <subhead> element used as the child of the <hx> element

http://www.w3.org/Bugs/Public/show_bug.cgi?id=11731

Ian 'Hixie' Hickson <ian@hixie.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |ian@hixie.ch
         Resolution|                            |WONTFIX

--- Comment #6 from Ian 'Hixie' Hickson <ian@hixie.ch> 2011-02-25 07:08:06 UTC ---
(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.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Friday, 25 February 2011 07:08:11 UTC