[whatwg] Yet another <section> <h> and <hn> idea.

[dolphinling]

Matthew Raymond wrote:
> dolphinling wrote:
> 
>> With respect to <section>, <h>, and <hn>, I would suggest the following:
>>
>> For any <hn>, if n is less than or equal to the number of sections it 
>> is nested inside, it is semantically equivelant to <h>;
>>
>> <section>
>>   <h1>1st level header</h1>
>>   <p>content</p>
>> </section>
>>
>> <section>
>>   <h>1st level header</h>
>>   <p>content</p>
>>   <section>
>>     <h2>2nd level header</h2>
>>     <p>content</p>
>>   </section>
>>   <section>
>>     <h1>_Also_ 2nd level header</h1>
>>     <p>content</p>
>>   </section>
>> </section>
> 
> 
>    If there is any difference in presentation or the level of 
> importance, then this contradicts the HTML 4.01 specification when the 
> header element is a child of a <section>. If you assume your <h> 
> elements are set up the way mine are, then this is the case, since in my 
> model, <h> elements on level "n" are semantically and presentationally 
> identical to <hn>. It looks to me like you're using <section> to enforce 
> a minimum importance level, and possibly to alter presentation. If so, I 
> oppose this.
> 

Yes, it is enforcing a minumum importance level; the idea is that if 
something's nested inside 3 or 4 sections, it's probably not as 
important as something that's in only one section. Few people would 
deliberately stick an <h1> inside a whole series of <section>s, and when 
they do it's probably the fault of their CMS.

I'm not sure where this contradicts HTML 4.01, can you quote the part?

>> Around any hn with n greater than the number of sections, there are 
>> implied semantic sections. These implied sections end at the end of 
>> the containing explicit section (or other containing block) or at the 
>> start of the next hn with an equal or lower value of n;
>>
>> <section>
>>   <h1>1st level header</h1>
>>   <p>content</p>
>>   <!-- section -->
>>     <h2>2nd level header</h2>
>>     <p>content</p>
>>   <!-- /section -->
>> </section>
> 
> 
>    Let's add a <section>, then:
> 
> | <section>
> |  <section>
> |   <h1>2nd level header</h1>
> |   <p>content</p>
> |  <!-- /section -->
> |  <!-- section -->
> |   <h2>2nd level header</h2>
> |   <p>content</p>
> |  </section>
> | </section>
> 
>    Just by having them nested in an extra <section> makes the second 
> implied section a sibling instead of a parent. This means that once you 
> get to level six, <hn> = <h> for all values of "n", and the legacy 
> header system becomes useless.
> 
>    Now, in theory, most documents won't use more than six levels, but if 
> you make that argument, you must consider two things. The first is that, 
> if you accept that levels greater than six are of no significance, it 
> makes <section> functionally redundant because <hn> can automatically 
> create the sections. (Although you could argue that the automatic 
> importance system justifies <section>, if you wanted to.) The second 
> thing to consider is that, when using <section> elements, you loose a 
> legacy header element for every level you go up.
> 

The legacy header system was useless after six "sections" anyway, and 
"lost an element" after each was used.

>    Okay, then what does this do?:
> 
> | <section>
> |   <h1>header</h1>
> |   <p>content</p>
> |   <h3>header</h3>
> |   <p>content</p>
> |   <h2>header</h2>
> |   <p>content</p>
> | </section>
> 
>    If you assume the implied sections are actually hidden <section> 
> elements, you get this:
> 
> | <section>
> |   <h1>1st level header</h1>
> |   <p>content</p>
> |   <!-- section -->
> |     <!-- section -->
> |       <h3>3rd level header</h3>
> |       <p>content</p>
> |     <!-- /section -->
> |     <!-- section -->
> |       <h2>3rd level header</h2>
> |       <p>content</p>
> |     <!-- /section -->
> |   <!-- /section -->
> | </section>
> 
>    However, logically, we should instead see this structure:
> 
> | <section>
> |   <h1>1st level header</h1>
> |   <p>content</p>
> |   <!-- section -->
> |     <!-- section -->
> |       <h3>3rd level header</h3>
> |       <p>content</p>
> |     <!-- /section -->
> |   <!-- /section -->
> |   <!-- section -->
> |     <h2>2nd level header</h2>
> |     <p>content</p>
> |   <!-- /section -->
> | </section>
> 

No. Notice that I said "These implied sections end at the end of the 
containing explicit section (or other containing block) or at the start 
of the next hn with an equal or lower value of n", so the the correct 
interpretation is the third one, that you said you'd expect.

>    In my model, such confusion doesn't exist. The headers don't 
> communicate structural depth. They only communicate the importance of a 
> section. Therefore, they always have the same semantic meaning and 
> presentation, regardless of how many <section> elements they're nested in.
> 
>> For a legacy document:
>>
>> <!-- section -->
>>   <h1>1st level header</h1>
>>   <p>content</p>
>>   <!-- section -->
>>     <h2>2nd level header</h2>
>>     <p>content</p>
>>     <!-- section -->
>>       <h3>3rd level header</h3>
>>       <p>content</p>
>>     <!-- end section -->
>>   <!-- end section -->
>> <!-- /section -->
> 
> 
>    My model would look like this:
> 
> | <!-- section level="1" -->
> |   <h1>1st level header</h1>
> |   <p>content</p>
> | <!-- /section -->
> | <!-- section level="2" -->
> |   <h2>2nd level header</h2>
> |   <p>content</p>
> | <!-- /section -->
> | <!-- section level="3" -->
> |   <h3>3rd level header</h3>
> |   <p>content</p>
> | <!-- /section -->
> 
>    In the above, the header level refers to the importance of the 
> section and not its structural depth in an outline.
> 

Yet if someone writes

<h1>heading</h1>
<p>content</p>
<h2>heading</h2>
<p>content</p>
<h3>heading</h3>
<p>content</p>

...they probably mean for it to be sections, subsections, and 
subsubsections.

>> A more complex example, with h and hn chosen off the top of my head:
>>
>> <section>
>>   <h>1st level header</h>
>>   <p>content</p>
>>   <!-- section -->
>>     <!-- section -->
>>       <h3>3rd level header</h3>
>>       <p>content</p>
>>     <!-- /section -->
>>     <h2>2nd level header</h2>
>>     <p>content</p>
>>   <!-- /section -->
>>   <section>
>>     <h1>2nd level header</h1>
>>     <p>content</p>
>>   <!-- /section -->
>>   <!-- section -->     <!-- This implied split I'm not sure about, but
>>                             it seems to be best [1] [2] -->
>>     <h2>2nd level header</h2>
>>     <p>content</p>
>>     <section>
>>       <h>3rd level header</h>
>>       <p>content</p>
>>       <section>
>>         <!-- section -->
>>           <!-- section -->
>>             <h6>6th level header</h6>
>>             <p>content</p>
>>           <!-- /section -->
>>         <!-- /section -->
>>       <!-- /section --> <!-- Another implied split -->
>>       <!-- section -->
>>         <h>4th level header</h>
>>         <p>content</p>
>>       </section>
>>     </section>
>>   </section>
>> </section>
> 
> 
>    Strip out the formatting and comments for a moment, and just leaving 
> indenting to indicate the DOM structure:
> 
> | <section>
> |   <h>header</h>
> |   <p>content</p>
> |   <h3>header</h3>
> |   <p>content</p>
> |   <h2>header</h2>
> |   <p>content</p>
> |   <section>
> |     <h1>header</h1>
> |     <p>content</p>
> |     <h2>header</h2>
> |     <p>content</p>
> |     <section>
> |       <h>header</h>
> |       <p>content</p>
> |       <section>
> |         <h6>header</h6>
> |         <p>content</p>
> |         <h>header</h>
> |         <p>content</p>
> |       </section>
> |     </section>
> |   </section>
> | </section>
> 
>    There's no easy way to determine what this is supposed to look like 
> without the formatting and indentation you added. A webmaster would have 
> to analyze the HTML to determine what level the markup is at.
> 

And when I do analyze it (the raw html), I think this system works quite 
well in determining what the webmaster meant. If they specify an h2, 
then it's a second level heading--unless it's already nested in three 
sections, in which case it makes no sense for it to be a second level 
heading.

>    What's worse is that you've created a system where
> 

Unfinished thought?


>> [2] ...Or it could just be declared invalid, and there could be a 
>> limit of one header per section.
> 
> 
>    I have been persuaded that the reaction to that would be rather 
> negative, and I would agree that in certain circumstances it would be a 
> real pain, especially when you have a lot of sibling sections in a row 
> without subsections.
> 

Hmm. Where are the arguements for that?

>> Hmm... have to think about it, but it might work. (Too lazy to revise 
>> my big long example, though)
> 
> 
>    The more complicated we make the rules with regards to implied 
> sections, the more likely we'll have the following problems:
> 
> a) Webmasters will get confused and create markup that doesn't have the 
> structure or presentation they desire.
> 
> b) The UA programmers will overlook certain cases, resulting in the 
> creation of outlines that violate the specification.
> 
> c) There will be specific cases where it may be impossible for 
> webmasters and vendors to determine how an outline should be generated, 
> resulting in intentional differences in the way markup is written for 
> these cases and how UAs handle it.
> 

Agreed. Hopefully the 2 rules stated in this idea aren't too complicated ;-)