CSS Practice: Pseudo-Namespaces in Complex Projects

Jens Meiert, March 21, 2007 / March 7, 2008.

This entry is filed under Web Development.

Working in complex projects or in projects that don’t provide a good overview of forthcoming page types and elements may require a defensive strategy for writing CSS. Such a defensive strategy strives for certain security measures to ensure better maintainability, and one tactic is CSS “pseudo-namespaces”.

This namespace concept is only roughly similar to that in XML. There are no “real” namespaces in CSS (thus the name “pseudo-namespace”).

Examples for CSS Pseudo-Namespaces

Special icons for certain links are a good start: You probably need or want to equip certain links (for example those for file types or for actions) with different icons. Assuming that there’s no reliable context (as with solely PDF links in your project’s sidebar), you could start with adding specific classes to these links:

<a href="" class="doc"></a>
<a href="" class="pdf"></a>
<a href="" class="ppt"></a>

This is fine (though you could cultivate that with an additional file class, for example). But considering that you a) don’t know what other page elements are to come, and/or b) don’t or won’t work alone on that project, you might want to make sure that there won’t be certain conflicts when e.g. a document preview module with a doc class gets introduced.

Note: You can of course address this issue with context dependent formatting (a.doc vs. div.doc), which is usually an advisable thing. But this may result in more code than is necessary, especially when it comes to more complex projects where you’d rather end up with dozens of much longer selectors, and it doesn’t solve the problem that you just don’t know who’s next modifying the code, either.

Well, a “pseudo-namespace” might help, for example:

<a href="" class="nf-doc"></a>
<a href="" class="nf-pdf"></a>
<a href="" class="nf-ppt"></a>

The nf- prefix is of course arbitrary and would mean “namespace [for] format”. The “n” is both a proposed name token for these namespaces as well as yet another security measure, meaning that it makes it even more unlikely that anyone else comes up with such an abbreviated name. Since the nf- prefix could be limited to links only, you’d need to set up a convention for that (and every other) namespace, and you should document it accordingly. (Like already mentioned, it’s a security measure so that anybody introducing another doc class won’t cause trouble, but you also want to avoid inconsistencies with ID and class names as well. Clearly a case for a little documentation.)

Beside the decreased risk of later conflicts, it’s now possible to write simpler CSS code:

.nf-doc {}
.nf-pdf {}
.nf-ppt {}

… and you could continue with the next elements, for example certain input element measurements:

.ni-s {}
.ni-m {}
.ni-l {}

… where ni could mean “namespace [for] input [elements]“, and where you can use very short and supposedly good class names (“small”, “medium”, and “large” input elements, where the names are rather intended to illustrate the relation of the affected elements than to be presentational – they’re not) without worries.

Pros and Cons of Pseudo-Namespaces

Hopefully I managed to demonstrate the concept without provoking too much focus on the detail (it will certainly do no good to discuss file class names and stuff). So here are the disadvantages of CSS pseudo-namespaces:

They require slightly more code conventions and
slightly more documentation since their (recommended) short form might irritate new project members;
tendentially, they endanger the CSS code’s consistency (“by design” since they’re primarily intended to prevent unforeseeable formatting problems).

On the other hand, these namespaces have some important advantages:

They enable more compact and more efficient style sheets;
they mean more safety when it comes to
- new page elements,
- foreign code injections, and
- new team members;
they preserve ID and class name semantics while
they also give more flexibility due to possible and not necessarily confusing reuse of useful ID/class names;
they’re finally cheaper though nonetheless assuring quality.

As a rule of thumb, the bigger and inscrutable a project is or tends to become, the more one’ll benefit from this namespace concept. It should be used carefully nonetheless.

Enjoy the most popular posts, probably including:

Comments

On March 21, 21:55 CET, Duluoz said:

You’ve hit on a great practice here. I’ve been using this practice for some time now myself, but never came up with a cleaver name.

The problem with creating a global style sheet to handle this possible problem of others injecting their classes, etc, is that you want that sheet to be first in inheritance. Therefore anything that gets defined later may over-ride your classes. However by using a psedo-namespaces technique you’ve eliminated that risk. I always set globals with “.g-” myself.

Very good!
On March 21, 22:13 CET, medyk said:

well.. there are real namespaces in CSS but they’re in CSS Level 3 and are not supported yet by most browsers
On March 21, 22:19 CET, Jens Meiert said:

Yah medyk, you’re right, though the concept’s different … that’s the effect of a missing “yet” Here I focus on current web dev, though.
On March 22, 8:56 CET, Robert Nyman said:

While I definitely understand the concerns and problems its trying to solve, I personally wouldn’t use such a practice.

Why? A couple of reasons:
- I think the class names lose some of their semantic meaning, with semi-abbreviations that doesn’t mean anything to people outside of the project.
- Maintainability. If you didn’t come up with all the pseudo-namespaces in the project yourself, you will need some index to look up what it actually means. I prefer code where you can read the class name and understand its meaning and usage without some kind of reference.
I’d rather say: go for proper class names with regular meaning, and if new members are introduced to the project, they can read a swift introduction. In the long run, if you stumble upon conflicts, tools like the wonderful Firebug add-on for Firefox can help you find and address them in a swift manner.
On March 22, 11:01 CET, Jens Meiert said:

Robert, that’s what I try to cover at “disadvantages”. You can of course address both issues by decent documentation and nonetheless “speaking” (and thus comprehensible) ID and class names. Of course, that’s always advisable.
On March 22, 19:04 CET, Nic Johnson said:

I’m the design lead on an intranet overhaul and we’ve been using a similar technique because of the technology we’re bound to. We’re using BEA’s Aqualogic Interaction product as a portal and there’s no way to guarantee the object ids and classes coming from various sources. So, to avoid conflicts, we simply use a certain prefix on all of our markup.
On April 4, 3:54 CEST, Ben Buchanan said:

It’s worth noting that microformats essentially operate on this basis Hence why the idea has been tossed around that all microformats should be pseudo-namespaced uf- (u for micro… iffy, but it works).

In your example I think the loss of readability far outweights the gains from shorter class names. You might save a byte or two, but you’ll waste developer time trying to remember what “ni-l” means in a year’s time
On August 21, 14:31 CEST, Jens Meiert said:

This post is also available in German at “Dr. Web” (liable for costs, though).

Jens Meiert