- From: Kornel <kornel@geekhood.net>
- Date: Fri, 3 Jul 2009 12:58:50 +0100
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
Received on Friday, 3 July 2009 04:58:50 UTC