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

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.

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.

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 21:44:09 UTC