[whatwg] WA1 - The Section Header Problem

[Henri Sivonen]

On Nov 19, 2004, at 16:43, Matthew Raymond wrote:
> Henri Sivonen wrote:
>> You can come up with two different outlines for the same markup. 
>> Therefore, the suggested markup is inherently ambiguous and the 
>> inherent ambiguity needs to be explicitly disambiguated in the spec. 
>> Starting with something that is inherently ambiguous and needs some 
>> significant disambiguation prose and examples is a bad idea, IMO.
>
>    So you'd like to define header elements as having no structural 
> meaning when within a <section> element?

I'd rather have only one heading model per markup language. If 
backwards compatibility was not at stake, I'd prefer the h-section 
model over the h1...h6 model. I think allowing a mixture of the two is 
worse than picking either one. Since WHAT WG cannot eradicate h1...h6, 
that means adding h-section would be trouble.

>> Directly?
>> Let's suppose I have this document template that contains a top-level 
>> heading "Blog Posts". Then I have two documents. One has a top-level 
>> heading "Post 1" and the other has a top-level heading "Post 2". Post 
>> 1 has subheadings a and b and post 2 has subheadings A and B.
>> Now let's suppose the template and post 1 use the h-section scheme 
>> but post 2 was written using a legacy editor and uses h1 and h2.
>> What should the CMS do in order to include the posts in the template 
>> in such a way that the outline would be
>> Blog Posts
>>    Post 1
>>       a
>>       b
>>    Post 2
>>       A
>>       B
>> ?
>
> | <section>
> |  <h>Blog Posts</h>
> |  <section>
> |   <!-- Insert Post 1 here. -->
> |  </section>
> |  <!-- Insert Post 2 here. -->
> | </section>

How would verbatim insertion satisfy the goals I had for the outline 
and appearance?

>    Of course, if you want the headers to derive their levels of 
> importance from parent markup, you'd have to convert the <hn> elements 
> into <h> and <section> elements, because <hn> elements don't support 
> it. And in a <section>-less world, you'd have that problem anyway 
> unless you selected the level of the header ahead of time to 
> compensate, which would also solve the problem in the above example as 
> well.

In the h1...h6 world the inclusion template directive could specify how 
many levels the headings of the included content need to be shifted 
down.

(A DOM-based implementation, when shifting h1 down by one, would create 
a h2 node, move the attributes and children of the h1 node to the h2 
node and then replace the h1 node with the h2 node.)

>> "Post 1" and "Post 2" should have the same style. "a", "b", "A" and 
>> "B" should all have the same style. What would the CSS selectors look 
>> like?
>
>    I've already defined <h> of level "n" as having the same 
> presentation as <hn>.

How? Do you suggest the CSS selector
h2
to implicitly expand to
h2, section section h
or something like that?

> If you're shifting the header levels to compensate for the parent 
> structure in a <section> free world, it's equally easy to to the same 
> thing with <section> elements, because they have the |level| 
> attribute.

I thought the whole point of the section scheme was to be able to use 
selectors based on section element nesting without an attribute.

>>>    This markup can be easily rewritten
>> The word "easily" makes me suspicious--at least until I see the your 
>> easy DOM heading rewriting code.
>
>    I was showing how <section> could accomplish anything that the <hn> 
> elements could, and how one may want to convert <hn> markup to <h> and 
> <section> markup. I'm not suggesting this conversion happen in 
> everyone's browser.

I am not suggesting browser-side rewriting, either. My point is that 
content management systems and Web page editors need to reconcile the 
differences of the heading models when merging HTML5 documents.

>> Why not
>> <section><h>Heading 1</h><!-- first level -->
>>   <section><!-- second level but there was no h2 -->
>>     <section><h>Heading 2</h></section><!-- third level -->
>> ...
>> ?
>
>    It takes more markup, for one, and using your indent style it may 
> lead to more scrolling in a text editor when hand coding a page.

Of course three nested sections imply more markup than two. But if 
there's a heading on level three, I think there needs to be at least 
three levels.

-- 
Henri Sivonen
hsivonen at iki.fi
http://iki.fi/hsivonen/