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

[whatwg] Re: <section> and headings

From: Lachlan Hunt <lachlan.hunt@iinet.net.au>
Date: Mon, 30 Aug 2004 01:42:56 +1000
Message-ID: <4131F980.6040503@iinet.net.au>
James Graham wrote:
> 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...
> 
> When a h1...h6 element is the child of  a  <section> element, UAs which 
> contruct a document outline must do so from the depth of "section" 
> nesting alone and ignore which of h1...h6 is used...

This is a conceptually bad idea because it alters the defined semantics
of <hn> elements and combines it with XHTML2-style, structured headings.
  Doing this essentially says that h1 to h6 are exactly the same, which
they are not.  While I'd support the addition of <section> elements, I
do not support altering the semantics of existing elements.  If
<section> were introduced for the purpose of structuring a document,
than an <h> element should also be introduced for the headings.  But, I
believe that would not be backwards compatible with IE, as it be
ignored, and unstylable like every other new element when served as
text/html.

If you really want *numbered* heading levels to be determined by their
structure level, I'd prefer it be done using numbered sections, similar
to the numbered divs found in the ISO HTML [1] because at least that
preserves the semantics of the hn elements.  But, I also don't think
that's a good idea because it adds too many extra elements, which will
not be understood, nor used correctly by anyone.  It may also make 
documents more difficult to maintain.  So, personally, I think the 
semantics of <hn> elements should not be changed, but that doesn't mean 
<section> can't be introduced.

> 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

I would not support a <chrome> element because that is the term often
used to refer to the application interface styles, and has absolutely
nothing to do with being a sectoin.

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

DO NOT overload the type attribute any more than it already is.  We had 
this discussion a few months ago when I was paying more attention to 
this work, and several people were suggesting the use of type for 
various things.  The type attrubue *SHOULD* only be used for denothing 
the MIME type of a resource, and for form controls.  HTML4 already 
overloaded the attrbute with 10 different uses; 8 of them being 
presentational, and thus deprecated.

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

Andy Clarke did a study a few months back on the most common section 
ids, to determine what a general site consists of, and published his 
results [2 - 4].  Maybe that could help with determining semantics for 
new elements.

[1] http://www.cs.tcd.ie/15445/15445.HTML
[2] http://www.stuffandnonsense.co.uk/archives/whats_in_a_name.html
[3] http://www.stuffandnonsense.co.uk/archives/naming_conventions_table.html
[4] http://www.stuffandnonsense.co.uk/archives/whats_in_a_name_pt2.html
-- 
Lachlan Hunt

http://www.lachy.id.au/
lachlan.hunt at lachy.id.au
Received on Sunday, 29 August 2004 08:42:56 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:36 UTC