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

[Matthew Raymond]

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.

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

> <section>
>   <h1>1st level header</h1>
>   <p>content</p>
>   <!-- section -->
>     <!-- section -->
>       <h3>3rd level header</h3>
>       <p>content</p>
>     <!-- /section -->
>   <!-- /section -->
> </section>

    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>

    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.

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

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

> [1] This also answers the question of what happens if you have two 
> headers in a section. The possibilities are assume the second one is a 
> subsection, assume they're both subsections, or assume they're both 
> normal sections, with an implied split. I think the implied split is 
> best...

    I agree. I think whenever you have a section with multiple headers 
on the same structural level, the section should be split into a series 
of sibling headers on the same level.

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

 > Can you have content before the header, though?

    There should probably be an assumed section before the header in 
that case, yes.

> How about subsections before the header?

    I guess so, but it should be considered bad form.

 > And what about implied subsections?

    For the sake of avoiding confusion about section depth inside 
complex document structures, these should be avoided.

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