Re: suggestion for abolition of <hgroup>

Benjamin Hawkes-Lewis, Tue, 28 Dec 2010 18:19:36 +0000:
> On Tue, Dec 28, 2010 at 12:51 AM, Leif Halvard Silli :
>>> I believe an attribute solution must at the very least focus on the 
>>> element to be *included* in the algorithm, rather than on the
>>> ones to be excluded, if it is to have a chance.
> 
> Why?

See my reply to Lars.
http://www.w3.org/mid/20101227223340252447.4a7f79cc@xn--mlform-iua.no

In short, the algorithm for <hgroup> works that way.

>> (2) Content attribute - @abbr contains the text for the ToC:
>> 
>>       <h1 abbr='My terrific idea'>My terrific idea. How I saved
>>           HTML5 from being a mess</h1>
>> 
>>    If @abbr is emtpy, then no text lands in the ToC:
>> 
>>       <h1>My terrific idea.<h1>
>>       <h2 abbr=''>How I saved HTML5 from being a mess</h2>
> 
> Since attributes can't mark changes of language or emphasis and since this
> makes the outline text hidden metadata rather than a segment of the visible
> text, I think "hgroup", @toc, and @subtitle are all preferable approaches.

Firstly: Often the generated contents table won't have such markup
         - it is suffient to know the heading level.
Secondly: in the second example above, the h1 element contains all
          markup. The <h2 abbr=''> would  not be used, and neither 
          would it have been if it had been wrapped inside a hgroup
          element.
Thirdly: language? The language would of course be that of the element
         where the @abbr is located.
Fourthly: hidden meta data? Can't see that it would be any more
          hidden than hgroup - what makes things visible is the
          resulting generated table of content.

>> @abbr is taken from HTML4, where it contains a short version of a table
>> cell's content - a very similar function for very similar reasons.
> 
> I doubt it will come naturally to authors to think of (or care about) 
> outline titles as abbreviations of headers.

Its 'natural-ness' is compareble to <hgroup>. But it is just a name. If 
there are convincing reasons for another name, that we can discuss, as 
long as the function is kept.

> By contrast, the "subtitle" concept is familiar from the deadtree 
> world and a more obvious target for styling.

A subtitle is usually *sub*. Whereas we need to cover structures as

<h2 subtitle>A</h2>
<h1>B</h1>
<h2 subtitle>C</h2>

where the subtitle is a suptitle.

>> Advantages to going for @abbr: a) broadens existing HTML4 feature 
>> instead of
>> inventing new concept b) thus builds on existing AT support
> 
> Not meaningfully. Just because a couple AT (Jaws, Window-Eyes) use "abbr" on
> "th" doesn't mean they'll also apply it to "hX".

I certainly hope that they won't treat a Table of Content as a Table. 
What matters is that the concept is known.

>> c) as long as UAs are interested in implementing the algorithm,   authors
>> would not have problems in understanding how it works
> 
> I'm not convinced. Authors rarely use "th abbr" correctly. In so far as it's
> used, it's often used for expansions rather than contractions! This 
> should give us pause to doubt they would use "hX abbr" correctly.

I have paused to think that the name 'abbr' might not be correct 
always. E.g. it might be that an author some times wants a longer title 
in the Table of Contents than the title used in the text actually has. 
If that's an issue, then renaming it to @toc might be meaningful.

>> d) CSS: h1{content:attr(abbr)}   would replace the h1's content with the
>> content of the @attr   and it works in Opera + I think in Chrome + nightly
>> Webkit.
> 
> Why is this an advantage?

I follow the thinking, which many other also have, that things should 
be backward-compatible etc. It also means that it is easy to test how 
the short version of a particular heading works. This relates to your 
claim about hidden metadata etc. Also h1[abbr] would work.

>> In contrast, the CSS selectability of the different <hgroup> elements
>> cannot be as programmatic, without a new CSS selector.
> 
> We need a new CSS selector like ::heading(2) anyway, because of the 
> way HTML5 changes the outline algorithm.

How cool. Then we can use CSS in order to reveal the hidden heading 
level. Brilliant.

>> e) it is questionable how often it is useful to make the   heading differ
>> from its ToC representation. @abbr is a bit more   tedious and thus makes
>> sure it doesn't happen too often
> 
> Subtitles don't seem that uncommon in ordinary documents.

Not sure what point you made here.

>> f) @abbr is very flexible:
>>    * doesn't need to exactly reflect any part of a
>>      heading
> 
> Hidden metadata is likely to get out of sync.

It is not hidden. Outline supporting UAs as well as CSS, would reveal 
it.

>>        If the spec insists on the uselessness of td@abbr, the 
>> alternative is
>> to introduce hgroup inspired markup - instead of @abbr - for 
>> identifying the
>> short version of a table cell.
> 
> As someone who's actually used "abbr" to shorten meandering table 
> headers for screen reader users, I think a mechanism that did not use 
invisible metadata
> would be an improvement. @aria-labelledby might be one option.

The element @aria-labbelledby points to will be treated as an attribute 
by the screenreader - and you have described all the problems that are 
related to that above.
-- 
leif halvard silli

Received on Tuesday, 28 December 2010 18:59:02 UTC