Via Ajaxian comes this article discussing the merits of custom XML attributes instead of over-loading the class attribute for functional purposes.
I came to this same realization many moons ago when first discussing how to enable dragging of SVG elements around the browser window. At the time, I used custom XML attributes (dragx, dragy) as a means of easily tracking the dragged position of an entity instead of having to do some horrendous parsing of SVG transform attribute strings. I marvelled at this technique (which I called "DOM Sticking" because I didn't know what else to call it) for its ease of attaching metadata to elements within an XML language.
At the end of that Drag SVG article, I had pondered turning my demo into a library and thought of using a class (class="draggable") to indicate whether an entity is draggable. But when I finally sat down to turn it into a JS library, I realized how painful it would be to parse the class attribute too. In the end, I finally ended up using attributes in a custom XML namespace, almost as easy as custom XML attributes (drag:enable="true").
Shouldn't that make both the "XML nazis" and the CSS purists happy?
By the way, here's the DRAG SVG DEMO in case you missed it the first time around. Works in Opera 9+, Firefox 1.5+ and IE+ASV.
I’ve long been a big fan of using attributes in custom namespaces for these purposes (and I like the way you seem to be breaking down the namespace according to the functionality). I’d never really used “class” for these purposes, but I’d like to note that class is *not* just for the use of CSS. Both the HTML and SVG specifications explicitly state that “class” is also for “general purpose processing by user agents.” It’s even included in SVG Tiny 1.2 for this, even though CSS is not supported. I wouldn’t use it for storing formatted data that needs extensive parsing, but for I do use it for assigning categorical information to the element (almost never for CSS).