Re: <subline> becomes <subhead> and other updates

2013-06-09 19:42, Leif Halvard Silli wrote:
> Just a note: Unlike some other participants in this debate, I am not
> fundamentally opposed to hgroup. Frankly, I have trouble explaining
> what the problem with it is.

I am not ‘fundamentally’ opposed to it. At least I’m not 
fundamentalistically opposed to it. I simply see no good enough reason 
to add it and some problems with it.

>   E.g. until AT support is ready, what would
> the trouble bet with do the following?
>
> <hgroup role=heading aria-level=1>
>     <h1 role=presentation>HTML</h1>
>     <h2 role=presentation>Living Standard — Last Updated 8 June 2013</h2>
> </hgroup>

If you use a heading element after a heading element of higher level in 
order to provide a ‘subheading’, then you are in a trouble with some 
software. But I would say that then you just need to stop doing so. The 
hgroup element is supposed to solve a problem that need not be created. 
And if the problem is created, then you can just as well use a div 
element and the role attributes as above to deal with some specific 
problems.

Most people don’t really care much about accessibility, or even 
understand the issue. This is sad, of course. But to most authors, 
hgroup would just be a grouping element, and the only reasons to use 
they can see for it are ‘semantics’ (the all-encompassing argument in 
favor of any elements with vague definitions and great buzzwords) and 
styling: you can style the two elements as a unit. The former argument 
is irrelevant to practical impact, and the latter really means that 
authors would try to style the hgroup element and possibly remember to 
add some magic that makes the style work on old versions of IE, too – 
instead of the simple approach of using a div element that has no such 
problems.

> Also, while the working group has a formal decision to remove hgroup
> from HTML5.0, there is no such formal decision w.r.t. HTML5.1. But this
> is also why I think that we eventually need to come up with something
> better, or else authors will just go for the WHATWg spec in this case.

I don’t think most authors care about such issues at all. If they decide 
to use hgroup, they can do it of course. They can even use 
<magicSemanticElement> if they like, with identical results: modern 
browsers let you style such elements, and old versions of IE can be 
handled using the createElement trick. The only difference is that 
magicSemanticElement has no default ARIA role, but so what? You 
shouldn’t count on any default role for hgroup either.

>
>> Just because some patterns emerge
>> doesn't mean that markup rules need to be changed. On the contrary,
>> if authors can do what they want to do by combining HTML elements in
>> a certain why, why tell them to do things otherwise (like group
>> headings in some containers)?
> The answer (AFAICT) is that such combinations have the effect of being
> interpreted by the outline algorithm as representing two sections
> rather than one section.

Given the classical definitions of heading elements in HTML, that is to 
be expected. If you use them against those definitions, e.g. use h2 to 
mark up something that is logically a first-level heading, there will be 
some inevitable downsides. I would say that the outline algorithm is 
then among the irrelevant and theoretical problems rather than a real 
concern.


> Also, for users, a hgroup is supposed to be
> perceived as a single header, rather than as several. Visually, one
> ‘naturally’ groups adjacent headings into a single, subdivided heading.
> But e.g. a screenreader will probably precent them as different
> headings.
Again, this is a consequence of using two heading elements. It’s 
illogical, but it has no catastrophic impact in most browsing 
situations. If you wish to avoid all the negative consequences, just use 
heading elements consistently. There is no problem in having a heading 
element treated as one heading even though it contains inner markup e.g. 
to make some parts appear in smaller font, or to be styled otherwise in 
a special way.


>
>> If some authors wish to use headings
>> with some inner markup instead, why tell them they should switch to
>> using some very different pattern?
> For the record: To use <subheading> for that inner markup instead of
> the current usage, would not be to switch to "some very different
> pattern". Rather it would be to switch to a similar pattern.

We may have different definitions for ‘pattern’. What I was primarily 
thinking is that most authors can deal with the subheading issue 
(whatever it might mean to them) somehow, and they have done so if they 
have faced it, and we should not tell them to do things differently 
without saying why. In fact, there should be some tangible benefit to be 
presented.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/

Received on Sunday, 9 June 2013 17:17:07 UTC