W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2004

[whatwg] WA1 - The Section Header Problem

From: James Graham <jg307@cam.ac.uk>
Date: Fri, 19 Nov 2004 09:35:20 +0000
Message-ID: <419DBE58.1060708@cam.ac.uk>


Matthew Raymond wrote:

> James Graham wrote:
>
>> Matthew Raymond wrote:
>
> [Snip!]
>
>>>    Note that the structure example you use above is the semantic 
>>> document structure I was talking about earlier. Importance need not 
>>> equal structure. User agents simply have the option of interpreting 
>>> it as such when it does not conflict directly with the semantic 
>>> document structure. 
>>
>>
>> Giving UAs options tends to lead to non-interoperable solutions.
>
>
>    Why do outlines build entirely by user agents have to interoperate?

Because one "User Agent" might be an editor which automatically inserts 
a table of contents whilst the other might be a browser which shows an 
outline, for example.

> Furthermore, I'm not giving the user agents anything they didn't 
> already have. I'm simply defining a way vendors can continue using 
> <h1>-<h6> as they were using it before without breaking the structure 
> created by <section> elements. 

Vendors of what? And breaking the structure how? I don't see how a 
clearly defined relationship between <hn> and <section> will break 
anything.

> > If they don't know that why have any spec at all?
>
>    HTML 4.01, with regards to headers, has virtually no specification. 
> this is the entire specification of it:
>
> "Heading information may be used by user agents, for example, to 
> construct a table of contents for a document automatically."

I'm aware of the limitations of HTML 4 on this issue. That doesn't mean 
we should do a bunch of stuff to make headings work properly and then 
throw away that progress at the last minute "because HTML 4 got this wrong".

>> What do you mean by "structual semantics" other than the ability of a 
>> UA to infer an document structure, of which an outline is a 
>> representation.  The whole concept of semantics is only useful 
>> insofar as
>> it allows UAs to do something and in the case of structure the 
>> obvious thing for a UA to do is present the structure. What's the 
>> point of speccing up a robust structural model if we don't specify 
>> how one can infer structure from the model? You seem to be 
>> sidestepping the problem rather than solving it.
>
>
>    I'm not sure what you're getting at here. The <hn> elements, as 
> defined in HTML 4.01, don't have any semantic meaning related to 
> structure.

Yes they do. They head (unmarked) sections of the document. It's poorly 
defined in the spec how those document sections are related to each 
other but, given the markup in the spec itself, we can infer how HTML 4 
headings are supposed to be used.

> In fact, there is no definition in the specification of how to 
> associate headers with content or even how they relate to each other. 
> All I'm attempting to do is say that if vendors decide to make up 
> their own set of rules regarding how to use that header information, 
> those rules can't violate the structure created by the <section> 
> elements. 

Why are vendors going to be making up their own rules at all. I really 
don't understand what that gives anyone. Vendors, authors and users are 
all better off if there is a single, working, header model (and, in 
general, if the spec defines expected behavior as far as possible).

>    I don't see a point to this limitation. In my model, an <hn> 
> element renders the same regardless of where it's used, unless it's 
> used as a tab label, and <h> = <h[level]> with regards to both 
> semantics and presentation. Are you referring to levels greater than 
> six? We can just make the default presentation for a header with a 
> level greater than six the same as <h6>. Actually, correct me if I'm 
> wrong, but would this work for that:
>
> |   h1, section[level=1] h { /* H1 styling */ }
> |   h2, section[level=2] h { /* H2 styling */ }
> |   h3, section[level=3] h { /* H3 styling */ }
> |   h4, section[level=4] h { /* H4 styling */ }
> |   h5, section[level=5] h { /* H5 styling */ }
> |   h6, section[level=6] h { /* H6 styling */ }
>
>    Well, in theory, some jerk could do <section level="7">, I suppose. 
> I wish you could do this in CSS:
>
> |   h6, section[level>=6] h { /* H6 styling */ } 

As other people have pointed out, the point of allowing nested 
<sections> is that you don't have to do this. Besides, what does:
<section level="25">
<section level="3">
</section>
</section>

mean? This idea seems to reproduce all the problems of the HTML4 heading 
model. And I'm still trying to work out what the real advantage would be.
Received on Friday, 19 November 2004 01:35:20 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:20 UTC