On 4/19/04 4:44 AM, "Ian Hickson" <ian@hixie.ch> wrote:

> 
> On Mon, 19 Apr 2004, David Woolley wrote:
>>> Stylesheets have absolutely nothing to do with semantics like this.
>> 
>> That's true, but what I was saying was that the right way to provide
>> a lot of the information that goes into headers and footers is as
>> link elements or meta references.
> 
> I think you are missing the point. People want this kind of content to
> appear in the content area, they want to mark it up richly, including
> nested lists of links and so forth.

Strongly agreed with Ian here.

There has been a trend towards many folks in W3C making claims like
"Everything is metadata" because they have tricked themselves into thinking
so, and it is a convenient rationalization for RDF.

The reality is that most of what these folks call "metadata" is called
"content" by people that actually produce web pages.

> But they need to be able to mark off certain sections as being "the
> header" or "the footer" or "navigation" -- for several reasons; sanity is
> one of them, clarity of markup is another. If there was a semantic way of
> marking this up, aural UAs could skip past navigation, or jump to
> navigation, easily. Indexers could be careful to avoid navigation and
> footers in their indexing. And so forth.

Agreed.

> One way of telling that there is a need for this is to look at random Web
> pages written by people who understand HTML (i.e. pages that don't use
> <font>, etc) and see what they are using the semantic-free <div> elements
> for. You _frequently_ see:
> 
>  <div class="header">
>   <p>Welcome to...</p>
>   <h1>XYZ Site</h1>
>   <h2>This site for Xs Ys and Zs</h2>
>  </div>
> 
> ...which IMHO is semantically dubious at best, and clearly denotes the
> need for more semantics (in this case, probably <header> and <byline> or
> some such).

Agreed again.  In fact, such case studies of real world semantic HTML being
published on the web would likely form a great requirements document for
additional XHTML M12N modules.  I have yet to see such a case study.


>> Moreover, what I was also saying is that, if browsers haven't provided
>> explicit support for similar features, they are unlikely to do so for
>> new ones,

This reasoning has been proven false time and time again, since there are
many specs that came out a while ago that browsers ignored, and yet some of
these same browsers are implementing newer specs.

And unless you are a browser implementer, you are in no position to assume
what implementers will or will not implement; such statements are purely
pessimistic speculation that doesn't serve any productive purpose.


> The elements that were proposed would be no harder to support in UAs than
> <div> is already. So I don't understand the problem. (Indeed some UAs that
> already just fake support for any element would _already_ support them
> to a large extent.)

The problem is one of data.  To properly design additional sets of tags to
add to HTML (XHTML M12N modules), there needs to be a good study of what
semantic authors are doing today.  And just sending out a survey won't get
you the right information either -- you'll get responses indicating what
people *think* they want, rather than what they'll actually use.  Looking at
de facto class names is a much better indicator of what new semantics
authors are actually *using* today.


Tantek