[whatwg] WA1 - The Section Header Problem

[James Graham]

Matthew Raymond wrote:

> James Graham wrote:
>
>> clearly defined relationship between <hn> and <section> will break 
>> anything.
>
>
>    Are you kidding me? Look at this:
>
> | <section>
> |  <h1>Header A</h1>
> |  <section>
> |   <h2>Header B</h2>
> |   <h1>Header C</h1>
> |  </section>
> | </section>
>
>    If you only look at the the headers, you have this structure:
>
> Header A
> +- Header B
> Header C
>
>    This violates the structure of the <section> elements. Therefore, 
> the example above can only have the following structure:
>
> Header A
> |- Header B
> +- Header C
>
>    Now, let's change that example a bit:
>
> | <section>
> |  <h1>Header A</h1>
> |  <section>
> |   <h1>Header B</h1>
> |   <h2>Header C</h2>
> |  </section>
> | </section>
>
>    According to the header information alone, the structure could look 
> like this:
>
> Header A
> Header B
> +- Header C
>
>    This violates the <section> structure, which looks like this:
>
> Header A
> |- Header B
> +- Header C
>
>    What my model lets user agents do is interpret the headers in a way 
> that preserves the existing structure, but can also append to it, so 
> the second markup example above could, if the UA vendor so chooses, 
> yield this structure:
>
> Header A
> +- Header B
>    +- Header C

I don't want the UA vendors to have a choice. I (as such a 'vendor' 
myself) want a clearly defined way to get a structure from a document. 
Not a choice of multiple ways. If people are adding <section>s to their 
document, it is /their responsibility/ to ensure that the new <section>s 
do not disrupt the existing structure of the document. If this is 
clearly defined in the spec, they can do that. If it's not defined, they 
can't. You can't argue that, because the HTML 4 spec is vauge, we have 
to be vauge to maintain exact compatibility with all existing UAs 
because a) few UAs exist that make any use of headings and, in 
particular, few use it for outlines and b) because of a) few sites use 
headings in a logical and consistent way wrt structure. It's much much 
better to solve the problem one way or another than to perpetuate it.

>
>>> > If they don't know that why have any spec at all?
>>>
>>>    HTML 4.01, with regards to headers, has virtually no 
>>> specification. this is the entire specification of it:
>>>
>>> "Heading information may be used by user agents, for example, to 
>>> construct a table of contents for a document automatically."
>>
>>
>> I'm aware of the limitations of HTML 4 on this issue. That doesn't 
>> mean we should do a bunch of stuff to make headings work properly and 
>> then throw away that progress at the last minute "because HTML 4 got 
>> this wrong".
>
>
>    You're missing the point. HTML doesn't even define what "right" and 
> "wrong" are. 

"wrong" in the sense of "not specified" rather than any definition of 
right and wrong uses.

>    If you mean that it preserves the HTML4 heading model as much as 
> possible for backwards compatibility, then yes, it does.

The problem is a) the HTML 4 heading model is vauge and b) authors abuse 
the model because it is vauge. We need to maintain semantic 
compatibility (HTML 5 headings should be HTML 4 headings) and we need to 
have a robust heading model. We do not need to reproduce the outline 
derived by every heading-aware UA from every existing site on the web 
under the transformation <div>-><section>. That's not a reasonable 
requirement and will only lead to more years of poorly structured, hard 
to navigate sites.