Jens Oliver Meiert

CSS Practice: Pseudo-Namespaces in Complex Projects

Post from March 21, 2007 (↻ June 12, 2021), filed under .

This and many other posts are also available as a pretty, well-behaved ebook: On 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 rests on certain safety measures to ensure better maintainability, and CSS “pseudo-namespaces” are such a measure.

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

Examples for CSS Pseudo-Namespaces

Special icons for links are a somewhat artificial example yet also a good start: Assume you want to equip certain links (for example those for file types or actions) with different icons. Given that there’s no reliable context (as with, say, PDF links in your project’s sidebar), you could add specific classes to these links:

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

You can certainly address this issue through context-dependent formatting (a.doc vs. div.doc). Yet this may result in more code than is necessary, especially when it comes to more complex projects where you’d end up with dozens of much longer selectors; it doesn’t solve the problem that you don’t know who’s modifying the code next, either.

A “pseudo-namespace” could solve this:

The nf- prefix is a little arbitrary, in this case meaning “namespace [for] format.” The “n” is both a proposed name token for these namespaces as well as yet another safety measure, meaning that it makes it even more unlikely that someone else comes up with such an abbreviated name. Since the nf- prefix could be limited to links, you’d need to set up a convention for that (and every other) namespace, and document these accordingly. (As mentioned, it’s a safety measure so that another person introducing a doc class won’t cause trouble, but you also want to avoid inconsistencies with ID and class names. 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 other types of elements, for example certain input element sizes:

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

…where ni could mean “namespace [for] input [elements],” and where you can use very short yet still understandable class names (“small,” “medium,” and “large” input elements, where the names are intended rather to illustrate the relation of the affected elements than to be presentational) without much risk.

Pros and Cons of Pseudo-Namespaces

I hope I managed to demonstrate the concept without provoking too much focus on the detail (it won’t be meaningful here to discuss file class names and stuff). So here are the disadvantages of CSS pseudo-namespaces:

  1. They require more code conventions and therefore more documentation since their short form might confuse new project contributors;
  2. they may threaten the CSS code’s consistency (“by design” since they’re primarily intended to prevent unforeseeable formatting problems).

On the other hand, namespaces have some important advantages:

  1. They mean more safety when it comes to
    • new page elements,
    • foreign code injections, and
    • new team members;
  2. they preserve ID and class name semantics while
  3. they also give more flexibility due to now possible and not necessarily confusing reuse of useful ID and class names.

The bigger and the more inscrutable a project becomes, the more one benefits from this namespace concept.

Tweet this? (If it changed your life, you delight me with a coffee.)

About Me

Jens Oliver Meiert, on April 29, 2020.

I’m Jens Oliver Meiert, and I’m an engineering manager and author. I love trying things, sometimes including philosophy, art, and adventure. Here on meiert.com I share some of my views and experiences.

If you have questions or suggestions about what I write, please leave a comment (if available) or a message.

Comments (Closed)

  1. On March 21, 2007, 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 clever 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!

  2. On March 21, 2007, 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 😊

  3. On March 21, 2007, 22:19 CET, Jens Oliver Meiert said:

    medyk, right, though the concept is a little different… I missed a “yet” 😉 I’m focusing on current web development practice, then.

  4. On March 22, 2007, 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.

  5. On March 22, 2007, 11:01 CET, Jens Oliver Meiert said:

    Robert, that’s what I hoped to cover with the disadvantages. You can address both issues by documentation and employing “speaking” (easier to understand) ID and class names.

  6. On March 22, 2007, 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.

  7. On April 4, 2007, 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 😊

  8. On August 21, 2007, 14:31 CEST, Jens Oliver Meiert said:

    This post is also available in German at “Dr. Web”.

  9. On December 12, 2008, 15:08 CET, Neal G said:

    This is sort of a poor example for this considering you can already select pdf, doc, and ppt files with CSS3 selectors - i.e. a[href$=”.pdf”]. I like the idea, just not the example.

  10. On December 12, 2008, 15:28 CET, Jens Oliver Meiert said:

    Neal, true (I wrote about CSS 3 in that context in 2005). From that angle the examples are not ideal.

  11. On June 24, 2009, 14:39 CEST, Clément said:

    I prefer namespacing using a parent class. For instance:

    
    .context1 h1 a{
     color:red;
    }
    .context2 h1 a{
     color:green;
    }
  12. On December 8, 2010, 2:51 CET, Rebecca Cannon said:

    We need namespaces for a large project with many embedded includes, and embedded namespaces would make it a lot easier.

    eg CSS having the ability to do parent classes. EG

    .ns {
    .doc {}
    .pdf {}
    .nppt {}
    }

  13. On January 6, 2011, 23:18 CET, Jason said:

    I’ve done something similar for creating complex widget libraries for web apps. I experimented with this method, and it seemed to work, but I’m not sure it’s technically valid:

    <div class="UiWidget/MenuBar">
    <ul class="UiWidget/Menu">
    <li><a href="#">Item</a></li>
    </ul>
    </div>
    

    styled in CSS:

    
    .UiWidget/MenuBar {
        background-color:#333;
    }
    
    .UiWidget/Menu {
        float:left;
    }
    

Read More

Have a look at the most popular posts, possibly including:

Cover: The Web Development Glossary.

Perhaps my most comprehensive book: The Web Development Glossary (2020). With explanations and definitions for literally thousands of terms from Web Development and related fields, building on Wikipedia as well as the MDN Web Docs. Available at Apple Books, Google Play Books, and Leanpub.

Stay up-to-date? Follow me by feed or on Twitter.

Looking for a way to comment? Comments have been disabled, unfortunately.

Found a mistake? Email me, jens@meiert.com.

You are here: HomeArchive2007 → CSS Practice: Pseudo-Namespaces in Complex Projects

Last update: June 12, 2021

Professional frontend developers produce valid HTML and CSS.