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

[Ian Hickson]

On Thu, 26 Aug 2004, James Graham wrote:
> > > 
> > > <section>
> > >  <heading>Header 1</heading>
> > >  <p>Content for 1.</p>
> > >  <section>
> > >    <heading>Header 1a</heading>
> > >    <p>Content for 1a.</p>
> > > ...
> > 
> > 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.

The way it is defined now, _any_ header element can be used, specifically 
to allow it to be backwards compatible with existing UAs. The <h1> is 
defined as being the only element that automatically gets restyled to 
match the <section> nesting, though.


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

Right.


> This makes it difficult to create documents which use the new features 
> and degrade gracefully.

Well, I'm not really sure how else to do it. Do you have any suggesitons?


> I also think that using <h1> as a general purpose heading is really 
> really ugly. But that's not much of an objection.

I don't disagree. But it is backwards compatible.


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

It would be:

   <h1>Page title</h1>
   <section>
    <h1>Content title</h1>
   </section>

...or, possibly:

   <div class="heading">
    <h1>Page title</h1>
   </div>
   <section>
    <h1>Content title</h1>
   </section>

...or, maybe (this is just thinking out loud now, the spec doesn't allow 
this yet):

   <heading>
    <h1>Page title</h1>
   </heading>
   <section>
    <h1>Content title</h1>
   </section>

(For backwards compatibility, the second <h1> in all the above can be 
written as <h2> without changing the WA1-defined semantics.)


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

What is unclear about it?

It is semantically exactly equivalent to today's:

   <h1>Title</h1>
   <h2>Subheading</h2>
   <h3>Second subheading</h3>

...or to the XHTML2:

   <section>
    <h>Title</h>
    <section>
     <h>Subheading</h>
     <section>
      <h>Second subheading</h>
     </section>
    </section>
   </section>

Admittedly, the styling would look different (and would look wrong). But 
that's becaue it uses a mixture of WA1-only markup and WA1-with-graceful- 
fallback markup.


> 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 considered this, but making <h1>-<h6> have _different_ semantics than 
each other in <section> elements basically makes it impossible to do the 
whole backwards-compatibility trick.


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

Yeah, <header> and <footer> or similar elements are almost certainly going 
to be defined at some point, along with <content> (for the main body of 
the page), <entry> or <post> or <article> to refer to a unit of text 
bigger than a section but smaller than a page, <sidebar> to mean a, well, 
side bar, <note> to mean a note... and so forth. Suggestions welcome. 
We'll probably keep it to a minimum though. The idea is just to relieve 
the most common pseudo-semantic uses of <div>.


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

Interesting article. I'll look at this in more detail at some point.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'