Color Codes in SharePoint SPColor Files MUST Be All Caps

With the new world of branding a tenant on Office 365, styling the suite bar and using a theme (aka Composed Look) can take you pretty far toward improving the user experience.

A Composed Look is made up of (potentially):

  • A master page – generally either Seattle or Oslo
  • Theme URL – the spcolor file to use for common classes in a SharePoint page
  • Image URL – an image to use as the background for pages
  • Font Scheme URL – spfont file to use for common classes in a SharePoint page
  • Display order – simply where in the list of Composed Looks yours is displayed

Composed Look Settings

I won’t go into all the details about how this works, but each setting above is somewhat optional: you can use an existing spcolor file, for example, but create your own spfont file. If you want to understand all the mechanics, check out Benjamin Niaulin’s article Step by Step: Create a SharePoint 2013 Composed Look


Change the look

Here’s a quick tip about spcolor files. I was tearing my hair out over the last few weeks trying to figure out why sometimes my iterations of an spcolor file were working and other times they weren’t. By not working, I mean that the Composed Look would simply disappear from the Change the look page. I’d revert to my last working version and slowly inch forward again.

It turned out to be something silly and obvious – once you know it!

All of the color codes in the spcolor file MUST be all capitals. So, for instance, this:

would not work, but this:

would. That was *not* easy to spot, but spot it I did.

Don’t let this one bite you; I hope that your Binglage has led you here for a solution and this helps…


Namespacing CSS Classes and IDs in Your SharePoint Branding

A graphical depiction of a very simple css doc...

Image via Wikipedia

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]:

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.

Review of ‘Professional SharePoint 2010 Branding and User Interface Design’

When Randy Drisgill (@drisgill) offered me a free copy of the new book entitled Professional SharePoint 2010 Branding and User Interface Design he wrote with John Ross, Jacob J. Sanford, Paul Stubbs, and Larry Riemann, I knew I’d like it. (There’s the disclaimer: I got a free book out of this.) I know Randy and John well enough to know that they are wicked smaht (as we say in Bahston) about branding SharePoint and they are also wicked funny. Those are two good skills to bring to a book on a potentially dry technical topic, at least to me.

What I didn’t expect is how much of the book I’d actually read. It seemed like a slam dunk: a quick skim, a few pithy comments, and I’d have a nice new shiny book on my shelf. As I started flipping through it, I found myself stopping at more and more places and reading whole sections. This book has so much good information in it that anyone, regardless of their skill level, is likely to do the same thing.

Not only will the book help someone who wants to do good branding on top of SharePoint 2010, it will also help them understand a lot about SharePoint itself is built to support good branding techniques. And that goes for someone who’s just coming to SharePoint for the first time as well as a smarty-pants like me. There’s truly something for everyone.

I’m not usually a “learn by reading” type of person (I prefer to “learn by doing”, hitting my head against it until I get it), but this book is well suited to someone who will want to read it from cover to cover. The prose is loose enough to hold your interest, the examples are clear and hold together throughout the book (a rare thing, IMO), and the technical level is just right no matter your skill level. It won’t be obtuse to the beginner, nor does it pander to the expert.

If you have anything to do with branding SharePoint, this book is a must have for your bookshelf. I know that I’m going to be referring to it going forward, and so will you when you grab it for yourself. Bravo, guys.

SharePoint and Your Mobile Strategy: Be Sure to Have One!

These days, if you have a site running in SharePoint the odds of someone coming to it with a mobile device are increasing extremely rapidly. This is certainly true if you have an Internet-facing site, but also highly likely even for corporate Intranets.

For this post, I’m going to pick on my friends at the Boston Area SharePoint Users Group (BASPUG) and then I’m going to help them fix the problem.

If you go to the home page for BASPUG on an iPhone (and probably any device that declares itself as a mobile one), you get a very basic WAP-like view from SharePoint 2010.

photo 3

And scrolling down to the bottom of the screen:

photo 2

This is nothing like the actual home page of the site, with its useful and interactive content:


Even if I scroll down to the bottom of the mobile view on my iPhone, I can’t switch to the full view of the site. In case you don’t know, the iPhone runs Safari, which is a fully functional browser. The screen is just smaller and you need to pinch and zoom a bit to view full-sized Web sites. So I’d actually rather switch to the full site so that I can read what I know is there, but I can’t.

So my point here isn’t that the mobile view in SharePoint 2010 sucks. Sure, it’s probably not what you want out of the box, but the engine is there and it’s fixable. My point is that you have to have a mobile *strategy* for your SharePoint installation.

In many cases, the best strategy will be to just turn it off. The mobile view above doesn’t enhance my experience, it ruins it. That’s not the starting point that you want to have for your users. IMHO, it’s better for them to have to navigate the full site in a cumbersome way than to not be able to read anything useful.

So be sure to have a strategy for mobile, even if it is to admit that you don’t have one. Put it into your deployment plans so that you don’t forget about it later. Revisit it when you have to or have the time to deal with it after launch. But *don’t* forget about it.

In looking around for how to turn the mobile view off in SharePoint 2010, it was no surprise that I came upon a blog post from my pal Randy Drisgill, SharePoint branding guru, which explained it: SP2010 Branding Tip #6 – Mobile Browsers. You can edit the compat.browse file in

C:\inetpub\wwwroot\wss\VirtualDirectories\[Your Web App Here]\App_Browsers\compat.browse

to change the settings for specific browsers. Read @drisgill‘s post for the details.

SharePoint 2007 (MOSS) Branding CSS Tricks

Having done branding (meaning applying custom CSS to change colors, fonts, etc.) to quite a few MOSS Site Collections, I wanted to offer a few tips and tricks to keep things clean and easy to maintain.  I’ve mentioned some of these tips before, but I wanted to get them all into one post so that they could be more useful.

  • Never edit default.master; take a copy and name it something logical, like myportal.master.  You might need default.master again, and once you customize it, you are out of luck.
  • Edit your myportal.master as you need to in SharePoint Designer.  I usually limit these edits to images that I want on every site in the Site Collection and changes to Web Part Zones that should apply across the board.
  • Attach a custom CSS file to your master page.  I store this custom CSS in the Style Library folder and I name it the same as my master page, e.g, myportal.css.  Storing it in the Style Library folder means that it will be backed up with the rest of the Site Collection.  (You have set up daily backups of your Site Collection, right?!?!?)
  • Definitely, definitely, definitely install the Internet Explorer Developer Toolbar.  This invaluable tool does many things, but most importantly for this exercise, you can use the Find / Select Element By Click option to figure out what CSS classes you want to override.
  • Only add classes and elements into the custom CSS that you are using to override the default.  If you copy and paste from core.css (the default CSS file) using Designer, you will get the entire class’s definition.  This will make your custom CSS much bigger than it should be and more confusing to maintain.  Here’s an example…If you copy from core.css, you might have:

    .ms-globalbreadcrumb {
        font-size: 8pt;
        text-align: right;
        background-color: #FFFFFF;
        padding: 2px 10px 2px 5px;

    If you only want to change the background color, then you should have:

    .ms-globalbreadcrumb {
        background-color: #FFFFFF;

    since this is the only thing that you are overriding.

  • Be sure that you only include each class once in your custom CSS.  If classes exist more than once it will cause you problems because you will probably change the first one and then the second one will override your override!
  • Try to keep the CSS classes in an order that generally goes from the top left of the page to the bottom right, just like the way you read a page.  It makes finding things easier and is worth the little bit of extra effort it takes.
  • Comments are good!
  • Don’t forget to check in a major version of your master page and approve it, and check in your custom CSS (no need to approve here).  If you don’t, you will see all of your changes, but everyone else will be asking you why you haven’t changed anything!


Technorati tags: , , , ,