1,804 articles and 14,618 comments as of Monday, January 31st, 2011

EndUserSharePoint has combined resources with NothingButSharePoint.com. You can now find End User (Mark Miller), Developer (Jeremy Thake) and IT Pro SharePoint (Joel Oleson) content all in one place!

This site is a historical archive and is no longer being updated. Please update your favorites, bookmarks and RSS feeds.

NothingButSharePoint.com
Thursday, July 9, 2009

Editing Themes with SharePoint Designer

A Matter of StyleA 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:

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”.


 

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:

 


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:

 

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.

Woody Windischman<br />
Author: Woody Windischman
Site: The Sanity Point

Woody Windischman is a technology consultant with over 20 years of experience in a variety of roles, providing a unique perspective which allows him to see problems holistically.

Since getting acquainted with Microsoft IIS and FrontPage in the mid 90’s, Woody has been deeply involved in the community – first having been awarded as a Microsoft SharePoint MVP from October 2005 through September of 2007, and then spending a year working directly with the SharePoint product team.

SharePoint Designer 2007Professional Microsoft Office SharePoint Designer 2007
Woodrow W. Windischman, Bryan Phillips, Asif Rehmani
ISBN: 978-0-470-28761-3

 

Please Join the Discussion

3 Responses to “Editing Themes with SharePoint Designer”
  1. Woody says:

    I noticed there are a couple paragraphs (and a small css code block) missing from the article as posted at this time. After the line:

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

    You should see this code, and the paragraphs that follow, which lead up to the code that is actually shown:

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

  2. Woody – My fault entirely. I’ve updated the article with the additional text. — Mark


Notify me of comments to this article:


Speak and you will be heard.

We check comments hourly.
If you want a pic to show with your comment, go get a gravatar!