A Matter of Style

By now, you are probably aware that SharePoint is a heavy user of Cascading Style Sheets (CSS) to control the look of your site. Hopefully, you are also aware that SharePoint Designer has (among other things) a great array of CSS editing tools. In Professional SharePoint Designer, we go into great detail on how these tools work, and many of the style elements used in a SharePoint theme. You can also find breakdowns of the classes used by SharePoint themes on Heather Solomon's site. She has a great SharePoint CSS Reference Chart, that allows you to copy snippets of the default (core.css) values of the elements for use in deriving your own theme styles.

With all of these resources, then, why am I writing yet another article on this topic? Simply because there is still more to say! In this case, I'm going to offer a few tips on connecting to the style sheet you want to edit, not only for "regular" SharePoint themes, but also for users of the Community Kit for SharePoint, Enhanced Blog Edition (CKS:EBE)!

Making the Connection

Whether you are using SharePoint's themes, or some other CSS, your style sheet is usually going to be invoked through a master page. On totally custom master pages, you will typically have a link to your style sheet something along the lines of:

<link rel="stylesheet" type="text/css" href="/somepath/mystyles.css">

But what if you (following my advice from the SharePoint Customization Hippocratic Oath) decide that you don't need to customize your master page, and just want to change the theme? The default SharePoint master pages don't give you a direct link to a theme's style sheet. Instead they reference a couple of placeholders (or tokens) that say "use whatever is defined for the site".

<SharePoint:CssLink runat="server"/>
<SharePoint:Theme runat="server"/>

The first token loads core.css, and any site-wide custom CSS file defined via the API or the Publishing feature's master page picker. The second loads whatever theme your user has applied through the site settings. Thus the load order is Core.css-->yourcustom.css-->appliedtheme.css. Since the last CSS definition for any given item "wins", any styles applied by the theme are always shown, followed by any items in the custom css that aren't overridden, and finally anything that remains in core.css.

Note: Since core.css essentially defines "everything", even complex themes are really just deviations from it. If core.css were loaded afterward, you would never see your customizations.

Mastering Your Environment

Now, while you can just edit the style sheets directly, it is much easier if you can see what you are doing in context. That means having a master page and content page open for editing in SharePoint Designer. Since you don't want to change your real master page, you can do this either on a separate site, or through copies of the default files.

The other thing you need to do is make sure SharePoint Designer is configured to make the changes in the external CSS file, rather than inline. To do this, in SharePoint designer select Tools/Page Editor Options. In the dialog that comes up, select the CSS tab:

Notice in the dialog, I have chosen "Manual Style Application", and made sure all of the drop-down choices are set to Classes or Rules. (Some may be "Inline" by default.) You may also choose whether images use styles or attributes for their sizes.

A Level of Indirection

Once you have your workspace configured, open your master page and test content page. When you try changing the an element, you will find SharePoint Designer automatically opens the .css file that is controlling it. In the screenshot below, I decided I wanted the links in the top bar bolded, so I highlighted the welcome control, and clicked the bold icon. I didn't have the CSS open initially, but notice how SharePoint Designer detected and opened the appropriate style sheet.

In this case, it added a font-weight parameter to the .ms-globallinks style:

.ms-globallinks, .ms-globallinks a {
    color: #4c4c4c;
                font-weight: 700;
}

Notice that the stylesheet opened was "simp1011-65001.css". This file is assembled at the time you apply a theme to a SharePoint site, by combining "theme.css" and any "xxxExtension.css" files that may be in the theme folder. By default, you will usually find a "mossExtension.css". The ultimate name of the file will depend upon the theme you have applied, as well as the code page in place.

Technically, there is nothing wrong with editing this file. It is the file that is actually applied to all of your pages. However, if you want to export this theme for later reuse, you will have to divide the changes back into the constituent files. Wouldn't it be great to be able to change those constituent files directly, rather than trying to figure out which file the element lived in after the fact? Well, you can!

All you need to do is edit your master page, and replace the placeholder token with references to the actual .css files. Here is an example piece of code to do that:

<!--    <SharePoint:Theme runat="server"/> -->
    <link rel="stylesheet" type="text/css" href="/team1/_themes/simple/theme.css">
    <link rel="stylesheet" type="text/css" href="/team1/_themes/simple/mossExtension.css">

Notice that I commented out, rather than deleted, the original token. Now, when I make exactly the same change as before, it is theme.css that is opened by SPD!

Note: You can see these changes on the master page without actually saving it; however, unless the master is saved, your content pages won't reflect them.

Occasionally, you will change an element that the current theme doesn't already have an override for. In those cases, SharePoint will open and create a local copy of core.css. If that happens, pay attention to the style definition that was changed, and copy it into your theme file, rather than actually saving a modified core.css.

CKS:EBE Themes

The same basic principle applies to Community Kit for SharePoint - Enhanced Blog Edition themes. To create my blog's theme, Sanity Road, I made a copy of Intensive into its own folder. CKS:EBE themes live in a theme folder as well, but not the default SharePoint folder. Each theme incorporates both a master page, and the CSS, as well as the associated imagery. The screenshot below highlights the structure and relevant files:

Like a SharePoint theme, a CKS:EBE theme uses a token to reference the css file. Unfortunately, SharePoint Designer doesn't recognize the token, so when you open your master page, it looks like this:

However, like the SharePoint theme, you can replace that token with a link to the "real" file:

<!--    <link rel="stylesheet" type="text/css" href="<% $BlogUrl:~Theme/main.css %>" runat="server" /> -->
<link rel="stylesheet" type="text/css" href="main.css"/>

and achieve the full, rich SharePoint Designer editing experience:

Summary

SharePoint Designer offers some very powerful visual editing tools. In addition, it has a great CSS editor.

In this article, I have shown you how to set up SharePoint Designer and your master page to enable the easy, visual editing of SharePoint themes. I have also shown how to use the same technique on CKS:EBE. I hope these tips help you get the most out of SharePoint Designer's tools, and leverage all the other documentation out there about the actual construction of the themes themselves.