[whatwg] The real issue with HTML5's sectioning model (was: "Headings and sections, role of H2-H6" and "Should default styles for h1-h6 match the outlining algorithm?")

[Eduard Pascual]

On Fri, Apr 30, 2010 at 10:02 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
> On Fri, Apr 30, 2010 at 11:57 AM, Eduard Pascual <herenvardo at gmail.com> wrote:
>> Actually, if we try to "implement" the outlining algorithm in
>> the form of selectors that match each level of headings we have:
>> On the case that the <h1>-only approach, selecting each level of
>> heading requires a list of something raised to the n-th power
>> selectors, where n is the heading level minus one. In other words: the
>> top level heading can be selected with "h1", but the next level would
>> require "section h1, nav h1, aside h1, article h1, ...", then for the
>> third level we go nuts (the example is limited to <section> and
>> <article> elements, including all of them would yield a list of too
>> many selectors): "section section h1, section article h1, article
>> section h1, article article h1". A four level would translate into 64
>> selectors or more (already quite insane to author), and if we ever
>> reach the fifth and further levels, we'll be dealing with hundreds or
>> thousands of selectors. If this isn't insane enough, keep in mind that
>> this is an over-simplification. Sure, there are combinations that will
>> never happen, but if we have to select also sub-headings inside a
>> <hgroup> things get pretty funny.
>
> Not true.  The CSSWG has a proposal (with unresolved issues, however)
> for an :any() pseudoclass which works perfectly in this case:
>
> :any(section, nav, aside, article) h1 { foo }
> :any(section, nav, aside, article) :any(section, nav, aside, article) h1 { bar }
> etc.
>
> (In other words, the "x" selector in the spec is just the :any() selector here.)
There is a subtle, but quite important, difference: something like
"section section h1" would work on all major browsers (with a minor JS
hack for IE to deal with "unknown" elements). Any currently works
nowhere (ok, we have :-moz-any() courtesy of David Baron, and I really
appreciate it; but it's simply useless for the scenario).

Even if an hypothetical  CSS3.1 Selectors got fast-tracked and
recommended by tomorrow, a key problem would still be there: authors
have no sane means to get HTML5'ish headings decently styled (I don't
need perfect, but some degree of *graceful* degradation is generally
needed) on current browsers.



>> This yields several advantages:
>> 1) The styling issue improves drastically: any pre-HTML5 will
>> understand this (IE would require a bit of javascript anyway) out of
>> the box:
>> h1 { styling for top-level }
>> section h1 { styling for second-level }
>> section section h1 { styling for third-level }
>> and so on, for as many levels as you need.
>
> Fixing HTML because CSS is too difficult probably isn't the right
> solution.  Address the problem at the source - CSS needs to be able to
> handle this case well.  Luckily there are further similar use-cases
> that make solving this problem fairly attractive.
Actually, I *am* trying to fix the problem at the source. This is not
about fixing HTML because CSS being difficult. It's about fixing a
design issue within HTML itself. The problems from the CSS perspective
are only a surface symptom of a deeper issue.

>
>> 2) All of a sudden, something like <section kind="aside nav"><h1>See
>> also</h1> some indirectly related links here...</section> becomes
>> possible, plus easy to style, and works happily with the outlining
>> algorithm.
>
> What's the benefit of marking something as both an <aside> and <nav>?
Quoting the HTML5 spec:
"The nav element represents a section of a page that links to other
pages or to parts within the page: a section with navigation links."
"The aside element represents a section of a page that consists of
content that is tangentially related to the content around the aside
element, and which could be considered separate from that content."
Putting that together, a section that links to other pages *and*
consists of content that is tangentially related to the content around
it *must* be *both* a nav and an aside. The most blatant example
(which I thought was clear enough from the example) are "See also"
sections found on many sites (see a couple of examples on [1] and
[2]). Currently, the closest thing we may get is
<nav><aside>...</aside></nav> or <aside><nav>...</nav></aside>. This
raises several concerns: which one should be the outer, and which the
inner section? How would that interact with the sectioning algorithm?
(ie: would a heading inside there be taken as one level lower than the
expected one?).


>> 3) Future needs will become easier to solve on future versions of the
>> specification, and with significantly smaller costs: for example,
>> let's assume a new sectioning element such as <attachment> becomes a
>> widespread need (it would already make sense on sites like web-mail
>> services, discussion boards, bug-trackers, and some others...). So a
>> new crouton on the soup, which would be treated quite like a generic
>> <div> by pre-HTML6 (or 7, or whatever) browsers. Now, with the
>> <section>+attribute approach, we'd get something like <section
>> kind="attachment">: that'd would still work with the outlining
>> algoryth (it could be treated as generic section), it's styling will
>> work smoothly, etc.
>
> What's the problem with just <attachment>?  Styling is easy to update.
The problem is that the outlining algorithm would immediately break on
any UA released before creating such an element. This can mess up with
assistive technologies, some purpose-specific search and/or parsing
utilities, and so on.
With something like <section kind="attachment">, of course UAs and
other tools would need to be updated before they understand the
specific meaning of kind="attachment", but they would already know
that it is indeed a section and would perform outlining and related
tasks properly.
Since you mention styling, I'll highlight that with the <section
kind="..."> approach styling wouldn't need to be updated at all. When,
as you claim, styling is easy to update, this is just a marginal
benefit, but still a benefit. But styling is not always easy to update
(from the top of my head, content templating and team-working are a
pair of examples of having significant costs to update styling).