[whatwg] WA1 - The Section Header Problem

Thu Nov 18 07:38:01 PST 2004

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

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

>>>>    I'd also like to see an optional attribute for <section> called 
>>>> |level|, which would indicate the level of importance for all the 
>>>> child <h> elements in the <section>. The idea would be that...
>>>
>>> Is there a reason for this? I mean what does the new attribute give 
>>> that is a) useful and b) not already possible with <hn> + <section>.
>>
>>    The idea is that a child section will have the default |level| of 
>> its parent plus one. Look at this example:
>>
>> | <section level="2">
>> |  <h>Level 2 Heading</h>
>> |  <section>
>> |   <h>Level 3 Heading</h>
>> |  <section>
>> | </section>
>>
>>    In this example, the second <h> element is equivalent to an <h3> 
>> heading because the |level| of its containing <section> is related to 
>> the level of its parent <section>. This establishes a recursive tree 
>> that changes the importance of all <h> headers automatically. If you 
>> use <h1>-<h6> elements, you are forced to change every header tag in 
>> order to accomplish the same effect, which is really bad if you have a 
>> lot of headers inside that section (unlike the example above, which is 
>> deliberately simple for the purpose of understanding the concept). 
> 
> Right but how useful is "importance" likely to be in the real world?  It
> seems to be a concept to which the people who write pages seem to be 
> attached (hence including it is a nice feature because they are more 
> likely to use the headings as structure correctly if they can do what 
> they think of as important within the model) but I can't really imagine 
> a UA making enough use of it to make this kind of attribute useful.

    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 remain unconvined that <h> is at-all compatible with the goal of 
>>> backward-compatibility or even particularly useful given that we have 
>>> to retain <h1> through <h6> so little conceptual simplifcation of the 
>>> language is obtained though <h>.
>>
>>    I'm not sure what you mean. In this scheme, and <h> header with a 
>> section level of one is exactly the same as <h1>, and so forth. The 
>> <h> header is a way of auto-assigning the numerical importance of an 
>> <h#> element. In theory, if you had enough structure, <h> could be 
>> equivalent to a theoretical <h25> element. 
> 
> This is one reason I sort-of prefer the model in which, inside a 
> <section> the value of n in <hn> doesn't make a difference. We don't 
> have backward-compatibility issues and we don't have artificial limits 
> on the depth of nesting.

    There are no artificial limits on the depth of the nesting. And if 
you use <h>, there are no limits on the levels of importance.