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

Re: Predefined Class Names Solution

From: Mark Birbeck <mark.birbeck@x-port.net>
Date: Mon, 7 May 2007 17:17:00 +0100
Message-ID: <640dd5060705070917o49ed2312wbbddca568ac99a76@mail.gmail.com>
To: public-html@w3.org
Cc: "W3C HTML Mailing List" <www-html@w3.org>

HI James,

> The intent of the author is (IMHO) not terribly relevant. What matters
> is whether their *actual* usage matches the proposed spec. If a survey
> shows that a fraction f of uses of class="copyright" do match the spec
> and f is >~ the fraction of authors who use elements such as <address>
> in line with the HTML4 spec then I don't see how speccing
> class="copyright" is a major problem from the point of view of "semantic
> compatibility".

The issue is pretty straightforward. @class is defined in HTML as
providing a semantic 'hook', but quite how that hook is used is not
defined. In particular there is no way to define universal values for
class. This means that when an author uses "copyright" for a value of
@class we can deduce no more from it than that they are saying 'my
copyright'. This would be true even if every author insisted that they
were actually trying to say the same thing as each other, since *by
definition* @class gives us no way to all 'say the same thing as each
other'.

So the problem is that if you try to ascribe global meaning to @class
values that are in every way indistinguishable from traditional HTML
@class values, then you have changed the meaning of @class in a way
that is not backwards-compatible. In other words, it's not just that
you have created the possibility of "copyright" meaning two different
things, but @class itself has been fundamentally changed.

In my view, there are two ways to get out of this bind. The first is
to use a new attribute that does what it says--provide metadata about
the purpose of an element. The second is to allow @class values that
are extremely unlikely to have occurred in the past, perhaps by using
a fixed prefix such as '_', or any prefix, followed by a fixed
separator, such as ':'. That would resolve the ambiguity in class
names, but also allow @class to still play its current role of having
no universal meaning.

As it happens, in future versions of HTML and XHTML I favour using
both, to meet different use cases.

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 16:17:06 UTC

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