On Fri, Apr 30, 2010 at 11:57 AM, Eduard Pascual <herenva...@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.)
Selecting for <hgroup>s is somewhat more difficult, but when you're
using <hgroup> you're probably doing something that you can throw your
own styling at. At the very least, though, just treating <hgroup> as
<h1> in terms of styling would be fine. Perhaps then throwing
additional styling at the sub-headings to shrink them appropriately,
like this:
:any(section, nav, aside, artile) :any(h1, hgroup) { foo }
...
hgroup > h1 { font-size: 1em; }
hgroup > h2 { font-size: .75em; }
hgroup > h3 { font-size: .58em; }
...
> On the case of a mixed approach, it is *absolutely* impossible to get
> the headings properly matched with current selector technology. Even
> with jquery's :has() (many variants of which have been proposed
> several times on the CSS discussion lists), things would be extremely
> hard, if even possible at all.
Indeed, addressing heading level absolutely correctly from a purely
structural point of view is difficult and verbose. But the heading
level itself is unambiguous and easy to determine, which is why a
:heading(n) pseudoclass wouldn't be a difficult thing either. But
still, with just the :any() pseudoclass, it's not terribly verbose to
get a good "close enough" approach that should work well enough as a
default.
> So, that's enough of a problem statement (at least for now). My
> suggestion is to clean things a bit: consolidate the sectioning model
> into a single element+attribute pair, like this:
> <section> stays as is.
> <nav> becomes <section kind="nav">
> <aside> becomes <section kind="aside">
> <article> becomes <section kind="article">
> <address> becomes <section kind="address"> (and the former is defined
> in the compatibility section as equivalent to the later, because it is
> the only element of the sectioning model that already exists in
> previous versions of HTML).
>
> I'm not sure about what should be done with <header>, <footer>, and
> <hgroup>, but I hope this is a good place to discuss it ;-)
>
> Any UA would have exactly the same amount of information within the
> element, so the outlining algorithm could be perfectly implemented.
>
> 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.
> 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>?
> 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.
~TJ
