<section> and headings [was: Re: [whatwg] LABEL and radio/checkbox onclick]
James Graham
jg307 at cam.ac.uk
Thu Aug 26 03:27:44 PDT 2004
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.htm>
More information about the whatwg
mailing list