Using CSS classes as decorators - a good pattern?

Question

I've been building a web-app with a fairly complex GUI - many small elements alongside eachother and within other elements that need various behaviours (dragging, clicking, but context-sensitive).

My code tends to work like this:

controls start out as html tags

<li>

then I add classes to the tag

<li class = 'static passive included'>

some classes might be for css styling to affect appearance

.static {background: blue; float: left;}

while others are acted upon by jQuery to give behaviour for the associated DOM events

$("#container").delegate(".passive", function {onclick : //do-stuff})

and others might be picked up by normal javascript when scanning the document, eg. collect the text values of all nodes with the 'included' class. So certain DOM elements are GUI objects which implement classes definted through a combination of css and jQuery.

My question is, is this a good way to work? And also are these really 'decorators' - they certainly 'add additional responsibilities to an object dynamcially' but I'm not sure about that term. Finally, do you use this pattern in your own sites?

Answer 1

I think what you're doing is dead on. The benefits of using classes, as opposed to making up attribute names, is that you can still validate the page. No modern browser will get upset about undefined CSS classes, and they are trivial to use with jQuery, et al.

Answer 2

Classes are ok, but I would consider HTML data attributes as well. Oftentimes, a class name simply doesn't convey enough information to enable the appropriate javascript hooking (without hard-coding element id names). HTML data attributes provide another way to classify and select elements and attach data to them for auxiliary purposes, like JavaScript-based enhancements.

With jQuery's, HTML data attributes are equally as simple to use as CSS classes.

Answer 3

Hmmm... yes and no. It is ok to do things like that, but classes really should be named to show what is common about the data within them. If there isn't anything common between two tags then there is every chance that the requirement of the classes will diverge later.

Example requirement:

• all navigation items will be white on blue, helvetica with a margin of 1px
• all comment descriptions will be white on blue, arial with a margin of 4px and a padding of 2px

Is it better to give them both a class of whiteonblue where

.whiteonblue {
  font-color: white;
  background-color: blue;
}

or to have repeated code

.navitems {
  font-color: white;
  background-color: blue;
// more css
}

.commentdesc {
  font-color: white;
  background-color: blue;
// more css
}

I argue the latter. There is no connection between navitems and commentdescs and thus the likelihood is that when one changes, the other will not. Do you really want to have to search through the html for the right class, remove the class, add a new one (whiteonred) before going to the CSS at that point? I don't.

Likewise Javascript. Maybe you want the same thing onclick in the initial design but the likelihood is that if one changes, the other one will not. It's easy enough to say

$(".navitems, .commentdesc")

If you stick to this policy, I suspect you'll find that your question goes away pretty quickly, but where it doesn't then what you're doing is fine.