W3C home > Mailing lists > Public > public-html@w3.org > May 2007

Re: "Pave The Cowpaths" Design Principle

From: Jukka K. Korpela <jkorpela@cs.tut.fi>
Date: Sun, 20 May 2007 11:18:25 +0300 (EEST)
To: public-html@w3.org
cc: www-html@w3.org
Message-ID: <Pine.GSO.4.64.0705201054550.1218@mustatilhi.cs.tut.fi>

On Sat, 19 May 2007, Maciej Stachowiak wrote:

> The spec also said class was free for "general use by user agents", so in 
> fact the spec explicitly did not promise values would be free of predefined 
> meaning.

You are apparently referring to clause 7.5.2 (Element identifiers: the id 
and class attributes) in the HTML 4.01 specification,
http://www.w3.org/TR/html401/struct/global.html#adef-class
even though you don't cite it, and what you present as a direct quotation 
isn't a direct quotation.

The specification says about the id attribute that it is, among other 
things,
"For general purpose processing by user agents (e.g. for identifying 
fields when extracting data from HTML pages into a database, translating 
HTML documents into other formats, etc.)."
It then repeats this for the class attribute, though without the 
parenthetic remark, so I think we can infer it for class, too.

The wording is sloppy, as so often in HTML specifications, but it 
apparently relates to _identifying fields_, so that in programming and 
conversions, one can refer to an invidual element or a set of elements by 
the id or class attribute, respectively.

It would be grossly wrong to infer that you can freely assign meanings to 
specific values of those attributes. When e.g. the use as a style sheet 
selector has been mentioned, and such usage has been widely described and 
exemplified in W3C and other documents, you just can't pick up a set of 
specific values that they mean something specific.

Even for the "general purpose processing" use, it would be quite 
inappropriate to assign definite meanings a decade after the class 
attribute has been in use. If someone who has written a script that 
processes a group of elements in a document and used class="note" for the 
purpose (perhaps because "note" means 'bill' in his language and those 
elements relate to some bills), he will be justly upset if browsers start 
displaying or otherwise treating those elements in some special way

>> whereas for rel, N were given and people were warned that there might be 
>> N+M in the future.
>
> The thing is, they invented some nonstandard useful new values many of which 
> we are adopting as standard without controversy. Seems directly analogous. 
> Whether people were "warned" or not will have no effect on the rate of false 
> positives.

It was clearly indicated, from the beginning, that rel values are supposed 
to be taken from a predefined (and relatively small) set of values with 
agreed meanings. The set was never really defined, and this is a sad story 
(part of the "we asked the browser vendors to implement <link> but they 
misheard it as <blink>" saga). But authors always knew that the set of rel 
values is special and not a free space. To take a somewhat analogous case, 
the target attribute was defined effectively as a free space except that a 
small set of values beginning with "_" were predefined, and other values 
beginning with "_" were forbidden (apparently, to allow future additions 
to the set of predefined values without disturbing any use of the free 
space). Although the target attribute itself is mostly useless or worse 
(since it mainly relates to frames), the technical approach to defining 
its values was sound.

If you want to have value space with predefined values and freely useable 
values, you should make them two subspaces that can be distinguished by 
very simple syntactic criteria. This applies even more so if the space has 
been free for years. Then the only feasible approach - if you want to add 
predefined values - is to make the predefined values _violate_ the current 
syntax and redefine the new syntax accordingly.

-- 
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
Received on Sunday, 20 May 2007 08:18:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:15:58 GMT