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

continuous? evolution of @class [was: Re: Getting beyond the ping pong match (was RE: Cleaning House)]

From: Al Gilman <Alfred.S.Gilman@IEEE.org>
Date: Mon, 7 May 2007 18:39:52 -0400
Message-Id: <p06110402c26553017fc0@[192.168.1.100]>
To: public-html@w3.org
Cc: www-html@w3.org

At 10:44 PM +0100 7 05 2007, 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.

s/infer/deduce

>>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.

No mechanism?

Consider a linked interpretation sheet. This may be linked within
html:html.profile or via a <link rel="dcterms:conformsto" ...> in the
html:head. This interpretation sheet would afford a glossary of usage
that binds term selectors (e.g. 'hella' appearing in @class) to
further description of any sort; a dictionary entry in a dictionary
of American slang, or a SKOS concept, or a reference to the city.

Back when we discussed this approach with Eric Miller he assured
us there were multiple good ways to hook an HTML page to such
an interpretation sheet.

http://lists.w3.org/Archives/Public/wai-xtech/2004Aug/0026.html

This is entirely continuous; migrating from a class of indications
where the semantics is purely by mnemonic value and use in
linked styles to one where the semantics is by mnemonic value
and linked styles and linked interpretation rules.

>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.
>
>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.
>
>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.

It would seem we can get by with a way to discover the dictionary
entries for those terms that have them. It doesn't have to mess with
the syntax of the attribute.

I'd be willing to entertain a thread debating whether XMDP is
everything we need in an interpretation-sheet and schema language.
But saying that just adding machine-findable explanations for your
@class tokens makes a discontinuous change is IMHO a strange
statement.

Al

>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.
>
>RDFa uses the CURIE syntax--a bit like QNames, but not so restrictive,
>and not confined to XML--and it would certainly be very easy to modify
>it so that this:
>
>  <div class=":copyright">
>    ...
>  </div>
>
>gave us something meaningful. For example, we could make the default
>'qualifier' HTML itself, which would make our example mean "the HTML
>term, 'copyright'".
>
>This might be a little awkward at the CSS level (the colon would need
>escaping until CSS selectors were modified), but it does have the
>advantage of not only resolving all of the problems we've been
>discussing, but also neatly co-existing with RDFa and microformats,
>thus allowing authors to do more powerful things:
>
>  <div class="dc:creator">
>    ...
>  </div>
>
>>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). 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.
>
>Now, if there was no other way to do this, and this change was
>necessary to enter some brave new world, then certainly we'd have to
>think long and hard about it, and if necessary, go for it. I certainly
>wouldn't say that nothing can ever change, or that we should never
>break backwards-compatibility. But that isn't the case here; on the
>table there are two ways of avoiding the confusion, both of which
>originate from trying to solve this very problem a number of years
>ago, and either of which will maintain the consistency of @class.
>
>Regards,
>
>Mark
>
>--
>  Mark Birbeck, formsPlayer
>
>  mark.birbeck@x-port.net | +44 (0) 20 7689 9232
>  http://www.formsPlayer.com | http://internet-apps.blogspot.com
>
>  standards. innovation.
Received on Monday, 7 May 2007 22:50:18 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:44 UTC