W3C home > Mailing lists > Public > public-html@w3.org > January to March 2007

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

From: Matthew Raymond <mattraymond@earthlink.net>
Date: Fri, 23 Mar 2007 07:08:53 -0400
Message-ID: <4603B545.2050002@earthlink.net>
To: Laurens Holst <lholst@students.cs.uu.nl>
CC: public-html@w3.org

Laurens Holst wrote:
> 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.

   By this argument, all block-level elements are subsets of <div>. This
is in error. You might say they are SUBCLASSES of <div>, but they are
not subsets. If anything, <div> is a mutual subset of all block-level
elements.

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

   People will naturally make assumptions about that just by viewing the
page. It's not unreasonable to have an a document outline algorithm that
can mirror that intuitive process.

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

   Yes and not. It could be marked up like this, for example:

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

   In fact, thats probably how I'd mark it up.

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

   Anyone reading your HTML4 example _only_ would assume that the second
paragraph is part of the second level subsection, and there's no obvious
way to remedy that with CSS. Furthermore, real markup structure is
needed if you want to style the section and subsection boundaries.
Marking up the subsection is unavoidable in this situation.

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

   If <section> were a failure, that would not prove that <div
role="section"> would be a success. Quite the contrary, it would
indicate that <div role="section"> would be as monumental a failure as
<section> and therefore isn't spec-worthy.

   Now, it's true that attributes and attribute values are more suited
for lesser use cases. However, attributes shouldn't expand the semantics
of the parent element, they should refine them. Extension of element
semantics should be handled by extension mechanisms, and defining
extensions to HTML is by definition outside the scope of HTML.

   Thus, even if you argue that |role| is a semantic extension
mechanism, there should be no predefined values for it in HTML
specifications because that would effectively be defining extensions to
HTML inside the HTML specification itself. Furthermore, the only real
advantage to |role| over |class| is that the attribute values are "more
semantic". There is not functional difference between the two, except
for namespaces, which I view as more trouble than they're worth in an
attribute value.

   (There are those that argue that some classes are purely
presentational, but one could just as easily say that all class names
are semantic because the presentation is motivated by the reasoning of
the designer, even if he or she is not aware of it. Perhaps people are
resistant to the idea of making all their classes semantic because they
don't want to consciously analyze their unconscious decisions.)

> 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

   The HTML 4.01 spec is so vague and underdefined at times that I would
not assume a failure to define something can lead people to any sort of
conclusion as to the original working group's intentions.

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

   Even for outlines, you need some means of determining how sections
relate to each other. Heading either start a new sibling section or a
subsection, so the beginnings and endings of sections will be clear in
all but the literal edge cases if you determine those relationships.

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

   While I agree <div> elements may be less useful than I previously
argued, I don't feel that it is nearly as impossible as you say to
create an algorithm for consistent document outlining across user agents.

> Btw, are examples in the HTML4 normative?

   I'd say your guess is as good as mine, but in many situations the
examples are the only thing you have to go on.

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

   And they pay the price in styling and markup readability.

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

   I disagree. There is no clear way to generate outlines, so user agent
outlining algorithms will not necessarily produce identical or even
similar results.
Received on Friday, 23 March 2007 11:08:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 23 March 2007 11:08:10 GMT