Jens Oliver Meiert

CSS Practice: Namespaces in Complex Projects

Published on Mar 21, 2007 (updated Feb 5, 2024), filed under , , (feed). (Share this on Mastodon or Bluesky?)

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 “pseudo-namespace”).

Examples for CSS 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 namespace can 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 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 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.

About Me

Jens Oliver Meiert, on November 9, 2024.

I’m Jens (long: Jens Oliver Meiert), and I’m a web developer, manager, and author. I’ve been working as a technical lead and engineering manager for companies you’ve never heard of and companies you use every day, I’m an occasional contributor to web standards (like HTML, CSS, WCAG), and I write and review books for O’Reilly and Frontend Dogma.

I love trying things, not only in web development and engineering management, but also in other areas like philosophy. Here on meiert.com I share some of my experiences and views. (I value you being critical, interpreting charitably, and giving feedback.)