- From: Matthew Raymond <mattraymond@earthlink.net>
- Date: Thu, 25 Nov 2004 13:24:16 -0500
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.
Received on Thursday, 25 November 2004 10:24:16 UTC