Multi-valued CSS class attributes

A reader named Jemisa wrote last week with this proposal:

Just another proposition for
<pre class="code" lang="python">
...
</pre>
Why not use
<pre class="code python">
...
</pre>
I know it's less "semantic" than your experimental attribute, but it might be useful (to style python code with different color than perl code for example)

This is a great idea which I at first completely failed to understand. My objections were twofold. On the CSS front, that you'd want to be able to style 'code' things independently of 'python' things. And on the XPath search front, that you'd want to be able to search independently.

But then Jim Roepke sent me the exact same proposal, and set me straight on the first point:

You can specify more than one class name in the class attribute.... you could say:
<pre class="code python">...</pre>
I don't know if your XPath stuff can handle that, but it's a valid way to specify the class of an element. In terms of CSS, both the code and python classes will be applied to the element.

OK. Now I finally get it. I can use XHTML like this:

<pre class="code python">
import re
import sys
...
</pre>
 
<blockquote class="personQuote StefanoMazzocchi">
"..."
</blockquote>

along with CSS like this:

blockquote.personQuote {
font-style: italic;
}
blockquote.StefanoMazzocchi:after {
content: 
  url(http://www.oio.de/public/web/stefano-mazzocchi.jpg)
}
pre.code {
border-style: solid;
border-width: thin;
padding: 10px;
}
pre.python:after {
font-weight: bold;
content: 
  url(http://www.python.org/pics/PythonPoweredSmall.gif);
}

This looks really promising. On the XHTML front, legal and even elegant. No extra namespace baggage. It's easy to write this way by hand, and tools that give people control over CSS styles could easily support this method if they wanted to.

On the search front, it's less than ideal. But the difference boils down to substring matching versus string equality. On a small corpus of XML content -- i.e., your own blog -- this won't matter, as I've already demonstrated to my own satisfaction. And on a larger corpus -- like the one I'm assembling now -- I'm presuming a database with indexing that can make a contains() query roughly as efficient as an equals() query.

Thanks, Jemisa and Jim! At the moment this looks like the winning strategy. I can't dive into this for a few days yet, but I'll watch for further feedback in case there's something else I've missed.

Former URL: http://weblog.infoworld.com/udell/2004/02/09.html#a913