Re: hgroup: a possible alternative

On Mon, Jan 10, 2011 at 2:46 PM, James Graham <jgraham@opera.com> wrote:
> 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>.

+1 to jgraham's idea here.  I like that it combines the benefits of a
container for the heading and subheading (the <hn>) and keeps the CSS
simpler (selecting subheadings is trivial; you don't have to remember
what level was used for that subheading).

The fact that legacy UAs will fall back to presenting the whole thing
as a single higher-level heading seems like a minor and ignorable
problem.

~TJ

Received on Monday, 10 January 2011 23:03:59 UTC