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

Re: Getting beyond the ping pong match (was RE: Cleaning House)

From: Maciej Stachowiak <mjs@apple.com>
Date: Mon, 7 May 2007 15:13:31 -0700
Message-Id: <E44AD631-9AC2-4E1E-A1B5-5D26BEA339A1@apple.com>
Cc: public-html@w3.org, www-html@w3.org
To: mark.birbeck@x-port.net

On May 7, 2007, at 2:44 PM, Mark Birbeck wrote:

> Hi Maciej,
>> > But the logical error that is being made by the proposal is to
>> > conclude that you are able to _infer_ one author's intent from  
>> that of
>> > others. Since there is nothing in the HTML spec that says that
>> > @class="copyright" means _anything_ at a global level, then even if
>> > 100 authors use it in the way that is being suggested, you *cannot*
>> > infer from that anything about author 101.
>> That's like saying you can't infer anything about a speaker's use of
>> the word "hella" (a Northern California slang term) because it's not
>> in the dictionary. Speakers are still pretty consistent about what
>> they mean, even though no formal authority has sanctioned it.
> That's a great example!
> The problem though is *not* that no formal authority has sanctioned
> the use of the term "hella", but that there is no mechanism by which
> @class can go from being allowed to hold any slang term you like (as
> it does at the moment) to holding dictionary-defined terms.
> The proposal on the table is to simply declare certain terms to now be
> in the dictionary--using your analogy we decide that "hella" is now in
> the dictionary, and its meaning is the norcal definition. The problem
> though, is that you've done that using an attribute that can contain
> _any_ term, so the residents of Hella in Iceland will carry on using
> the term in the way they think most appropriate, and any programmer
> with any sense is not going to bother relying on the occurrence of
> "hella" to mean the Californian definition, since they cannot be sure
> that the author was intending this definition.

The existence of Icelandic does not invalidate the meanings of words  
in English.

> But, we agree that moving to a dictionary-definition for 'copyright'
> (for example) is desirable, based on observations that 'copyright' is
> used a lot in the wild. So, assuming that we do want to move from a
> slang definition to a dictionary-defined one, we can do one of two
> things. The first would be to provide a new attribute which says,
> 'only dictionary terms can be used here'. That's how the new attribute
> @role works, but it's also how attributes like @rel and @rev work.

No, rel and rev mix predefined values with arbitrary author-defined  
values, and make no promises that new predefined values won't be  
added in future versions. <http://www.w3.org/TR/html401/ 
types.html#type-links>. This is exactly what is proposed for class,  
except that in HTML 4.01 it had 0 predefined values.

> The second technique would be to say, 'we're now going to allow the
> attribute that has traditionally been used to hold slang meanings, to
> also hold dictionary-defined ones'. If we do that though, we need a
> way to differentiate between the two within the same attribute.

The English language does not differentiate, and things go in the  
dictionary based on usage. We don't invent a new spelling and  
pronounciation for each word that goes in the dictionary. This does  
not hamper communication. So I disagree with your assertion.

> In my view both solutions are useful. @role is already in use today in
> HTML documents and in Firefox (remember those cow-paths?), and
> although it provides a semantic 'hook', its purpose is quite specific,
> and tells us about the 'intent' of a piece of mark-up, e.g.,
> navigation areas, main section, notes, etc. But prefixed @class values
> are a more general technique which is being used in RDFa, and is
> something that is sorely needed in microformats.

I still don't see how role serves any use case that class doesn't.

>> In other words, this is just Descriptivism vs. Prescriptivism again.
> There is nothing wrong with using the 'descriptivist' approach to
> finding new sources of things to try to standardise, and RDFa was also
> designed in that way.
> But what _is_ wrong is to attempt to redefine an HTML attribute in a
> non-backwards--compatible way. @class previously did not define its
> values to be universally applicable, but now we're saying that they
> _are_ universally applicable (or worse, some of them are).

It did define that class can be used for any general-purpose use by  
user agents. Assuming meanings for some predefined classes by  
convention seems to me like a valid general-purpose use.

> The big problem is that this new approach gives us no way to tell the
> difference between one of the new 'magic' values and the old non-magic
> values.
> This is therefore not at all backwards compatible, and fundamentally
> changes the meaning of @class.

Whether this is a problem depends on the cost of false positives vs  
the benefit of automatically getting more positive hits without any  
rewriting of existing content. That probably depends on the intended  
use cases of various proposed predefined class values.

Received on Monday, 7 May 2007 22:14:24 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 30 April 2020 16:21:03 UTC