[whatwg] WA1 - The Section Header Problem

[Matthew Raymond]

James Graham wrote:
> Matthew Raymond wrote:
[Snip!]
>>    Note that the structure example you use above is the semantic 
>> document structure I was talking about earlier. Importance need not 
>> equal structure. User agents simply have the option of interpreting it 
>> as such when it does not conflict directly with the semantic document 
>> structure. 
> 
> Giving UAs options tends to lead to non-interoperable solutions.

    Why do outlines build entirely by user agents have to interoperate? 
Furthermore, I'm not giving the user agents anything they didn't already 
have. I'm simply defining a way vendors can continue using <h1>-<h6> as 
they were using it before without breaking the structure created by 
<section> elements.

>> Your "MyNews" example is a perfectly valid in my model.
>>
>>    I would point out, however, that since my model does not explicitly 
>> assign semantic document structure to <h> and <h1>-<h6> elements and 
>> in fact explicitly defines them as NOT having any defined document 
>> structure semantics (although vendors are free to interpret them as 
>> they wish), there is no vendor requirement to structure an outline 
>> with "header 3" as the child of "header 2". It is simply a decision 
>> left up to the vendor. 
> 
> So how does an author know how some random browser will interpret their 
> document?

    For <section> elements, that's clearly defined, since I define 
<section> elements as having over any structural scheme the vendor may 
wish to introduce regarding <h1>-<h6> elements.

    With regard to header elements, the only thing that's changed is 
that  headers overridden by <section> markup.

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

    It doesn't even say HOW to create an outline. So anything we put 
into Web Apps 1.0 is going to be better than what they have in HTML 
4.01. Heck, they don't even say that you should use the importance level 
to structure the outline (although it's a reasonable conclusion).

>>> I haven't entirely thought through the advantages and disadvantages 
>>> of each approach.
>>
>>    My approach allows vendors to continue building outlines using only 
>> header elements while making it clear that <section> is the only 
>> element that has defined structural semantics. 
> 
> That doesn't mean anything to me. If the spec allows outlines from <hn> 
> what's the point of saying 'but they don't offer "structural 
> semantics"'?

    Allowing a "table of contents" as a valid use of header information 
is a long way from describing how to construct an outline using <hn> 
elements. Besides, a table of contents can be flat (though, obviously, 
that's not very useful).

> What do you mean by "structual semantics" other than the 
> ability of a UA to infer an document structure, of which an outline is a 
> representation.  The whole concept of semantics is only useful insofar as
> it allows UAs to do something and in the case of structure the obvious 
> thing for a UA to do is present the structure. What's the point of 
> speccing up a robust structural model if we don't specify how one can 
> infer structure from the model? You seem to be sidestepping the problem 
> rather than solving it.

    I'm not sure what you're getting at here. The <hn> elements, as 
defined in HTML 4.01, don't have any semantic meaning related to 
structure. In fact, there is no definition in the specification of how 
to associate headers with content or even how they relate to each other. 
All I'm attempting to do is say that if vendors decide to make up their 
own set of rules regarding how to use that header information, those 
rules can't violate the structure created by the <section> elements.

>>    In case I didn't make it clear, it is intended for a <h> element 
>> with an importance of one to have the PRESENTATION of a <h1> element, 
>> and so forth. Therefore, as the level <h> inherits from <section> 
>> changes, so does the presentation of <h>. Importance may not matter 
>> much in the real world, but styling does.
>>
>>    In theory, this could problems with CSS, but I think that's easily 
>> overcome like this:
>>
>>    h1, section[level=1] h { /* H1 styling */ }
>>    section[level=25] h { /* H25 styling */ } 
> 
> I tend to believe that we should just have (default) style based on the 
> choice of h1 through h6, as at the moment. That's not what's in the 
> current spec but it has certian advantages - fewer verbose selectors, 
> better backward compatibility, etc. It also has some disadvantages 
> (documents using <section> and a single <hn> won't look as good in a 
> HTML5 browser as in a HTML4 browser).

    I don't see a point to this limitation. In my model, an <hn> element 
renders the same regardless of where it's used, unless it's used as a 
tab label, and <h> = <h[level]> with regards to both semantics and 
presentation. Are you referring to levels greater than six? We can just 
make the default presentation for a header with a level greater than six 
the same as <h6>. Actually, correct me if I'm wrong, but would this work 
for that:

|   h1, section[level=1] h { /* H1 styling */ }
|   h2, section[level=2] h { /* H2 styling */ }
|   h3, section[level=3] h { /* H3 styling */ }
|   h4, section[level=4] h { /* H4 styling */ }
|   h5, section[level=5] h { /* H5 styling */ }
|   h6, section[level=6] h { /* H6 styling */ }

    Well, in theory, some jerk could do <section level="7">, I suppose. 
I wish you could do this in CSS:

|   h6, section[level>=6] h { /* H6 styling */ }

    At any rate, webmasters should then be free to override as they see 
fit using CSS. They'll be able to anyway. It's simply a matter of it 
actually being HARDER for them to accomplish the same thing in your system:

| section > section > section > section > section > section > section >
| section > section > section > section > section > section > section >
| section > section > section > section > section > section > section >
| section > section > section > section > h1 { /* H25 styling */ }

    ...As opposed to just...

| section[level=25] h { /* H25 styling */ }

    Who does your limitation benefit?