[whatwg] Re: <section> and headings
James Graham
jg307 at cam.ac.uk
Tue Aug 31 03:58:30 PDT 2004
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.
More information about the whatwg
mailing list