This post details my thoughts on where to start with branding for SharePoint 2013. In particular, I think Themes (.spcolor, .spfont) are now usable, and recommend to start there, linking to a couple of resources. But first, I talk about what not to do.
What not to do
It might seem like a good idea to get a graphic design company to develop a whiz-bang look for your intranet, then turn around and ask a web development company to turn it into a SharePoint branding. Often this starts out with an HTML reset or HTML boilerplate.
The core SharePoint stylesheets have over 10,000 lines of CSS -- unless you want to rewrite all of that, you do not want to be doing a CSS reset. You never know when BI dashboard widget XYZ is going to need to display a green/red traffic light based on some CSS buried deep within the core files.
Don't do it.
Okay, so then next thing that developers try is to leave the defaults alone and start overriding. You want the left menu green, fine, find the CSS for the menu and change it to green. You want the library headers to be orange on black, find the CSS and start changing it, etc.
First of all, unless you have a structured approach to this, following CSS Inheritance Specificity rules, you might be tempted to start using whatever ID attribute you find to try and override. Don't do this, as often SharePoint requires multiple levels of override to work together. More on this below.
Furthermore, the override approach only appears to work until the customer actually starts to use it. They first log a bug that the menu is the wrong colour in search, then in a blog, then on page PQR, etc; the same with the headers: add a lookup column and it is wrong, or a read only column and it is wrong, etc. There are so many parts (in that 10,000 CSS file) that no matter how many you think you have overridden, the customer will find more that haven't been.
Two other problems that are often encountered with a graphic-design-first approach:
- The design doesn't incorporate space for SharePoint controls, like the ribbon, user name, or tool menu, list/library controls, standard search scopes, or all sorts of other standard SharePoint parts.
- Where the designers provide "CSS that you can just drop in", they often base it on a particular structure of components like menus -- say: a link inside a span inside a div. The standard SharePoint menus won't have the same structure, so their CSS won't work.
- a colour palette (spcolor)
- a set of fonts (spfont)
- Start with an out-of-the-box spcolor file close to what you want.
- Set the main colours (search and replace) and six accent colours.
- Override additional CSS following a consistent structure, such as adding a single class to the body element and the front of each definition you are overriding.
Start with a theme
So, we know what not to do, so where do you start. First of all, I suggest starting with a theme -- base fonts and colours from the client's brand guide or desired branding. In SP2010 themes were not easily accessible, but that has changed in SharePoint 2013 and they are reasonably easy to develop and deploy.
A theme consists of two main parts:
You can also include background images and even custom master pages (in a composed look), but this post will concentrate on the above.
The advantage of starting with the above is that it reduces the 10,000 line CSS file down to two small and manageable files. It means once you change the menu font to Old English, it will be Old English in every menu, without the need to hunt down and override every single one. The same with colours.
However, while the seven fonts are easy to define, I find the ninety or so colours in the .spcolor file still too many to handle, and which need to be darker or lighter for good contrast.
Therefore to start I suggest picking one of the out of the box colour palettes as a starting point. For example, if the primary corporate colour is orange, then start with Palette015 or Palette025, or even palette_pub005 or palette_pub019. This will give you a starting range of shades for SelectionBackground, RowAccent, StrongLines, etc.
To help pick a starting point, I wrote a small PowerShell script that parses the files and outputs an HTML palette sample, allowing you to compare them side-by-side. Here is the file comparing all out-of-the-box SharePoint 2013 color palette themes. You probably want to zoom out your browser to get a better view.
Note that some of the palettes are quite subtle as they may look the same but differ in simply the opacity of one key value. The sample file includes diagonal stripes behind the colours so the opacity can be seen.
After selecting a starting point, change the main colours to exactly match their corporate branding, and then adjust as necessary. For example, starting with Palette015, you want to change AccentText from orange #F09609 to the correct corporate orange. Rather than only changing the AccentText colour however, you want to change everywhere in the file where #F09609 appears (RowAccent, EmphasisBackground, etc).
Note that the usage will vary depending on the base theme, but in general you want to keep the contrast consistent, although you can adjust shades if you want.
The main colours to look at are AccentText (above), BodyText and BackgroundOverlay (however be careful changing these), and Navigation. Where you want them to vary, also look at HeaderBackground, FooterBackground, and the TopBarBackground and SuiteBarBackground (and associated text and hover colours).
Lastly, set the ContentAccent1 (usually the same as AccentText) through ContentAccept6 colours based on the corporate colour scheme. Shades will automatically be generated from these colours and used in the content editor, with ContentAccent2 being used for alternate headings.
The accent colours are even used in the SharePoint UI, such as for colouring tabs on the ribbon.
You can also use the SharePoint Color Palette Tool.
Leveraging the theme
You will notice that several colour settings in the theme file don't appear to work.
For example, you might set HeaderBackground, HeaderSiteTitle or HeaderNavigationText, and wonder why the changes don't appear in the default Seattle masterpage.
Try switching to the Oslo masterpage, and you will see them. The issue is that the top area of the Seattle masterpage is not marked as a header, so you need to use SiteTitle and Navigation to change the appearance.
So, this gives us a clue how we can leverage theme files in our custom master pages.
If you do want to have a coloured header, then don't pick a random class name (class="myheader"), and write custom CSS (.myheader { background: #ffffee; }), instead reuse the values already defined in the theme.
That is, using Seattle (corev15.css) use class="ms-bgHeader ms-core-header" to indicate the header section, which will set the correct header colour based on the theme, as well as the menu text colour.
Similary, use class="ms-bgFooter" for a footer coloured as per the theme. You can also cheat and used class="ms-bgFooter" to colour another area, e.g. if you want a two-tone header section, use ms-bgHeader for one and ms-bgFooter for the other.
There are also CSS classes available for most of theme values, e.g. "ms-ContentAccent1-fontColor", etc for accent fonts, "ms-ContentAccent1-bgColor", etc for accent backgrounds, "ms-ContentAccent1-borderColor", etc for borders.
To get the HeaderSiteTitle you need to base your master page off Oslo (oslo.css), but will need to edit to add in a left nav if needed. With this stylesheet class="ms-core-pageTitle" will use HeaderSiteTitle, while class="ms-bgHeader ms-core-header" and id="titlerow" will set the header background.
Have a look in corev15.css for other similar defined values for hovers, lines, etc.
How to override with custom CSS
Once a basic theme is in place, you can be assured that most pages will at least look okay and in general consistent (all headers will be consistent, all menus, etc). There will still, however, be situations where you then want to apply additional customer styling.
Maybe you want flyout menus to be coloured different, or have added a footer to pages, or want web parts in the right hand sidebar to have different headings. This is where you need to use custom CSS, however I recommend approaching this in a consistent and structured way.
If you are using a custom masterpage (even just one of the out of the box master page layouts, but with a link to your custom CSS added), then I suggest adding a simple class to the (top level) body element, e.g. , and use that to implement any CSS overrides. Similarly for any custom page layouts or web parts I recommend wrapping them in a top level div element with a simple class usable for overrides. I usually use a two letter prefix, similar to how ms- is used, to identify which custom CSS classes I have added.
Then, to override, say the dynamic menus, find the relevant CSS inside the SharePoint core files (e.g. corev15.css) and copy the specifiers used into your custom CSS, add your body class (.xy-master) at the beginning, and then whatever you are overriding.
It can be important to look at the range of specifies used in the base CSS files, as you may need to override the link colour, but then also the visited and hover alternatives, or maybe where there is a span inside the link.
In most cases adding a single additional class will give a higher specificity for just the elements you want, although sometimes there may be other definitions you also need to copy also with the increased specificity to maintain the correct relationship between elements.
If you are only building an override CSS, but not a custom master page, then I still recommend having a consistent approach to override specificity, e.g. always add the 'body' element to each definition you are overriding.
Other approaches are possible, but I recommend following at least some kind of structure so that your CSS overrides can be readily identified.
Finally, here are a few related recommendations from Heather Solomon.
Summary
To summarise:
Awesome post Sly. 🙂