[whatwg] WA1 - The Section Header Problem

[Matthew Raymond]

James Graham wrote:
> 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

    If true, then that's a perfectly valid argument. In that case, 
perhaps we should simply drop any idea that header elements provide any 
kind of structure at all, save identifying the beginning of section 
content and identifying its importance.

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

    Sites using headers improperly weren't necessarily my concern. I was 
more concerned with "user agents" such as search engines and other web 
services that may use header content to determine the document structure.

    Granted, if those services don't really determine document structure 
using headers, we can dump any suggestion of structure related to 
headers. I'm not attached to it anyway. I merely want headers treated in 
a consistent manner regardless of whether they're inside a <section> 
element.

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

    So long as user agents don't violate the specification, they can 
render markup as they see fit. That has always been true. Therefore, it 
is not wrong for them to interpret headers as providing structure, even 
if that's not fully specified. It's simply inconvenient, which is why 
specifications need to be written with care.

    That said, it is not "wrong" either to clarify details of markup in 
a later specification, so long as it doesn't cause an undue hardship for 
user agent vendors and webmasters.

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

    Well, my model does both, but I can see how allowing the greater 
room for interpretation provided by the HTML 4.01 specification can 
cause problems regarding UA complexity and webmaster confusion.

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

    Huh? No, I was not suggesting <div> to <section> transformations. 
(Although the idea of using <div> in the place of <section> is good for 
a momentary intellectual distraction.) I was trying to indicate just how 
vague the specification really was.

 > That's not a reasonable
> requirement and will only lead to more years of poorly structured, hard 
> to navigate sites.

    Fine, then if we're doing away with vendor UA interpretations of 
headers, let's specifically define them as only having the following 
semantic meaning:

    1) Header elements contain only two kinds of header information: the 
header title and the importance of the document segment is heads.

    2) Headers can indicate the beginning of a document segment, but 
otherwise have no other structural meaning. They would not indicate the 
depth of a segment within a document structure, nor its relation to 
other segments.

    3) The value of "n" in an <hn> element, a.k.a. the importance level, 
has no affect semantic meaning related to document structure. It is 
meant only to indicate the importance of the information contained in 
the document segment that follows it.

    On a side note, I've also been considering having the |level| 
attribute of <section> automatically take the level of the first heading 
inside the <section> element, unless that heading is an <h> element.

| <section>
|  <h2>Header A</h2>
|  <section>
|   <h>Header B</h>
|  </section>
| </section>

    In the above example, "Header A" would have an importance level of 
two, and "Header B" would have the importance level of three.

    Hmm. Not sure if I like that or not. What do you think?