W3C home > Mailing lists > Public > public-html@w3.org > December 2010

Re: suggestion for abolition of <hgroup>

From: Lars Gunther <gunther@keryx.se>
Date: Mon, 27 Dec 2010 20:17:33 +0100
Message-ID: <4D18E64D.3030804@keryx.se>
To: HTML WG <public-html@w3.org>
2010-11-30 01:04, Bruce Lawson skrev:
> can't see a use-case for multiple adjacent headings in a header that
> wouldn't be heading+subtitle(s).

I have read the entire thread and could have interjected my comments at 
another position, however I have a clear answer to this and will begin here.

Use case from a random search for TOC:

Looking at this TOC (not it's markup) there is no info between the 
chapter headings and the essay headings. I could *easily* imagine an 
author marking this up as:

<h3>What is...</h3>

I have written several essays and read a few hundred more. Going 
straight from main heading to sub heading is a very common pattern.

I am *strongly* opposed to having a lesser heading be *magically* 
transformed into a subheading and "removed from outline", based on 
position alone. Such a solution would not:

1. Fit all use cases (as explained)
2. Be robust. E.g. a 3d party JavaScript that injects some kind of link 
could easily break it.
3. Be easily taught. I've found that newcomers always seem to favour 
explicit solutions over implicit solutions. (Repeat: I teach web dev for 
a living.)
4. Be backwards compatible. It would introduce new syntax on existing 
markup. I am willing to bet my right arm that this will break web sites...

However, not liking the "magic" solutions does not make me a fan of 
<hgroup>. The fact that we have browsers on the market that claim to 
"support" it, while *not* hiding the subtitle from outlining in AT is 
proof that the issue has not been taken seriously enough (and that 
browser vendors are too keen to score useless HTML5 "points" on support 

Redefining <header> to take different meaning in different contexts is 
also not really doable. It is also a *magical* solution, with most of 
the flaws listed above. Besides, that horse has now left the stable, 
with books and articles *en masse* teaching the current definition.

We are left with 3 solutions:

1. Keep <hgroup>

2. Introduce an attribute:
<h1>My terrific idea</h1>
<h2 subtitle>Or how I saved HTML5 from being a mess</h2>

"subtitle" is only an example, not a name I've thought through.

3. Encourage usage of inline span elements

   My terrific idea
   <span class="subtitle">How I saved HTML5 from being a mess</span

However, this option does not really solve the *content* issue. Even if 
it is stylable through CSS, the subtitle is not *hidden* from AT 
technologies, external parsers, etc.

A combination of 2 and 3 would solve that problem

   My terrific idea
   <span subtitle>How I saved HTML5 from being a mess</span>

However, that sounds a lot like a new element:

   My terrific idea
   <subtitle>How I saved HTML5 from being a mess</subtitle>

BTW, since the <small> element has gotten a specific meaning, it can not 
be re-used in this context. Having multiple meanings to one element is 
bad. Confusing and hard to teach.

The nut to crack for an author is this: Do you really wish to *hide* the 
subtitle, or do you just want it to be stylistically offset? I think we 
will see tons of abuse when authors want the latter, but mark up as if 
they wanted the former.

To achieve a stylistically offset, but non-hidden, heading, I suggest 
using solution 3 above.

In order not to confuse this use case with the other (real hiding), a 
"subtitle" attribute is my preferred solution.

I support dropping <hgroup> in favour of an attribute. It is the most 
teachable and clear solution: "Normally this would be an ordinary 
heading, but the presence of of this attribute alters its meaning."

I also predict that it will be easier for tools to look for an 
attribute, instead of looking for a position within <hgroup>.

Follow up question: Do we really have such a strong use case for hiding 
subtitles, that it warrants an element or an attribute at all? On that 
matter I have neither opinion nor arguments.

But it would be better to move whatever solution we agree upon to 
HTML.next and not burden our future with a solution that is far from 
optimal, and very far from concensus.

Lars Gunther
Received on Monday, 27 December 2010 19:18:14 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:07 UTC