<section> and headings [was: Re: [whatwg] LABEL and radio/checkbox onclick]

[James Graham]

Ian Hickson wrote:

>On Wed, 25 Aug 2004, Matthew Raymond wrote:
>  
>
>>If anything, headings should work like this:
>>
>><section>
>>  <heading>Header 1</heading>
>>  <p>Content for 1.</p>
>>  <section>
>>    <heading>Header 1a</heading>
>>    <p>Content for 1a.</p>
>>  </section>
>>  <section>
>>    <heading>Header 1b</heading>
>>    <p>Content for 1b.</p>
>>  </section>
>></section>
>>    
>>
>
>WA1 defines something like this, re-using <h1> for the heading element.
>  
>
Instinctivley I dislike this proposal but I'm not sure I can easilly 
explain why.

My first objection is that changing the meaning of <h1> isn't backward 
compatible for assistive technologies. True, authors can work around 
this using h2-6 elements but the spec states that these do not have the 
same behavior as h1 when they are the children of a section element. 
This makes it difficult to create documents which use the new features 
and degrade gracefully. I also think that using <h1> as a general 
purpose heading is really really ugly. But that's not much of an objection.

It's also not clear how a structure like:
<div class="heading">
<h1>Page title</h1>
</div>
<div class="content">
<h2>Content title</h2>
</div>
would be represented in the new scheme. Reaplacing the <div>s with 
<section>s and the <h2> with <h1> produces a different structure (page 
title and content title are equally important).

The new scheme makes it very easy to create illogical page structures. 
For example, it's not clear how the following should work:
<section>
<h1>Title</h1>
<section>
<h1>Subheading</h1>
<section>
<h2>Second subheading</h2>
</section>
</section>
</section>

On the other hand, there is some merit to a situation in which <section> 
creates structure and the choice of n in <h{n}> denotes the 'importance' 
of the heading relative to the content of the page (so, for example, 
search bots give lower weight to <h6> elements than <h1> elements 
regardless of the nesting). I'm not sure how useful this would be, 
especially given that <menu> exists for marking up navigation but many 
authors already use the heading elements in this way and will presumably 
continue to do so. If this is the route taken, it needs to be clear that 
only the <section> elements create outline structure, not the <h{n}> 
elements, which isn't strictly HTML4 compatible but is consistent with 
the way many actual sites work.

Another possibility is to use <h{n}> to denote levels of heading within 
a section so that:
<section>
<h1>Page Heading</h1>
<section>
<h1>Article Title</h1>
<h2>Article subtitle</h2>
</section>
</section>

Has the semantics implied by the element contents and, in particular, an 
outline view of the document does not show the <h2> element as a child 
of the preceeding <h1> element. However this, again creates backward 
compatibility problems since existing software will not recognise the 
new semantics and act accordingly. This is nice because it makes the use 
of <h1> to denote a general heading less ugly but it's really a radical 
change from HTML 4.

There is more discussion of the use of the html 4 heading elements in 
[1] . In general, I think that explicit markup for document sections is 
good (although I would like to see more single-purpose elements such as 
<header> or <footer> to provide addiational semantics for UAs - the 
ability to seperate out sitewide elements from page-specific content is, 
in my opinion, particularly important) but I think we need to carefully 
consider the way the old and new heading styles will interact, 
particularly since backward compatibility is important.

[1] http://jogin.com/weblog/archives/2004/07/19/hierarchy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20040826/8611f5fd/attachment-0001.htm>