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 23:24:16 +0000
Message-ID: <AANLkTimFpfBe3QCpOc081fQvqqwRU0mxOt-gzdOsq4cO@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 6:58 PM, Leif Halvard Silli
<xn--mlform-iua@xn--mlform-iua.no> wrote:
> 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.

OK, I don't find the referenced arguments convincing.

We don't /have/ to use "hgroup" as a model.

We could define how to handle whitespace and stray text in the outline
algorithm, or we could only allow @subtitle on block-level elements,
or we could introduce a "subtitle" element.

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

And in the less common case … what?

> Thirdly: language? The language would of course be that of the element
>         where the @abbr is located.

    <h1>Markup with a certain <span lang="fr">je ne sais quoi</span></h1>
    <subtitle>A short history of HTML</subtitle>


    <h1 abbr="Markup with a certain je ne sais quoi">
        Markup with a certain <span lang="fr">je ne sais quoi</span>
        <span>A short history of HTML</span>

You can't express the change to French in the @abbr of the heading element.

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

Judging from current browser UIs, typical authors won't see a generated
table of contents.

Markup that designates parts of the visible text as meaning certain things
("hgroup", @subtitle, "subtitle") is very different from markup that annotates
the visible text with text that is only visible when using specialist tools or
configurations (@abbr).

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

That's not necessarily a strong recommendation. ;)

> But it is just a name.

I think the problem is the concept not the name: styling subtitles is more
immediately familiar to typical authors than providing an alternate heading for
screen reader heading lists.

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

OED and Mirriam-Webster define "subtitle" as a subordinate, explanatory title.



It doesn't /have/ to be presented under the primary title.

> Whereas we need to cover structures as
> <h2 subtitle>A</h2>
> <h1>B</h1>
> <h2 subtitle>C</h2>
> where the subtitle is a suptitle.

Do we? Does anyone have some real-world examples of this on the web?

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

The concept of "subtitle" is likewise known.

Unlike actual shipped code to translate infosets into UI, just knowing some
concepts doesn't help implementors or end-users much.

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

Do you have some real-world examples of this?

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

No it doesn't. The fact that you could forcibly expose the annotation with some
special CSS does not mean the text will be typically visible.

>Also h1[abbr] would work.

That would also select headings excluded by the algorithm

Selectability doesn't seem like an advantage over a subtitle element or

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

Subtitles are not massively uncommon.

I don't think the decision about whether to include subtitles in an outline
interface should be left up to authors.

Using explicit markup for subtitles allows UAs to include or exclude subtitles
from outline interfaces.

I see no reason to make such markup "tedious".

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

For "hidden", read "hidden in typical presentations".

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

Are you confusing @aria-label (which /is/ hidden data) with @aria-labelledby
(which is not)?

  <th aria-labelledby="population-hdr">
    <span id="population-hdr">Population</span> in thousands[<a

Benjamin Hawkes-Lewis
Received on Tuesday, 28 December 2010 23:25:04 UTC

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