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