[whatwg] WA1 - The Section Header Problem

Thu Nov 18 04:50:39 PST 2004

Matthew Raymond wrote:

> James Graham wrote: 

>
>    The idea is that outliners should structure outlines according to 
> the structure established by the <section> elements first. Within that 
> structure, they can establish further structure based on importance, 
> but it cannot break the structure established by the <section> elements. 

Right. That sounds roughly like my proposal for a heading model.

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

I haven't entirely thought through the advantages and disadvantages of 
each approach.

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

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