Namespacing CSS Classes and IDs in Your SharePoint Branding

This is a concept I’ve gone back and forth on over the last year or so. I think I’m ready to firmly come down on the “Yes, let’s do it” side of the argument.

Here’s the first definition of namespace from Wikipedia:

In general, a namespace is a container that provides context for the identifiers (names, or technical terms, or words) it holds, and allows the disambiguation of homonym identifiers residing in different namespaces.

Now, for you normal people out there, what that *usually* means is prefixing the names of something with a consistent value to help you assort things into groups. With most modern programming languages, you benefit from namespaces because it assures you that your code won’t stomp on anyone else’s. (At least it’s far less likely, as someone else can, of course, choose the same namespace.)

In my SPServices library, every single function resides in the SPServices namespace. That means that all the function names start with SPServices [dot]:

• $().SPServices.SPCascadeDropdowns
• $().SPServices.SPDisplayRelatedInfo
• $().SPServices.SPLookupAddNew
• etc.

You get the idea.

Even though my function names are most likely going to be unique – I’ve chosen rather long, descriptive function names on purpose – it’s possible that someone else could have a function of the same name. By putting all the functions into the SPServices namespace, I’ve reduced the possibility of function name “collisions” to almost nil.

But what does all of this have to do with CSS, you are probably wondering? Well in CSS, you can do essentially the same thing. Let’s say you are working on a project for Foo, Inc. with SharePoint. If you precede all of your custom CSS classes for Foo, Inc. with something like “foo-“, then you have reduced the possibility that there might be an existing CSS class with that name. You can do the same thing with unique ids for elements in your markup:

When we brand SharePoint, we’re building on top of an existing platform. If we were starting with a green field, we wouldn’t need to worry about CSS class collisions; we’d be able to pick and old naming that we wanted.  As an example, there is a class used in one of the out of the box Web Parts (I can’t recall exactly which one, but I think it may be the Summary Links Web Part) called “footer”. That’s a very garden variety name, and one that we might be tempted to create ourselves to style a page footer. As soon as we do, though, any of the Web Parts which have that class applied to it inherit whatever styling we’ve applied to our own footer class. I know for a fact that this can be a problem because I had to track it down more than once.

A safer class name would be “foo-footer”. It’s almost guaranteed to be unique, and we won’t stomp on an existing class named footer. This is a good approach overall. If you see a class which has a name starting with “foo-“, you know that it is specific to this client or application or branding scheme; whatever you’d like the namespace to indicate.

Microsoft does the namespacing thing pretty badly. Some of the out of the box CSS classes for SharePoint start with “ms-“; some don’t. Some classes start with a prefix which indicates something about the functionality in which they are used, like “srch-Icon” for a search icon or “UserCaption” for a caption for some user info. In SharePoint 2010, it got more complicated, as some classes start with “s4-” (one supposes that this means SharePoint 4.0, which is the internal version for SharePoint 2010 – it’s the fourth version of SharePoint) and some don’t. There doesn’t seem to be any real rhyme or reason to it other than the fact that different development teams thought about CSS classes differently. Take a look through core.css (SharePoint 2007) or corev4.css (SharePoint 2010) sometime and see if you can make heads or tails of it; I certainly can’t see much pattern in there. (Don’t even get me started on the whole inline vs. separately stored CSS issue. That’s a different smelly can of worms.)

Add to the out of the box CSS classes those which your developers are likely to embed in user controls, rendering templates, and the like, and there is even more possibility for a mess. To me, this is a clear indication of the fact that .NET’s abstractions teach developers, even Microsoft ones, not to think too much about what happens in the browser. They are told to use the .NET abstractions and all will be well when the functionality finally gets in front of the user. Well, not so much, and not so often.

When I see an abundant use of the !important tag in CSS (which I consider just plain evil), it is usually either due to the CSS creators novice use of selectors or due to a lack of namespacing. (If you find yourself wanting to use !important, think long and hard about why. It should be a very unusual exception, not the rule.) Another benefit of using the namespace approach is that you’ll have unique class names and won’t need to fight with the out-of-the-box styling, at least not as much.

Of course, there must be a downside to all of this, you probably are thinking. There are a few drawbacks, surely, but I think the benefits outweigh them. You’ll type a little bit more when you develop and apply your CSS, but I think that’s really the biggest cost. There will also be a few more characters going over the wire, but bandwidth gets better all the time. (If you’re still on a modem connection, then by all means, feel free to ignore this advice.)  All in all, this approach is just a good idea with little overhead.