[whatwg] The real issue with HTML5's sectioning model

[Ian Hickson]

On Fri, 30 Apr 2010, Eduard Pascual wrote:
>
> Basically, most of the issues with headings boil down to a single fact: 
> the sectioning model is (probably needlessly) over-bloated. [...]
> 
> And now, in HTML5, not only have <h1-6> been kept, but a plethora of new 
> elements: <section>, <nav>, <aside>, <article>, <hgroup>, <header>, 
> <footer>; and it even messes with <address>. The justifications for 
> <h1-6> (backwards compatibility, better transition, etc) are quite 
> sound; but the 7 new elements more than double the mess.

Another way to look at it is that the new elements simplify the markup 
authors have to use. Most of the new elements correspond to very commonly 
used class names.


> 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.

Not necessarily. We can fix Selectors to make this much shorter, in a way 
equivalent to what the spec says, for example using a pseudo-class like 
Mozilla's :-moz-any().


> On the case of a mixed approach, it is *absolutely* impossible to get 
> the headings properly matched with current selector technology.

Indeed. We can always improve that technology if that's a problem, though.

In practice it's not clear what the needs are here. I don't see most 
authors needing to select both <section>/<h1> and <h2>/<h3> etc with the 
styles interacting. Do you have any concrete use cases in mind where this 
is a problem?


> 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 ;-)

I don't understand what problem this solves. All its seems to do is make 
the language more verbose.


> 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.

If you want to target older UAs, you can just use <h2>-<h6> with 
<section>, instead of relying on the automatic sizing of <h1>.


> 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.

Isn't that a negative, rather than a positive?


> 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.

Given how often we add new sectioning elements, I don't think that's 
something to worry about optimising for. At least not in favour of a 
simple language.


On Sat, 1 May 2010, Eduard Pascual wrote:
>
> It's not a matter of saving a few characters here and there.

Well, that was more or less the reasoning behind having these elements in 
the first place, so it is a _bit_ about that. :-)


> The very purpose of <section> and its friends is to implement explicit 
> sectioning on HTML, so there is no need to rely on error-prone, 
> painful-to-maintain implicit <h1-6>-based sectioning. However, the spec 
> recommends still using <h1-6> anyway, to ensure backwards compatibility. 
> The compatibility goal itself is a quite good thing but, on this case, 
> it not only destroys the primary purpose of the feature, but makes 
> things even worse: having to state the same thing (the sectioning of the 
> document) twice (with the sectioning elements and with the numbered 
> headings) doubles the chance to introduce errors, and doubles the effort 
> required to maintain the content.

Yeah, but it's only an issue during the transition period.


> In summary: the <section>+attribute approach solves all the issues the
> current model solves

Not all of them; the main problem was that using <div class=""> made ugly 
documents that are a mess to maintain.


> provides better (backward and forward) compatibility

It provides no better backwards compatibility unless you are relying on 
CSS, and the forward-compatibility in this case is of minimal concern 
given the timescales we're talking about here.


> allows better leveraging existing technologies (such as CSS) to work 
> with it

Is that a goal? It seems that we should improve the platform as a whole, 
not design features in HTML based on CSS' current limitations.


> would be simpler to specify and to implement

It wouldn't be simpler to specify, since the status quo is already 
specified, so would require no work. :-)

The implementation burden also seems minimal in either case.


> and easier for authors to learn

That I'm not convinced of at all.


> and solves some use cases the current model does not.

It's not clear that those use cases are real problems, though.


On Fri, 30 Apr 2010, Eduard Pascual wrote:
>
> 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.

That doesn't follow. It just means both either be appropriate.


> 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>.

Just <aside>...</aside> or <nav>...</nav> works too.


> 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?).

I think you may be overthinking this. :-)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'