Re: suggestion for abolition of <hgroup>

Benjamin Hawkes-Lewis, Tue, 28 Dec 2010 23:24:16 +0000:
> On Tue, Dec 28, 2010 at 6:58 PM, 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?

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

Pointing out the single thing that goes into the outline, is less error 
prone than pointing out every subtitle. 

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

With <hgroup>, the whitespace is already defined since it it can only 
take block level elements as children.

>> Firstly: Often the generated contents table won't have such markup
> 
> And in the less common case … what?

But does the outline algoritm pick up inline markup in the heading 
element? At least, the IE9 demo of this feature, does not. You can test 
it here: 
http://ie.microsoft.com/testdrive/HTML5/SemanticNotepad/Default.html


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

I see your point. But again, the IE9 demo of the algorithm doesn't pick 
up such language info. But may be that's up to how the algorithm is 
implemented. It would, however, also be possible to treat the text of a 
the @abbr as a 'selector'. E.g. ikn this example, the content of the 
@abbr could be used to 'select' the entire first line:

> vs.
> 
>     <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>
>      </h1>

...
>> 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 don't believe it would be more difficult for an author to look for 
@abbr than it would be to look for @subtitle.

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

I think the most troubling part of hgroup is its name. We are having 
this dicussion based on the assumption that hgroup is only a outline 
feature. However, as Rob pointed out, hgroup is actually a single, 
subdivided heading. If it we look at it from THAT angle, then I think 
it is a strong enough recommendation. Probably the best one sofar.

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

hgroup covers that usecase. My working assumption was to come up with 
something which is as good. Of those who have suggested @subtitle, you 
are the first to question whether it is of any use to support 
'sup-titles'. I agree that it is a less common use case. But it exists.

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

Perhaps a chapter will be have the heading 'A.1: Subject X', while the 
author would write 'Appendix 1: Subject X' in the Table of Contents — 
or the opposite. HTML4, for example, have examples of the opposite.

...
>> 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
> href="#note-5">5</a>]
>   </th>

No, I am not. This issue is also relevant to the @longdesc issue, where 
several have suggested to use @aria-describedby or -labelledby instead. 
Thereby ignoreing that ARIA 1.0 instructs AT to treat the textual 
*content* of elements which are are pointed to via aria-describedby or 
aria-labelledby like they would treat the content of an @alt attribute. 
THat is: they are supposed to ignore any markup in such elements. AT is 
only supposed to 'color' the content of such text according to the AT's 
ability to color any text. But they are not supposed to respect the 
semantics of the elements which keep that text.
-- 
leif halvard silli

Received on Wednesday, 29 December 2010 00:44:55 UTC