Re: Classes Considered Harmful

[I decided that discussion of this is probably more relevant on
www-html than it is simply archiving it to www-archive.]

> After weeks of puzzling this problem, I've finally decided that
> "classes" are to be considered harmful in markup. Why? The
> simple reason is that they attach additional behaviours to markup
> [...], and extend them in ways which should be done using
> (things like) substitution groups and xsi:type denotations.

After a few more weeks of puzzling this problem, and the torrent of
insightful emails from Al on the subject (e.g. [1], [2]publically
available), I realise that my original mail raised many important
points, but that the overall view was slightly distorted. The words
"close, but no cigar" come to mind :-)

The dangers and disadvantages to classes are, of course, real. People
abuse them just as they can abuse practically any system that give you
a certain amount of freedom. We find this sort of abuse in markup
constantly:-

   <myelem class="blue"/>

Here, the presentational attribute of the element not separated from
content; the presentation has not been applied based upon the
semantics of the element. The author has not followed the "write what
you mean, not what you want done with it" axiom (cite: TimBL). [N.B.
The example above is harmful in 99.999% of use cases. i.e. sometimes
this is acceptable, but in the majority of cases it's not. Prizes (my
own personal thumbs up) to people that can come up with acceptable use
cases].

The following is another example of class abuse:-

   <myelem class="blue purple list image diagram table"/>

Here, there are presentaional attributes, *and* overloading of
semantics. Yuck.

But, of course, it must be noted that the same things can be achieved
with elements. Indeed, this was not really the problem which I raised
in my original email [3] on the subject: it's something that class
aggrevates slightly due to the fact that it's so easy to come up with
new labels. But the two of the most important (i.e. "real") problems
are that new classes are difficult if not impossible to define (i.e.
attach semantics to), and that they are impossible to export (reuse).

There was some discussion on the WAI ERT mailing list about attaching
semantics to classes (q.v. [4], [5]) quite a while ago, started by
Len, who was always good on picking these issues out and addressing
them head-on. But because classes are not "accessible" per se (that
is, difficult to access within the conceptual information space), they
are difficult to address. XPath allows one to point into a document
*according* to the class marks, but it does not allow you to address
the class marks themselves as a separate resource (in the RDF sense,
not RFC 2396).

So NMTOKEN(S) style class values are either impossible, or very
difficult to address, and hence attach semantics to, or export. That's
a huge disadvantage, and one over which elements triumph; they can be
annotated directly in their schema definitions. But the disadvantage
of elements (attr: Al) is that they confine us to a 1.n dimensional
document space, and presentational styles are painted on this
hierarchy in a much higher-dimensional state (the numeric value of
which appears to vary according to Al's mood). Another practical
disadvantage that is always obvious is that elements themselves can't
be referred to easily, being QNames rather than URIs, so exporting
semantics even there is difficult. Not as difficult as classes, but
still difficult.

One answer that is often proposed (many sources, more or less
independently of each other, for example [6] by Dan Connolly), is that
class marks should be QNames. I discussed this briefly in my original
mail, and pointed out that this just made the problem worse:-

> Let's allow QNames in classes, and see what happens:-
>
>    <img class="xhtml:ul" src="abc.gif" alt="abc"/>
>
> What's going on there?

But really, what's going on there depends upon the actual *mechansism*
being used for @class in that language. There is no problem if an
RDF-style concatenation mechansism is used, because the URI:-

   http://www.w3.org/1999/xhtmlul

is quite distinct from the QName:-

   {http://www.w3.org/1999/xhtml}ul

Note that I came up with an XSLT stylesheet a while ago that processes
multiple QName values in attributes. CSS cannot be used to style
QNames in classes (cf. [7]), which is good, because it forces people
to create language that can be transformed using XSLT, and hopefully
make them more interoperable (able to be transformed to a wide range
of formats). A couple of languages that I'm working on utilise, or
have utilised that at some point in their respective developments.

The only problems come in where people don't define what their
particular class mechanism works, and the range of applications that
it has. *That* should be considered harmful. This comes under "define
your semantics" which is a key thread all the way through XML GL [8].

We (for some value of "we") need to produce materials that instruct
people how to make accessible class values, and use them in a way
which will be meaningful within the context of their use. Al appears
to have started on a mini crusade to do this, and I commend him for
that.

So basically, I've gone from saying "all classes are to be considered
harmful", to "localized class values are to be considered fairly
harmful, decentralized class values are fine, as long as their uses is
well defined, and people are educated as to a) the relative merits of
using them, and b) how to use them in an accessible manner, depending
on scope".

[1] http://lists.w3.org/Archives/Public/w3c-wai-gl/2001JulSep/0113
[2] http://lists.w3.org/Archives/Public/w3c-wai-gl/2001JulSep/0491
[3] http://lists.w3.org/Archives/Public/www-archive/2001Jul/0002
[4] http://www.w3.org/WAI/ER/IG/classuse
[5] http://lists.w3.org/Archives/Public/w3c-wai-er-ig/2000Aug/0035
[6] http://www.w3.org/2000/08/palm56/datebook.html
[7] http://lists.w3.org/Archives/Public/www-style/2001Jun/0082
[8] http://www.w3.org/WAI/PF/xmlgl

--
Kindest Regards,
Sean B. Palmer
@prefix : <http://webns.net/roughterms/> .
:Sean :hasHomepage <http://purl.org/net/sbp/> .

Received on Sunday, 12 August 2001 10:27:04 UTC