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

Re: suggestion for abolition of <hgroup>

From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
Date: Tue, 28 Dec 2010 18:19:36 +0000
Message-ID: <AANLkTinkD30VSn3u79GqzCoLY0d3tM6_gqOupXnj-eMu@mail.gmail.com>
To: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Cc: HTML WG <public-html@w3.org>, Lars Gunther <gunther@keryx.se>
On Tue, Dec 28, 2010 at 12:51 AM, Leif Halvard Silli
<xn--mlform-iua@xn--mlform-iua.no> wrote:
>> 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?

> (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.

> @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.

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

> 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".

> 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.

> 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?

> 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.

> 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.

> 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.

> g) introducing h1@abbr should also open the door for th@abbr's   return -
> currently that attribute is not permitted in HTML5.    By seeing how it works
> for headings, authos are also helped   undestanding how it works for table
> cells.

Irrelevant unless HTML5 reintroduces "th abbr".

>        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.

--
Benjamin Hawkes-Lewis
Received on Tuesday, 28 December 2010 18:20:13 UTC

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