Omicron Llama

Coding all day, every day.

Applying CSS Customisations in SharePoint – A Technique

Having done numerous branding exercises in SharePoint over the past few years, I have had the opportunity to try out various different methods of both loading CSS into your environment, and also the actual writing of the CSS.

I have previous covered methods of loading CSS, and spoke about it in a video, which you can view here: Video – SharePoint Branding with CSS Customisations.

In this post I’m going to show a technique for writing CSS that I’ve recently came across, that definitely can help to improve both legibility of your CSS files, but also the reusability and flexibility of the classes you customise.

My first couple of branding attempts in SharePoint (back in the 2007 days) were examples of what I’d describe as ‘blanket’ branding. Each element I wanted to change, I would select in Firebug or Chrome’s DOM explorer, find out the CSS that applied whatever was there, and write a line of CSS to change it.

This quickly resulted in a rapidly growing CSS file that would apply a single look and feel across the entire site, and proved very difficult to modify later on.

Here is a method that makes your specific CSS changes much more ‘modular’, in that all you need to do to apply the specified change is to (somehow) wrap the selected element in a DIV or SPAN with a particular class.

Here’s an example of why this would be useful. Let’s say you wanted to have two List Views on a page, but you wanted one to have a different title bar colour to the other. Now the title bar is covered by CSS class ‘ms-standardheader’. If you apply a style change to this class, it will affect both (and all other) instances of the List View on the page (and all other pages!).

If you were to duck into the HTML Editor for this page, and see how the two ListViews have been added:

What we want to do is to wrap the two list views each inside a DIV container, and apply a different class to each. We’ll call one ‘blue’ and one ‘green’.

Now we want to write and deploy some CSS. You can use whatever method you’re used to, for this I’m using my favourite method of a DelegateControl to load up an ASCX with CssRegistration. See the video linked above for how to do this.

The CSS I’ve written for this example looks like this:

As you can see, this is a really straight forward background colour change to each element. I’m using the CSS wrapper that we added to the content above to contain the ms-standardheader class, and applying different style changes to each ‘wrapped’ element.

Get your CSS into the environment and see the results:

OK, not the most accessible example 🙂 But you can see the premise. I have a usable CSS class that I can use to set the colour of any List View title bar on a page.

You can extend this technique to entire pages, by adding an overall ‘wrapper’ to the page layout around the content fields, or even the entire site by modifying the master page and adding a ‘wrapper’ around the content placeholders.

Let me know if you use this technique, or if you have other techniques that you typically use that you’d like to share.

5 thoughts on “Applying CSS Customisations in SharePoint – A Technique

  • sympmarc says:

    I tend to use names that are more functional than indications of the styling. For instance, rather than blue or green, highlight-header and normal-header. That way when the branding changes, the classes still make sense (hopefully).

    I also always use a prefix for every project to namespace the classes. So if this is a project called “foo”, the classes would be foo-highlight-header and foo-normal-header.

    Microsoft is horrible about namespacing CSS classes (“footer”, anyone) and so are many plugins and third party tools. By namespacing everything (including scripts), collisions are far less likely.

    M.

    • James Love says:

      Namespacing is a great idea. I have also used this in more recent projects, so that css classes are something like ‘customer-newsarticles-pageheader’, and wrapping this around the field control for the title in the page layout.

  • Very good post. I know this wasn’t the point of your post, but I was wondering why you tend to load the CSS with a delegate control. Why not just add it a header content placeholder on the page? I’m just asking because I’m struggling with this myself. I want it to to be easily reusable and I actually started with a delegate control, but then switched it because the delegate control seemed like overkill.

    • James Love says:

      Just personal preference. I know with a DelegateControl I can switch it on or off at will (if the Feature contains only the delegate), and I can inject the CSS without modifying any page layouts or masterpages with this method.

      Basically, which this method I can just upload a single feature that can apply a basic ‘branding’ without modifying any other site artefacts. I can also control the load order by modifying the Sequence attribute of the Control element, again without modifying any site artefacts.

      It’s not sandboxable but I haven’t had much demand for solutions that have that constraint (yet) 🙂

    • Those are good reasons. I may switch it back to a delegate control for my current project as well. I’m trying to develop an internal best practice approach for my company and I want it to be right. Thanks!

Leave a Reply to sympmarc Cancel reply

Your email address will not be published. Required fields are marked *