[whatwg] Re: <section> and headings

[Lachlan Hunt]

James Graham wrote:
> On 29 Aug 2004, at 16:42, Lachlan Hunt wrote:
>> James Graham wrote:
>>> 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.

Yes, indeed there does.  I don't understand why the HTML WG decided not 
to deprecate or remove hn elements from XHTML2; but they didn't, so that 
will be something they'll probably have to make a note about.  Infact, 
it might be worth bringing that point up on www-html later on.

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

In order to preserve the semantics of hn elements, I would produce this 
outline:

1. Level 1 Heading
    2. Level 2 Heading
    2. Level 2/3? Heading

Although it may not necessarily be structurally correct for that 
document structure, the semantics of hn elements are preserved.

> 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

You are correct, it is not invalid, but there is a note about not using 
numbered headings out of order.  There should also be an informative 
note in the spec about how they should be used in such circumstances.

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

Which is different from their current definition which says that they 
do.  Thus, your method is changing their semantics.

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

You didn't miss anything, I never said it was a well written spec. 
Essentially, the way they are defined in the DTD, they must be used like 
this:

<h1>Heading 1</h1>
<div1>
     <h2>Heading 2</h2>
     <div2>
         <h3>Heading 3</h3>
         <div3>
             ...
         </div3>
     </div2>
</div1>

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

As I said, I don't particlarly like the numbered divs either, but the 
point I was making is that it means the heading levels are not 
quesionable as they are in your examples 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> ... and <h{n}>

Having thought about this a little more, I think it would be acceptable 
to define <section> as a way to semantically structure a document, but 
to make an informative note about how heading levels should not be used 
out of order, or nested poorly as in your examples (not that it will 
stop people from doing it anyway).

If <h> were added as well, then it should be noted with something like 
the numbered headings are equivalent to the structued headings when 
nested at that level indicated by the number.  For example.  <h2> is the 
same as the second level <h>

<body>
     <h>Heading 1</h>
     <section>
         <h>Heading 2a</h>
         <h2>Heading 2b</h2>
         <section>
             <h2>Heading 2c</h2>
         </section>
     </section>
     <h2>Heading 2d</h2>
</body>

Headings 2a to 2d would be equivalent for a document outline; however 2c 
and 2d (though still valid) may not be structurally correct.  The 
document outline for that example, as determined by the semantics of the 
elements rather than the structure alone, would be:

Heading 1
     Heading 2a
     Heading 2b
     Heading 2c
     Heading 2d

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

No, type is fine because it represents the ContentType of the resource. 
  You just need to be more specific about any other attributes you want 
to suggest.

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

(BTW, that should have said 3, not 8 presentational uses.  I forgot to 
look it up and fix it before sending)

> So, if it's already used for a bunch of things, why not use it some 
> more?

Well, so is font.  I've seen it used to mark up headings, paragraphs, 
lists, tables? (I'm sure someone's tried ;-D).  Why don't find some more 
uses for it?

Basically, it's because it was a oversight that has thankfully been 
cleaned up (mostly) in XHTML2.  type is now only used for the content 
type of an external resource or, in the case of scripts and stylesheets, 
it's also for the element's content.
(I do think that inconsistancy should also be fixed up, and has been 
discussed on www-html previously, but no solution has been found yet)

For backwards compatibility with HTML 4 forms type can also be used for 
form controls, but it should not be used for any additonal purposes.  In 
HTML4, six instances of type actually did represent content types of 
various things, one for form controls, and the remaining three were 
presentational hints for ul, ol and li.  The presentational hints were 
deprecated.  So, essentially it was left with content type and form 
control, which is how it should stay for the WHAT WG specs.

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

Values of the class attribute have always, and will always be author 
defined values.  No language specification should define their values. 
(however, specifications that define a specific use for the language may 
define what values an author can use mean.  For example, the GMPG 
defines that an XMDP [1] is written using HTML and uses class="profile", 
and defines what it means)

Even with a syntax like "_i", there's no guarentee that an author, or 
other spec similar to XMDP, hasn't already used, or will use and define 
that value for other reasons.  Not only that, but <span class="_i"> is 
not in any way superior to <i> (unless the author is using "_i" for a 
semantic reason, rather than italics).  If anything, it's worse because 
it just adds more characters for no reason.

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

I'd prefer dozens of new elements, rather than trying to redefine an 
existing attribute, or even a new attribute with many values.  But 
hopefully the number of elements will be constrained to only those that 
are absolutely necessary.

[1] http://gmpg.org/xmdp/
-- 
Lachlan Hunt

http://www.lachy.id.au/
lachlan.hunt at lachy.id.au