On 3 Jul 2009, at 12:00, Michael(tm) Smith wrote:
And it seems like introducing a new element like <subheading>
would have the disadvantage of complicating the heading hierarchy
and confusing authors about when and where to use <subheading>
versus using <h2> to <h6>, and also requiring that the spec detail
how to deal with cases like, e.g.:
<h1>
<h2>
<subheading>
...or whatever.
The rule could be simple: it doesn't change document outline, applies
to single <hx> preceding it.
Yeah, we could spec the document-conformance rules
to disallow weird <h2>-<h6>/<subheading> combinations, but even
then, the spec would have to state what UAs are supposed to do
when authors don't follow the rules and throw in weird,
non-conformant combinations anyway.
That applies to <hgroup> too. It too needs to handle weird
combinations and non-conforming uses.
IMHO <hgroup> is more difficult to use and has potential to break
document outline, so it would need more complicated error recovery
than <subheading>.
So, on balance, <hgroup> seems like it hits the sweet spot pretty
well, as far as providing something that meets the various
requirements (e.g., a means to associate headings with
subheadings, without causing an inordinate amount of confusion to
authors, and without adding an inordinate amount of processing
complexity for implementors).
I disagree.
The discussion started because <hgroup> was difficult to understand
and could be confused with <header>.
It increases complexity of document outline algorithm and authoring by
changing meaning and rank of <hx> in context of <hgroup>.
--
regards, Kornel
