[whatwg] WA1 - The Section Header Problem

Thu Nov 18 08:02:27 PST 2004

Matthew Raymond wrote:

> James Graham wrote:
>
>> Matthew Raymond wrote:
>>
>>>    Take this example:
>>>
>>> | <section>
>>> |  <h1>heading 1</h1>
>>> |  <section>
>>> |   <h2>heading 2</h2>
>>> |   <h3>heading 3</h3>
>>> |  </section>
>>> | </section>
>>>
>>>    The structure in an outline would be like this:
>>>
>>> heading 1
>>> +- heading 2
>>>    +- heading 3 
>>
>>
>> There is a second possibility here which is that we use a model in 
>> which, as a child of a <section> the value of n is ignored so the 
>> tree becomes:
>>
>> heading 1
>> +-heading 2
>> +-heading 3
>>
>> This is nice in that it's conceptually simpler (except that <body> 
>> has to be special cased for backward compatibility) and allows one to 
>> do things like:
>>
>> <h1>MyNews</h1>
>> <section id="currentStories">
>> <h2>Main Story</h2>
>> <h3>Lesser story</h3>
>> </section>
>
>
>    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.

> 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? If they don't know that why have any spec at all?

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

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