- From: Lachlan Hunt <lachlan.hunt@iinet.net.au>
- Date: Wed, 01 Sep 2004 01:14:07 +1000
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
Received on Tuesday, 31 August 2004 08:14:07 UTC