[whatwg] Re: <section> and headings

[James Graham]

On 29 Aug 2004, at 16:42, Lachlan Hunt wrote:

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

If there are going to be two methods of determining the level of a 
heading, there needs to be some indication of how they interact. For 
example, in XHTML 2, how would I generate an outline from code like:
<section>
<h>Level 1 Heading</h>
<section>
<h>Level 2 Heading</h>
<section>
<h2>Level 2/3? Heading</h2>
</section>
</section>
</section>

AFAIK (and I haven't looked very closely), there's nothing in the XHTML 
2 spec to say that the above code is invalid and, given the way that 
authors use headings at present, I can imagine code like the above 
being used e.g:

<section>
<h>Newspaper name</h>
<section>
<h1>Main Headline</h1>
</section>
<section>
<h2>Other story</h2>
</section>
</section>

>  Doing this essentially says that h1 to h6 are exactly the same, which
> they are not.

It says that h1...h6 do not define the depth of nesting in the document 
hierachy. They may be used in some other way e.g. to distinguish the 
main headline on a page.

>   While I'd support the addition of <section> elements, I
> do not support altering the semantics of existing elements.

Insofar as headings are ever used, they are almost always used 
incorrectly (one cannot generate an outline view of the document from 
the headings as marked up). The exception is documents with a very 
formal structure (e.g. w3c specs). This suggests the HTML 4 heading 
model is sufficient for simple documents but not flexible enough for 
the "web-apps" that wrap most documents (a simple weblog is a web-app 
in the sense I use here because each page contains some fixed content 
which is not relevant to the document body).

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

Sorry, I'm not sure I understand the point of numbered divs. The 
document only seems to have a dtd without explanatory text (I'm sure I 
must have missed a link or something). How would one use numbered divs 
and why are they superior to sections? I really dislike having a fixed 
set of numbered elements because they don't scale so I'd really need to 
see some benefit here.

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

See my comments about XHTML 2 above. If <section> is introduced to give 
structure then (as a developer of a UA-addon for creating document 
outlines), how should I deal with documents that use both <section> 
(sure to give a hierarchical outline) and <h{n}> (often used in a way 
that doesn't allow outlines to be created)?. This *must* be defined 
even without an <h> element:
<section>
<h3>Heading</h3>
<section>
<h2>heading</h2>
</section>
</section>
*will* appear multiple times and will have a different 'correct' 
interpretation on different sites.
>
>> 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.

The idea is that it is used to mark all areas of the document that 
aren't part of the main content but are part of the surrounding site. 
If these areas are regarded as the site interface <chrome> is roughly 
right. But it's the idea that's important not the specific name.

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

(that's a bad name, imho. We would have been better giving something so 
specific a specific attribute name like 'mime'. Type is a very generic 
word and hence suitable for a variety of purposes)

> , and for form controls.
>  HTML4 already overloaded the attrbute with 10 different uses; 8 of 
> them being presentational, and thus deprecated.

So, if it's already used for a bunch of things, why not use it some 
more? It's certainly been useful in extending HTML 4 forms. (In fact, 
I'd rather have a means of defining reserved class names. In a 
different context <span class="_i"> is superior to <i> and has almost 
all the same benefits. But I can see that going down like a lead 
balloon :) )

In any case, the crux of the suggestion is to use a single element with 
an attribute to distinguish the type of content rather than inventing 
dozens of new elements. Despite bringing it up, I can't say that I'm 
too thrilled with the idea myself.

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

Summary (assuming we want elements where he talks about class names):
<header>
<footer>
<navigation> (we have <menu>)
<sidebar>
<search> (I'm not sure how this should work)
<content>
<copyright>

he then makes up some others. <product> to delimit a product listing on 
an e-commerce site is an interesting one but I'm almost sure we 
couldn't come up with a rich enough syntax to allow UAs to provide 
additional e-commerce specific functionality.

It would still be nice to get a larger sample from a greater variety of 
different site types.