W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2004

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

From: Ian Hickson <ian@hixie.ch>
Date: Fri, 12 Nov 2004 10:17:41 +0000 (UTC)
Message-ID: <Pine.LNX.4.61.0411121010000.8631@dhalsim.dreamhost.com>
On Sun, 29 Aug 2004, James Graham wrote:
> > 
> > > 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 principle, I think I see the point. In practice the way that many 
> authors seem to use the existing <h1> to <h6> elements is broadly 
> compatible with this principle (iirc the HTML 4 spec states that the 
> different elements denote the "importance" of different heading levels. 
> Authors tend to ignore the following text stating that headings can be 
> used to create a document outline and mark e.g. headings in their 
> sidebar as being lower importance than headings in the main document 
> even if, structurally, they're at the same depth. This makes creating a 
> useful outline impossible but does mean that some search bots give 
> higher weight to more important content.).
> 
> From my limited observation of author practice, the most
> backward/author-compatible heading model I can imagine is:
> 
> The semantics of h1...h6 elements that are the first h1...h6 child of a 
> <section> element is the heading for that section. Subsequent h1...h6 
> elements in the same <section> are subheadings (in the sense of sub 
> titles e.g. "A New Hope"  in "Star Wars - A New Hope") of that section. 
> h1....h6 elements have decreasing levels of importance with h1 being the 
> most important and h6 the least. Higher level headings tags should be 
> used to mark the headings most important to the page content as a whole 
> and low level headings should be used to mark less significant 
> divisions.

That would work except that if we do this we have to abandon the idea of 
having <h1> be automatically sized to fit the nesting level, and 
<h2>..<h6> left with existing renderings for compatibility, since 
otherwise you'll end up with "subheadings" that are twice as large as the 
section headings.

I think it's very important that authors be able to keep using their 
existing documents, just throwing in <section> elements where they want 
them, without all the styles changing.


> I've noticed sites that use the "a second heading in a <div> is a 
> subheading" paradigm- Off the top of my head, both Eric Meyer 
> (meyerweb.com) and Dave Shea (mezzoblue.com) do this in their weblogs. 

Yeah, the <header> element currently in the draft would be the way to do 
that. It lets you do slightly more, as well, such as:

   <header>
    <p>Welcome to...</p>
    <h1>Voidwars!</h1>
   </header>

...or including author information in the <header> (see the draft for 
another example).


> The most obvious use case I have in mind would be a UA hiding certian 
> sections of the page so that the content was easilly accessible. It 
> might therefore be goood to have a general purpose <chrome> element to 
> denote a section of the page other than the main content. One could then 
> subdivide using an attribute (<chrome type="header"> <chrome 
> type="footer"> and so on). This is, at least, easilly extendable and 
> allows a browser to use CSS like "chrome {display:none;}". For 
> document-type pages, it might be good to have <pullout> or something to 
> define a box of content that related to a part of the article but was 
> not in the main flow. This would be superior to just using <section> or 
> <div> with float because it would work in non-visual browsers. I think a 
> well-defined way of adding footnotes would be popular although it's not 
> quite in the same class of functionality.

In the current draft:

   "Chrome": <header>, <footer>, <sidebar>, <navigation>
   "Content": <article>

Maybe we should make <article> more general-purpose? I hesitate to call it 
<content> because it would be really weird to have multiple <content> 
blocks on the page -- I'm looking for an element that can be used to mark 
up a forum post / blog article / etc.

Maybe we do need both <content> and <article>, although that's starting to 
seem a little excessive and I'd rather remove some of these elements than 
add more.


> > We'll probably keep it to a minimum though. The idea is just to 
> > relieve the most common pseudo-semantic uses of <div>.
> 
> Ideally we could get a large sample of actual sites to find out what the 
> most common uses acttually are. Is there an existing bot avaliable that 
> would allow one to spider (part of!) the web and extract the classnames 
> given to <div> elements?

We (Opera) are working to see what can be done along those lines.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 12 November 2004 02:17:41 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:20 UTC