Re: hgroup: a possible alternative

Hi james,
I like the idea, i think the main issue with hgroup is that authors
find it difficult to understand that some headings in hgroup are no
longer h1-h6 but some vaguely defined subtitle/subheading/tagline

I came up against the vagueness issue when trying to work out what
default roles for such headings and the hgroup itself should be.

as brucel puts it "It (hgroup) has no rendering; its sole purpose is
to hide subtitles from the outlining algorithm"
http://www.brucelawson.co.uk/2010/on-the-hgroup-element/

If there is a new element to be added why not make it a clear semantic
element such as subhead/subtitle/whatever

Making it easier for authors to understand (ie a clear semantic
element rather than changes implied upon h1-h6) will mean it will be
more likely that it is used correctly.


regards
stevef

On 10 January 2011 22:46, James Graham <jgraham@opera.com> wrote:
>
>
> On Mon, 10 Jan 2011, Toby Inkster wrote:
>
>> Not sure if there's an open issue on hgroup that's accepting change
>> proposals, but here's the stub of an alternative idea for discussion
>> anyway.
>>
>> It seems to me that much of the dislike of <hgroup> can be solved by
>> turning it inside out. Instead of:
>>
>>        <hgroup>
>>                <h1>Medieval Beekeeping</h1>
>>                <h2>The evolution of an artform</h2>
>>        </hgroup>
>>
>> You could have:
>>
>>        <h1>
>>                <hline>Medieval Beekeeping</hline>
>>                <hline small>The evolution of an artform</hline>
>>        </h1>
>
> Why not <h1>Main Heading <subhead>Subheading</subhead></h1>, where a heading
> element can have 0 or more <subhead> children that represent subheadings (we
> can bikeshed over the name of course). This requires less markup than
> <hgroup> or this <hline> proposal. I also think it works marginally better
> for CSS since the selectors for each part are simpler (assuming we get
> :heading(n) to select n-th level headings):
>
> :heading(n) {/*rules for the heading*/}
> :heading(n) > subhead {/*special rules for the subheading*/}
>
> Compared to <hgroup> it is more obvious what :heading would select (there is
> no <hgroup> vs child-that-represents-the-heading confusion) and it is easier
> to select the subheading(s) since they always have the same element name.
> Compared to <hline>+<hline small> it removes the need for an attribute
> selector.
>
> Semantically, it is arguably less flexible than <hgroup> since one cannot
> have different subheadings of different rank, but that seems like a minor
> use-case. It has slightly different fallback behaviour since legacy UAs will
> presumably consider the whole element a single heading rather than multiple
> headings. This seems theoretically cleaner, although I don't know how much
> difference it makes in actual UAs. <subhead> also has the benefit of
> simplifying the outline algorithm somewhat compared to <hgroup>.
>
>



-- 
with regards

Steve Faulkner
Technical Director - TPG

www.paciellogroup.com | www.HTML5accessibility.com |
www.twitter.com/stevefaulkner
HTML5: Techniques for providing useful text alternatives -
dev.w3.org/html5/alt-techniques/
Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html

Received on Tuesday, 11 January 2011 10:12:42 UTC