W3C home > Mailing lists > Public > www-html@w3.org > August 2004

Re: [xhtml2] Questions

From: Karl Dubost <karl@w3.org>
Date: Mon, 23 Aug 2004 08:38:48 -0400
Message-Id: <612B7482-F501-11D8-9BC6-000A95718F82@w3.org>
To: W3C HTML <www-html@w3.org>

Le 22 août 2004, à 19:07, Anne van Kesteren a écrit :
> I don't. I agree that you can't specify all use cases for a particular 
> element or attribute, but I do think a lot of elements could be better 
> defined on what they should/must contain and should/must not contain.

There is a danger with that and history of Web development shows us the 
"mistakes". Don't forget that "first times" have a tendency to set the 
interpretation for a while.
An "h1" element has been initially presented as a 16px, bold font. 
People have used it because it was bigger and bold, not because people 
wanted to create an heading. If you present an element with a specific 
behaviour, you might risk to set *one* behaviour and that's all. It's 
why a separate best practices guide is more suitable, and it can 
elvolve on his own without redifining the specification each time you 
add a new use case.

Look how people debate about an element, right now. One of the first 
thing, they will do is look at the example which is given in the 
specification as a *normative* prose, when it's not. You can explain in 
the introduction of the document, the examples are not normative, 
people will not necessary see it.

Though I completely agree with you, that there's a need sometimes for a 
longer prose in the description of the element. The definitions are 
sometimes a bit short. Hey, XHTML 2.0 when in Last Call will be a very 
good opportunity to ask clarification for every point of the 

> (Having namespaces in values (qnames iirc) makes things look like a 
> mess by the way. But that's just my humble opinion.)

Classes values are not mandatory.
You can create profiles for that, though there's no official mechanism 
to create a profile.
my class names are not mandatory and done for my own use, you are not 
supposed to read the source of my HTML to understand it ;)

> Which will make it not usable (and not used) in the end. The same as 
> with the LONGDESC attribute from HTML 4.01. (Maybe not a really good 
> example, since IMG was evil by design from the beginning.)

People use things:
	- They need
	- They benefit of

The problem is not so much make a good specification but to leverage it 
by real implementations. Example: 'h1' used by search engines. Most of 
the people creating Web pages don't need the semantics of HTML and they 
don't see any values into it. It's a long debate about "People don't 
think in terms of structure". I could go on a very long time on this 
topic. Reality check.

> Since CITE would not have the same structural value as SOURCE. CITE is 
> per definition an inline element, SOURCE would be a block level 
> element, which would be more appropriate for use within BLOCKQUOTE. 
> Maybe I should have called it BLOCKCITE instead, to make the point 
> more clear.

noooo... not yet another block element. This shows me that there is 
something plain wrong about block/inline model that we debate here for 
quite a long time. ;)

Thanks Anne for your comments.

Karl Dubost - http://www.w3.org/People/karl/
W3C Conformance Manager
*** Be Strict To Be Cool ***

Received on Monday, 23 August 2004 13:01:58 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 30 April 2020 16:20:54 UTC