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

[Eduard Pascual]

On Sat, May 1, 2010 at 3:56 AM, Anne van Kesteren <annevk at opera.com> wrote:
> On Sat, 01 May 2010 10:42:03 +0900, James Robinson <jamesr at google.com>
> wrote:
>>
>> Is this sort of reply really necessary?  I have not been following the
>> surrounding discussion, but this email showed up as a new thread in my
>> mail client.  Based on this tone, I now have no desire to catch up on the
>> rest of the discussion.
>
> My bad. It's just that we've been over this discussion like a gazillion
> times
Really? Then I must have missed something.
Please keep in mind that this was *not* another HTML5 vs. XHTML2
thread; but a discussion on the issues triggered by HTML5's approach
(styling, compatibility, room for future evolution, spec-bloating).
The (partial) comparison with XHTML2 was only intended to help
highlighting the root of these issues.
Anyway, I'm working on a formal proposal that will describe the
problems in terms of use-cases and examples, and my suggested solution
in the form of (mostly) spec-ready text, accompanied with rationales
for each proposed change to the current draft, but *without* any
mention to XHTML2 (it could properly serve as an example to discuss
some concepts in the abstract, but it has no place in a more formal
proposal).

> and it would be nice that if we were to have it again at least we
> started with the correct facts.
Then let's start by taking *correct* facts. My original statement
about XHTML2's sectioning model was indeed a simplification, but the
goal of that was highlighting the best aspects of their approach, not
to degrade this into yet another XHTML2 vs. HTML5 discussion. On the
other hand, your statement:

> Which are that XHTML2 had exactly the same
> design as HTML5 has now
Is a blatant lie. The key difference between XHTML2's and HTML5's
approaches to sectioning (and the one my suggestion was based on) is
that XHTML2 defines *a single element* to mark up sections
(unsurprisingly named <section>), while HTML5 defines several
(<section>, <nav>, <article>, and so on). This is the root of the
issues I'm trying to get addressed; and it seems a lot saner to solve
them all at the root than to define some kind of esoteric workaround
separately for each.

> but did not solve the problem of mixing h1-h6 with
> section/h. HTML5 did.
I applaud HTML5's overall approach to how mixed implicit and explicit
sectioning will be handled. It's an amazing example of the good work
done in HTML5 on the field of compatibility. But the issues here are
about how explicit sectioning is implemented. It is a new feature that
introduces some unneeded issues, instead of leveraging existing
technologies (including pre-5 X/HTML, CSS, and so on). In other words,
while HTML5's approach to heading handling is good, sound, and
elegant, the approach to sectioning is bloated, ugly, and
revolutionary rather than evolutionary.

On a side note, I'd like to highlight a detail that might have gone
unnoticed. There are, IMO, two kinds (or rather, perspectives) of
"backwards compatibility":
The one you'll probably be more familiar with is the UA perspective:
new UAs must be able to handle old content: if a user's favorite sites
break on a new browser, the user won't want to use that browser.
Simetrically, there is a content authoring perspective: new content
needs to handle old UAs: if a new site or document breaks on the
user's favorite browser, the user won't use that content, even if they
want to.
For HTML5 (or any other "upgrade" to a web-related technology) to
succeed, both perspectives need to be observed. *This* is where XHTML2
most blatantly failed: it tried to avoid the UA perspective through
the assumption of mode-switching, and the features for the authoring
perspective (keeping elements that it was obsoleting, such as <h1-6>,
<img>, <a>, etc) didn't solve anything at all (due to the
mode-switching assumption).
HTML5 has done a great work to address the UA perspective of
compatibility; but there are some aspects, like the sectioning model,
that trigger serious issues on the authoring perspective.

Regards,
Eduard Pascual