Re: Classes Considered Harmful

Well, you see, I had this dog, we named him "blue" cause he got into the
blue paint one time as a pup and we like to never got the color out; so I
made up a website to him when he died, with his quotes all given as <div
class="blue">. I never meant nothing by it though. </grin>

Seriously, I find when I'm teaching people about CSS (I'm doing a chapter
about it for an upcoming Wrox book), I recommend the same rules as I do for
schema development -- class names are nouns, unless they involve Microsoft
behaviors, in which case they could be verbs; this particular conundrum was
one of the reasons I've always felt ambivalent towards using CSS for
behavior constructs.

Classes by themselves were meant as a mechanism for adding presentation to
HTML markup, both as a means of getting out of the mode of HTML as
presentation and as a way of assigning an alternate meta-data structure to
the language. CSS preceded XML by about two years, and it was in fact the
deficiencies of CSS as a meta-language that spurred the creation of XML in
the first place.

Having said that, I don't think CSS classes are harmful at all, save in
their occasional abuse. One purpose of classes is to create a media
presentation layer that overlays the logical structure of HTML or XML.
Ideally, the most consistent form of CSS is as an adjutant layer to XML-FO,
but given that there are very few native FO browsers even now, CSS is an
acknowledgement to reality. The class mechanism functions as a means of
adding indirection, so that it becomes possible to utilize the same
stylistic devices across multiple tags. For instance, if I have a class
called commentary that sets all commentary as sans-serif gray text:

<style>
.commentary {font-family:sans-serif;color:gray}
</style>

then I can rely upon inheritance to give me the proper attribution even over
distinctly different elements:
<h1 class="commentary">Some Notes</h1>
<p class="commentary">Having said that, I don't think CSS classes ...</p>

The one thing that I do wish would occur is for the declaration of CSS in
XML itself:

<style>
    <class name="commentary" font-family="sans-serif" color="gray"/>
</style>

It may be more verbose, but it is easier to generate programmatically (and
it is increasingly consistant with languages like SVG).

-- Kurt Cagle

----- Original Message -----
From: "Sean B. Palmer" <sean@mysterylights.com>
To: <www-html@w3.org>
Cc: "Al Gilman" <asgilman@iamdigex.net>
Sent: Sunday, August 12, 2001 7:14 AM
Subject: 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 12:44:23 UTC