SharePoint Branding – How CSS works with master pages – Part 3

Welcome to the third article (or is it a manifesto?) in my series on SharePoint branding. In this article, we continue examining methods to incorporate CSS files into master pages for clever branding. In my first article of this topic, I discussed what I think is the main issue with SharePoint branding – APPLICATION.MASTER and CORE.CSS. The previous article to this one, examined 5 methods to deal with the trial and tribulations of APPLICATION.MASTER and CORE.CSS behavior. So, to recap where we got to, let’s re-examine the original scenario and then look at the summary of the 5 different several methods with their relative merits and issues.

The Scenario

Like many organizations, my client had an existing corporate branding standard that was used in a non SharePoint environment and naturally enough, they wanted their SharePoint site to look like this branding. This was for a fully featured intranet/extranet that utilized most of the MOSS2007 features such as

• Document collaboration
• Infopath Forms Services
• Workflow
• Enterprise Search
• Excel services
• Business Data Catalog
• Custom web parts
• Event Handlers

It was *not* a public site at all.

Initial investigation soon concluded that we would need a custom master page. DEFAULT.MASTER didn’t quite have the design flexibility that was required. In fact the branding requirements were actually closer to some of the built in master pages such as BLUEGLASS.MASTER, since this was for intranet purposes, particularly collaborative document management, those master pages are unsuitable.

Other major requirements included mandatory consistency of branding across the entire farm. This meant that we had to deal with the APPLICATION.MASTER issue. Additionally, different semi-autonomous divisions within the client’s organisation wanted to be able to modify the corporate brand in accordance with existing branding policy (mainly colours/skinning) while maintaining the existing structural look and feel.

Additionally, as well as the corporate branding, there was another, very different branding which was used as part of a communications plan for some organizational change stuff. This had a deliberately different look to the rest of the site, yet the web designer had been clever when this design was created. They were able to completely rebrand the look and feel of the additional branding just through additional CSS and not wholesale HTML structural changes.

So, really, we had two general classes of sites. ‘Standard’ corporate sites and the custom branded ‘Organisational Change’ site.

The type of MOSS environment this was to be applied to was a medium to large SharePoint farm with three web front end (WFE) servers, and there were several SharePoint web applications and site collections in the farm that needed this branding. Further down the track, there was to be other SharePoint farms in different offices around the world with localized language requirements.

The final requirement (the one that complicated things) was that many of the CORE.CSS styles needed to be overridden to ensure the branding was correct.

Summary of CSS methods

Method	Advantages	Disadvantages
SharePoint:CSSRegistration	– Easy to implement	– Does not overrides core.css – Does not work with _layout pages
Master Page Settings	– Easy to implement – Overrides core.css – Works on _layout pages	– Can only be used once – Has to be set up for each site
<link> method	– Set in master page once – Overrides core.css	– Precludes "Master Page Settings" CSS override – Does not work with _layout pages
Michael’s webcontrol	– Set in master page once – Overrides core.css – Works nicely with "Master Page Settings" CSS override	– Does not work with _layout pages – core.css as the first CSS can be problematic
My webcontrol	– Set in master page once – Overrides core.css – Works nicely with "Master Page Settings" CSS override – core.css is not the first stylesheet in the list – allows choice as to what css overrides core.css	– Does not work with _layout pages

Now for many SharePoint logical architectures, these methods will likely work well. Unfortunately in my situation each had enough drawbacks that I kept looking. So next stop: SharePoint Themes.

Over-riding CSS – SharePoint Themes

In my humble opinion, when you examine themes, it smells a little like legacy WSS/SharePoint 2 functionality carried over and now adds to confusion rather than clarifies. This is purely a hunch of course, but given the way themes have to be installed, and their scope across the farm, suggests to me that it may become a legacy feature going forward.

Why do I think this? Well, the official purpose a SharePoint theme is for ‘skinning’ a site, but at the end of the day, a theme is just another CSS file, only implemented a different way. Being CSS, you can define any style you want here, not just the ones related to colour. Furthermore, the styles defined in themes can be used in any other other CSS files too.

Okay, so it is essentially another form of CSS file… then what is the difference between this and the other methods CSS I have outlined?

Well, for a start, theme CSS files live in a sub-folder of on the server:

C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\THEMES

So, this is a location on the web front end server/servers, whereas with the other methods, the CSS files reside inside a document library of a site collection. I believe that document library is a better choice because you have all those niceties like versioning, approvals and recycle bin, etc. If you have a farm of WFE servers, you would have to add your theme to each server and hope no mistake was made.

On top of being in every WFE server folder, just making a CSS file and dropping it in here is not enough either. Examining one of the pre-supplied themes shows that a theme consists of CSS files, an INF file, and of course, the images referred to by the styles. The two CSS files are called THEME.CSS and MOSSEXTENSION.CSS. (When you apply a theme to a site, MOSSextension.css is appended to the bottom of your theme.css)

The INF file is always the name of the theme folder, eg

<path to sharepoint>\12\TEMPLATE\THEMES\CITRUS contains CITRUS.INF

So you create a folder, add the CSS, INF and images, and finally, you then have to tell SharePoint about it. This is done by modifying a single XML file called SPTHEMES.XML.

SPTHEMES.XML can be found in:

C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS\1033

A typical entry will look like:

<Templates>

    <TemplateID>PimpMySharePoint</TemplateID>

    <DisplayName>Pimp me</DisplayName>

    <Description>A pimped sharepoint</Description>

    <Thumbnail>images/thpimp.gif</Thumbnail>

    <Preview>images/thvpimp.gif</Preview>

</templates> 

So let’s look at an example.

I have taken a copy of the CLASSIC folder under THEMES, info a folder called PIMPMySharePoint. I’ve then renamed CLASSIC.INF to PIMPMYSHAREPOINT.INF and added this theme to SPTHEMES.XML.

I then run IISRESET and open up my site collection. Go to Site Actions->Site Settings and choose "Site Theme"

Now you should see your "Pimp SharePoint" theme listed

Click apply and re-examine the page. You will see that the look and feel of the site will have changed.

Now examine the HTML source in the browser. You will see something like

<link rel="stylesheet" type="text/css" href="/_layouts/1033/styles/controls.css?rev=EhwiQKSLiI%2F4dGDs6DyUdQ%3D%3D"/>

<link rel="stylesheet" type="text/css" href="/_layouts/1033/styles/HtmlEditorCustomStyles.css?rev=8SKxtNx33FmoDhbbfB27UA%3D%3D"/>

<link rel="stylesheet" type="text/css" href="/_layouts/1033/styles/HtmlEditorTableFormats.css?rev=guYGdUBUxQit03E2jhSdvA%3D%3D"/>

<link rel="stylesheet" type="text/css" href="/_layouts/1033/styles/core.css?rev=5msmprmeONfN6lJ3wtbAlA%3D%3D""/>

<link rel="stylesheet" type="text/css" id="onetidThemeCSS" href="/sites/ft1/_themes/PimpSharePoint/Pimp1011-65001.css?rev=12%2E0%2E0%2E6007"/>

Note that the theme (in bold) is rendered after core.css.

How did this happen?

You should already be familiar with SharePoint:CssLink and SharePoint:CssRegistration webcontrols via my previous articles. Behind the scenes to all of this, the theme is rendered via an additional control called the <Sharepoint:Theme> in the master page. Here is DEFAULT.MASTER source code that produced the above output

<Title ID=onetidTitle><asp:ContentPlaceHolder id=PlaceHolderPageTitle runat="server"/></Title>

<SharePoint:CssLink runat="server"/>

<SharePoint:Theme runat="server"/> 

If you look carefully at the above source code, you will see that the only reason that the theme has overriding CORE.CSS is because the SharePoint:Theme control is listed after Sharepoint:CSS. If you reverse the order of the two controls, as expected the order of the theme is changed. In the example below, I took a copy of DEFAULT.MASTER and made the following modification:

<Title ID=onetidTitle><asp:ContentPlaceHolder id=PlaceHolderPageTitle runat="server"/></Title>

<SharePoint:Theme runat="server"/>

<SharePoint:CssLink runat="server"/>

and the resulting HTML is now reversed with CORE.CSS once again last.

<link rel="stylesheet" type="text/css" id="onetidThemeCSS" href="/sites/ft1/_themes/PimpSharePoint/Pimp1011-65001.css?rev=12%2E0%2E0%2E6007"/>

<link rel="stylesheet" type="text/css" href="/_layouts/1033/styles/controls.css?rev=EhwiQKSLiI%2F4dGDs6DyUdQ%3D%3D" />

<link rel="stylesheet" type="text/css" href="/_layouts/1033/styles/HtmlEditorCustomStyles.css?rev=8SKxtNx33FmoDhbbfB27UA%3D%3D" />

<link rel="stylesheet" type="text/css" href="/_layouts/1033/styles/HtmlEditorTableFormats.css?rev=guYGdUBUxQit03E2jhSdvA%3D%3D" />

<link rel="stylesheet" type="text/css" href="/_layouts/1033/styles/core.css?rev=5msmprmeONfN6lJ3wtbAlA%3D%3D" />

Thus, although you will read that themes are used to say, "re-skin the layout of a site", in reality, it is the order of the application of CSS files that determine what parts of a site a theme will modify. Put in a different way, you add whatever you like to the theme CSS files and it will act like any other CSS, except it gets rendered last by default.

Heather notes that themes have the same benefit as using "Master Page Settings" to override CORE.CSS. That is, they also apply to _layouts pages and affect APPLICATION.MASTER. The only reason that they work here is because the APPLICATION.MASTER master page used for _layout pages has the SharePoint: Theme webcontrol in its source code.

A gotcha with this method is that themes are per farm. Since they reside on the web front end server, my "Pimp Sharepoint" theme is available to any site in the farm. What’s more, if I modify the theme here, all sites are modified. This can be good but is equally going to catch you out as your SharePoint farm grows.

Another gotcha! Do not for a second assume that the SharePoint:Theme control is always included in master pages because it is not! Go and check the master pages that are installed by the "Office SharePoint Server Publishing Infrastructure" feature and you will see that none of them use the SharePoint:Theme webcontrol. Therefore, no matter what you put as your theme for sites based on publishing master pages, only the _layout pages (based on APPLICATION.MASTER) are affected by the theme CSS. (This to me reinforces my belief that themes are a legacy technology.)

Another gotcha! You will not like themes if you have a lot of sub-sites because you have to apply it at the site level for each site. Unlike the other methods described thus far, this method is not inheritable to sub-sites.

Yet another issue that makes this method a low cleverworkarounds rating, is that themes have to be installed on the web front end servers. In a large scale farm, there may be several WFE servers that need this set. There is no version control, version history, recycle bin, publishing approvals, and as a developer it means you have to deal with anal SharePoint infrastructure or governance Nazis who will not even talk to you unless you have packaged your work up as a solution.

Cleverworkaround Rating: Sucky

Overriding CSS – Master Page Settings with @import

This is a method that I considered but did not test, although I am sure that it will work (so I would be happy to hear from anyone who did). It actually needs to be used in combination with the "master page settings" method that I described in article 2. The idea here is based around strict naming conventions for CSS files.

Now remember my original scenario, I have a master page, and a corporate brand CSS that needs to override CORE.CSS (CSS number #1). But then I have additional CSS files that override the corporate brand CSS file depending on the site. Using the master page settings to specify a CSS file only deals with CSS number 1.

But my idea here is that the CSS to be specified in Master Page Settings (CSS number 1) , refers to one of more additional CSS via the @import directive. The names are strictly defined, so for example:

@import url(brandingoverridemintyfresh.css);

@import url(brandingoverrideorgchange.css);

So now, you have two extra CSS ‘placeholders’. If they do not exist in the site collection, they will not be used. But if you put a CSS file into the site collection, and give it one of the above names, you should in theory get the additional styles required.

This method seems relatively simple in the sense that it is all done in the CSS files, and the SharePoint GUI. However, since by default the CSS files reside in the site collection style library, adding or removing CSS files affect the entire site collection. This behavior can probably overridden with hard-coded or relative URL’s but it will not be great. Hard-coding anything is "not clever" for scalability and flexibility, and relative URL’s are difficult because site collections are not necessarily top level sites.

In addition, your CSS file can get ugly, with lots of @import references to files that do not exist which will confuse things later if governance around this is not well handled.

I won’t assign this a rating, given that I didn’t test it. But I can see it would have its uses in some circumstances. If someone wants to experiment with this I’m happy to link you, or add to this article.

My solution

Now despite the fact that I’ve in effect bagged themes earlier, the actual styles defined in the themes are some of the ones you are likely to be interested in, when performing a branding exercise. It is this fact that led me to my final solution that for me, had the best clever rating of all.

So let’s now examine our matrix so far with the addition of the themes method.

Method	Advantages	Disadvantages
SharePoint:CSSRegistration	– Easy to implement	– Does not override core.css – Does not work with _layout pages
Master Page Settings	– Easy to implement – Overrides core.css – Works on _layout pages	– Can only be used once – Has to be set up for each site
<link> method	– Set in master page once – Overrides core.css	– Precludes "Master Page Settings" CSS override – Does not work with _layout pages
Michael’s webcontrol	– Set in master page once – Overrides core.css – Works nicely with "Master Page Settings" CSS override	– Does not work with _layout pages – core.css as the first CSS can be problematic
My webcontrol	– Set in master page once – Overrides core.css – Works nicely with "Master Page Settings" CSS override – core.css is not the first stylesheet in the list – allows choice as to what css overrides core.css	– Does not work with _layout pages
Custom Themes	– Easy to implement (GUI set) – Overrides core.css – Works on _layout pages	– Modifying the theme modifies all sites using it – Not inherited – has to be manually set for all sites – Installing and updating themes require farm administrator and manual configuration of WFE servers – Not all master pages will obey the theme

Over-riding CSS – The hybrid!

Now remember my original scenario, I have a master page, and a corporate brand CSS that needs to override CORE.CSS (CSS number 1). But then I have additional CSS files (let’s collectively call them CSS number 2), that override the corporate brand CSS file depending on the site. CSS number 2 assumes that CSS number 1 is also referenced. This keeps CSS number 2 smaller and more manageable. But the disadvantage is that as discussed, using the master page settings to specify a CSS file can only be used once and therefore only deals with CSS number 1.

But…what if we took all of the bits that needed to be overridden CORE.CSS and moved them to CSS number 2? Then CSS number 1 is left with styles that CORE.CSS does not interfere with.

CSS number 2 (remember there are potentially many of these) is a little bigger now, as it has some additional styles since now it has to deal with any CORE.CSS interference, however it is still relatively maintainable.

So then, we can do this… (…drumroll)

Have the generic branding (CSS number 1) added to the master page using the SharePoint:CSSRegistration method. Then any CSS number 2, can be specified by the ‘master page settings’ method.

So to illustrate, let’s take a look at the source code to our branded master page.

<SharePoint:CssLink runat="server"/>

 <SharePoint:CssRegistration name="<% $SPUrl:~SiteCollection/Style Library/~language/Core Styles/Band.css%>" runat="server"/>

  <SharePoint:CssRegistration name="<% $SPUrl:~sitecollection/Style Library/~language/Core Styles/controls.css %>" runat="server"/>

 <SharePoint:CssRegistration name="<% $SPUrl:~sitecollection/Style Library/zMyDefaultBrand.css %>" runat="server"/>

  <SharePoint:Theme runat="server"/> 

So, looking at this code, you can see that we are using SharePoint:CssRegistration, to specify a CSS file called zMyDefaultBrand.css. Remember why I prepended it with a z? It’s because SharePoint:CssLink control renders CSS files in alphabetical order it will be rendered last by the CSSLink webcontrol, except for CORE.CSS of course.

You can also see that I left the SharePoint:Theme control in so it can be used if required.

So, since we have moved all the CORE.CSS overrides to CSS number 2, we have a default CSS file called MyTheme.css. This now goes hand in hand with zMyDefaultBrand.css and is set set via the "master page settings" screen.

So the rendered HTML code combines to this:

<link rel="stylesheet" type="text/css" href="/sites/pc/Style%20Library/en-US/Core%20Styles/Band.css" mce_href="/sites/pc/Style%20Library/en-US/Core%20Styles/Band.css"/>

<link rel="stylesheet" type="text/css" href="/sites/pc/Style%20Library/en-US/Core%20Styles/controls.css" mce_href="/sites/pc/Style%20Library/en-US/Core%20Styles/controls.css"/>

<link rel="stylesheet" type="text/css" href="/sites/pc/Style%20Library/zMyDefaultBrand.css" mce_href="/sites/pc/Style%20Library/zMyDefaultBrand.css"/>

<link rel="stylesheet" type="text/css" href="/sites/pc/_styles/core.css" mce_href="/sites/pc/_styles/core.css"/>

<link rel="stylesheet" type="text/css" href="/sites/pc/Style%20Library/MyTheme.css" mce_href="/sites/pc/Style%20Library/MyTheme.css"/> 

Let’s look at the result and compare with our requirements. As you can see, CORE.CSS still beats zMyDefaultBrand.css but it is subsequently beaten by MyTheme.css, so we can override any CORE.CSS quirks.

Since MyTheme.CSS contains all of the look and feel styles that are usually defined in the SharePoint themes and CORE.CSS, the _layouts pages based on APPLICATION.MASTER get overridden nicely. By splitting the CSS we are able to define the global style in zMyDefault.css and the *default* CORE.CSS override in MyTheme.CSS

Since we are using master page override method, this is set on a per site basis and is inheritable from a parent site. Now our web designers can work their CSS magic to make additional MyTheme.css type files to offer flexible branding options such as MyThemeMintyFresh.CSS or MyThemeCorporateBrandB.CSS. Web administrators can pick the CSS file they want to use on a site by site basis giving complete flexibility.

Wohoo!

Cleverworkaround rating: Nice

Summary

So here is the final version of my table..

Method	Advantages	Disadvantages
SharePoint:CSSRegistration	– Easy to implement	– Does not override core.css – Does not work with _layout pages
Master Page Settings	– Easy to implement – Overrides core.css – Works on _layout pages	– Can only be used once – Has to be set up for each site
<link> method	– Set in master page once – Overrides core.css	– Precludes "Master Page Settings" CSS override – Does not work with _layout pages
Michael’s webcontrol	– Set in master page once – Overrides core.css – Works nicely with "Master Page Settings" CSS override	– Does not work with _layout pages – core.css as the first CSS can be problematic
My webcontrol	– Set in master page once – Overrides core.css – Works nicely with "Master Page Settings" CSS override – core.css is not the first stylesheet in the list – allows choice as to what css overrides core.css	– Does not work with _layout pages
Custom Themes	– Easy to implement (GUI set) – Overrides core.css – Works on _layout pages	– Modifying the theme modifies all sites using it – Not inherited – has to be manually set for all sites – Installing and updating themes require farm administrator and manual configuration of WFE servers – Not all master pages will obey the theme
My Hybrid Method	– Easy to implement (GUI set) – Overrides core.css – Works on _layout pages	– master page setting is always specified

Next steps

I am a two finger typist, so after 3 articles you would think we are done. But nooooo, we still haven’t solved all of the issues. Next stop, we examine how to deploy this to the farm set-up in a nice, easy to maintain format. So we do some work on features, solutions, quirks (yeah there are quirks) and governance around it all.