[whatwg] WA1 - The Section Header Problem

Henri Sivonen wrote:
> On Nov 18, 2004, at 17:06, Matthew Raymond wrote:
>> Henri Sivonen wrote:
>>> On Nov 17, 2004, at 20:13, Matthew Raymond wrote:
>>>> a outline based on semantic document structure would yield #1, 
>>>> whereas an outline based on importance would yield #2
>>>
>>> Doesn't look good.
>>
>>    Could you be more specific?
> 
> 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? Only problem I see is what 
happens if they take a document or an extremely large block of markup 
and put it inside a <section>. Does all the structure provide by header 
elements suddenly drop out of existence?

>>> How should a CMS combine documents some of which used <h1>...<h6> and 
>>> others <h> & <section>?
>>
>>    The header elements (<h>, <h1>-<h6>) contain header information and 
>> importance. The <section> element establishes semantic document 
>> structure. They can be combined directly.
> 
> 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>

    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.

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

>> It's only a question of whether the user agent vendors choose to use 
>> the importance level to add further structure to the outline. Here's 
>> an example:
>>
>> | <h1>Heading 1</h1>
>> | <h3>Heading 2</h3>
> 
> ...
> 
>>    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. That's why I said "rewritten" instead of 
"converted". Perhaps I wasn't being clear about that.

>> using <section> elements to add semantic structure:
> 
> Why does "semantic structure" need to be added? Doesn't h1...h6 form a 
> "semantic structure"?
> 
>> | <section><h>Heading 1</h>
>> |  <section><h3>Heading 2</h3></section>

    Actually, based on the example in the HTML 4.01 specification, you 
could make a better argument that the <div> element has semantic 
structure than you could for header elements. There is no explicit 
language that says header elements provide structure, although there is 
some suggestion in the language and examples that they do.

> 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. It's 
also harder to read and follow, and it fails to recognize that the 
section structure has priority, so there's only two structural levels in 
the part of my example you quoted, where as yours has three.

    Both examples are really bad practice, though.

Received on Friday, 19 November 2004 06:43:09 UTC