Blog

Themes have been around in SharePoint since 2003 as an option to customize the visual appearance of SharePoint. SharePoint 2003 and 2007 both included a set of themes out-of-the-box that could be applied to a SharePoint site by a Site Owner through the SharePoint UI, and web designers and developers had the ability to create custom themes containing custom images and CSS files.

One of the problems with how themes worked in SharePoint 2007, was that to customize them required a web designer or developer to create custom CSS, image and supporting theme registration files, and deploy them to the file system on the SharePoint Web Frontend Servers. This restriction required technical knowledge and access to physical servers, and thereby restricted non-technical users from being able to customize the SharePoint visual design of their sites.

Themes are also supported in SharePoint 2010, but how they work has changed considerably. One of the goals stated by Microsoft is that they wanted to provide the ability for non-technical users to have ease of use and control over the visual design of their sites, and the ability to customize themes through the SharePoint UI.

Using Themes

The new Theme Editor can be found in Site Settings > Site Theme under the Look and Feel category, and presents a familiar list of out-of-box themes, although the names of the themes has changed from SharePoint 2007.

The SharePoint UI now allows the user to customize a theme by overriding any of available font or color selections. One of the advantages of the new Theme support in SharePoint 2010 is that Themes are now much more standardized:

• 4 colors are provided as the core theme palette for controlling background and text color (Dark 1, Light 1, Dark 2, Light 2). These colors will form the core of your style guide, and have the greatest impact on the overall look and feel of your site.
• 6 accent colors provide the ability to bring sophistication to your design and largely control elements such as active and hover link attributes, border colors, text colors for specialty content such as system menus, group title, header areas, etc.
• 2 fonts are provided for header and body elements
• 2 colors are provided for hyperlinks (normal and followed)

In addition to the color selections directly available to the user, the Theme Generator will automatically render 5 additional tints (lighter variations) and shades (darker variations) for each color. The labels used for each variation are (ex. Accent 1):

• Accent 1 (the user selected color)
• Accent 1 – Lightest
• Accent 1 – Lighter
• Accent 1 – Medium
• Accent 1 – Darker
• Accent 1 – Darkest

The tints and shades provide web designers with the ability to provide depth and perspective to a Visual Design, and are most often used for border effects, gradient color bands, etc. Later in this post, I will demonstrate how these shades are referenced from CSS files.

Anatomy of a Theme

In SharePoint 2007, themes were a collection of CSS, Images and Theme information files stored relative to the SharePoint Root folder at 12\Template\Themes. In SharePoint 2010, you can still find the original SharePoint 2007 themes, for legacy reasons, in the same relative folder under 14\Template\Themes.

Themes in SharePoint 2010 however, are now stored relative to the SharePoint Root folder under 14\Template\Global\Lists\Themes. The format has changed considerably as well. Themes are now packaged using the Office Open XML format as .THMX files.

THMX files are ZIP files that combine XML definitions for the theme styles, and image resources according to the standards. A full description of the internals of a Theme file is beyond the scope of this post, but you can read Creating Document Themes with the Office Open XML Formats on MSDN for more information.

Themes can also be viewed in a new Themes gallery found under Site Settings > Themes located under the Galleries category.

How Themes are applied to Page Rendering

CSS links are rendered into SharePoint 2010 pages in largely the same way they were in SharePoint 2007, using a specialized set of controls included in the <HEAD> section of the Master Page.

Although it has always been possible to include the standard HTML <link> attribute to include CSS style sheets in Master Pages, the CssLink, CssRegistration and Theme controls provide special functionality, and continue to be the recommended approach for inserting stylesheet links into your design. Here is a brief overview of what each of these controls does:

• The <SharePoint:CssLink> control is responsible for injecting the default core styles used by SharePoint, and any custom style sheets that are registered using the CssRegistration control.
• The <SharePoint:CssRegistration> control allows registration of any custom CSS style sheets. The links are actually rendered into the page using the CssLink control.
• The <SharePoint:Theme> control checks if a theme has been applied to the current site, and is responsible for rendering links to the Theme stylesheets. NOTE: This control seems to continue to be included in SharePoint 2010 Master Pages for legacy support. It no longer seems to be necessary for supporting or enabling SharePoint 2010 themes.

Given the above sample, let’s look at how SharePoint renders the links for a site that DOES NOT have a Theme applied:

In the above example, we can see that the CssLink control has injected a number of out-of-box core style sheets. We can also see that my custom CSS link has been rendered last in the list, and is linked directly to the original CSS file stored in the Style Library.

After I apply one of the out-of-box themes, we can see that SharePoint has changed how style sheets are linked into the page.

In SharePoint 2007, an additional style sheet link for the applied Theme would have been included in the page output. The styles included in the Theme would have overridden any core or custom styles using the cascading behavior of CSS.

In SharePoint 2010 that behavior has changed. When a Theme is applied, SharePoint auto-generates the CSS and Images for the Theme on-the-fly, and stores them in the _themes folder of the site the theme has been applied to.

If we open the site with SharePoint Designer, we can see that SharePoint has created a folder containing the generated theme files. The folder name is based on a unique numeric identifier that is generated each time a new theme is applied to the site.

The important thing to note is that SharePoint has replaced ALL of the original CSS links with themed variations. In SharePoint 2010, when a Theme is generated, SharePoint uses instructions embedded into the original style sheets to generate replacements. This auto-generation and replacement occurs under two circumstances:

• The out-of-box style sheet is *themable*. These style sheets can be easily identified by virtue of the fact they are stored in the _layouts/1033/styles/themeable directory.
• The CSSRegistration for my custom style sheet has the EnableCssTheming=”true” attribute.

If I don’t enable CSS theming, then SharePoint renders my custom style sheet last in the page output and continues to link it directly to the original CSS file in the Style Library:

NOTE: There is no requirement that custom style sheets have to support themes. Just as it was both possible and often practical with SharePoint 2007, in SharePoint 2010 it is entirely appropriate according to your objectives to link custom style sheets into Master Pages, and remove the ability of users to apply themes. This is likely to continue to be common practice for publishing sites where site administrators do not want to allow users to override the default styles.

Supporting Themes in Custom Style Sheets

In SharePoint 2007, core and custom style sheets did not have to know anything about Themes. SharePoint used the cascading capability of CSS to enable styles located in Themes to override the core and default custom styles linked directly into the Master Page.

In SharePoint 2010 this behavior has changed, and the core, and any custom style sheets you develop, now need to include markup in order to support themes. The easiest way to see this in action is to open the out-of-box style sheets and see how they do it:

In the above example, we can see that in order to support Themes, CSS commenting has been used in the Style Sheet to inject a special instruction to SharePoint about how to override the default style with the named style defined in the Theme.

Below are some additional examples of instructions that can be included in your Style Sheet to support themes:

Note that SharePoint now includes the ability to automatically re-color images during Theme generation – Wow!

Upgrading SharePoint 2007 Themes to SharePoint 2010

As of BETA2, I have not seen any guidance yet on upgrading SharePoint 2007 themes. Given the considerable change in how Themes are supported in SharePoint 2010, upgrading Themes from SharePoint 2007 is going to mean replacing them:

• Create a custom Theme using Office PowerPoint 2010 and deploy it to the Site Theme Gallery. Todd Baginski has just written a blog showing HOW TO: Create a custom theme for SharePoint 2010. If your custom theme was limited to just basic text and color properties, this will likely do the trick. If your custom theme did anything advanced with CSS tricks, then this will not be a complete replacement.
• Create a custom Master Page that registers your custom CSS directly in the Master Page

Despite the fact that some people will grumble that Microsoft has diverged from using native Web Standards for CSS inheritance, Site Owners, Administrators and Developers will probably embrace the improved standardization of Theme styles, and the ease of use this approach brings to SharePoint.