Re: Preparing to launch the Forms Task Force ...

Matthew Raymond schreef:
>    From the HTML 4.01 Spec [1]:
>
> | A heading element briefly describes the topic of the section it
> | introduces.
>
> ...
>
> | The following example shows how to use the DIV element to associate a
> | heading with the document section that follows it.
>
> ...
>
>    It's pretty clear that headers are semantically the introduction of a
> section. The specification simply lacks a definition for how to
> determine the bounds of the section.
>   

Actually, it says that the <div> elements are used to associate a 
heading with its sections. In other words, according to this phrasing, 
<div> can be what is a <section> in HTML5. Or <section> is a subset of 
<div>. Although the section on <div> itself does not support this.

As for the first part of the quote, I never disputed that the element is 
the topic of the section. What I object against is that they tell you 
where a section begins, but they don’t tell you where it ends, so it 
would be incorrect to make assumptions about that. I have created 
several documents where a section’s text continues after a subsection. E.g.:

<section>
   <h>Heading</h>
   <p>Blabla.</p>
   <section>
      <h>Subsection</h>
      <p>…</p>
   </section>
   <p>So, to conclude, blabla.</p>
</section>

In HTML4, that would be:

<h1>Heading</h1>
<p>Blabla.</p>
<h2>Subsection</h2>
<p>…</p>
<p>So, to conclude, blabla.</p>

Does the last <p> belong to the subsection? It does not, and the HTML4 
doesn’t claim that it does.

>    Now, I will concede that the semantics of <div> are weak. In fact,
> it's the poster child for why |role| would be a dismal failure. Here you
> have an element being used for sections right in the specification with
> the class name "section", and there are probably only a handful of
> people who've actually marked pages up that way.
>   

I don’t see how that illustrates that role would be a failure. I’m sure 
that even after HTML5 is finished, there will be tons and tons of people 
who never use <section>. As I am sure that there will be tons of people 
who use either a <section> or a <div> where a <header>, <footer> or any 
of the other section-type elements would be more appropriate. If 
anything it would show that <section> would be a failure, and would be 
used as generically as <div>.

Additionally, I would think that if <div> were really to be meant as 
<section>, they should have written a better description of <div> itself 
[1]. I think the example is merely some kind statement that ‘they don’t 
really miss a sectioning element, truly not’, to point to if someone 
complains about it.

[1] http://www.w3.org/TR/html4/struct/global.html#h-7.5.4

>    However, the semantics of <h1>-<h6> are clear about the fact that
> these elements begin sections.I would suggest that one way to process
> them is that they should be tied to their parent elements. The first
> <div> in the example above has a heading, then the child <div> has a
> heading, therefore the child <div> is a subsection of the parent.
> Associate elements accordingly. If there are two heading elements on the
> same level, then the second one begins a new section.
>   

Well, what I’m saying is, just don’t define it. It’s rather useless. 
Outlines will work without it, and other than that I don’t really see a 
need for it. Add to that that just because the sectioning is not done 
explicitly, it’s really not possible to derive the sectioning while 
guaranteeing it’s correct. (And no, you can not depend on <div>s to 
properly indicate that, because both you and I know they’re not used for 
that purpose.) And last but not least, it would also save a huge bunch 
of text in the specification.

Btw, are examples in the HTML4 normative?

>    There have been several other proposed algorithms for this as well.
> I'm not suggesting the one above is the best. I'm merely trying to
> determine why you feel that the task is somehow impossible.
>   

As I said, because you can not derive sections from only heading elements.

>> And even if you would want to specify it. I mean, it’s *really* obvious. 
>> “Each heading starts a new section according to their level, which lasts 
>> until the next heading or the end of the document”.
>>     
>
>    This is directly contrary to the implied semantics of the markup
> example from the spec above, which clearly implies nesting.
>   

There’s no rule in HTML (even not an unwritten one in general practice) 
that sub-sections must be placed in <div>s. There are tons of documents 
which don’t do that.

I just opened the first article that I could find on O’Reilly Network 
[2] to verify it, and indeed, no <div> tags to indicate sections. Now 
unless you want to claim that you can predict where each and every one 
of O'Reilly’s sections and those of all the other documents on the web 
begin and end, I think it would be better if the definition remained as 
it is now. Which is that this kind of markup simply *does not imply any 
kind of sectioning* other than that the headings indicate where a 
section begins.

[2] 
http://www.oreillynet.com/pub/a/oreilly/digitalmedia/2007/03/16/digital-media-insider-podcast-9-songs-you-may-have-missed.html

>> There, put that
>> phrase in the spec instead of that whole chapter. There is no need to be 
>> overly meticulous about it, like WHATWG spec section 3.8.11.1. “Creating 
>> an outline”.
>>     
>
>    Essentially, you're advocating abandonment of HTML 4.01 heading for
> use in creating things like a Table of Contents, for which the elements
> were originally intended.
>
>    I would agree that we don't have to support non-semantic use cases
> for <h1>-<h6>, but if authors made their best attempt to use these
> elements semantically and correctly, their efforts should not be discarded.
>   

Oh, I don’t want to abandon it. <h1>…<h6> should stay exactly the way 
they are. For an outline, that is good enough and always has been good 
enough.


~Grauw

-- 
Ushiko-san! Kimi wa doushite, Ushiko-san nan da!!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Laurens Holst, student, university of Utrecht, the Netherlands.
Website: www.grauw.nl. Backbase employee; www.backbase.com.