SharePoint and CSS

SharePoint utilizes CSS quite heavily, and it is both a curse and a blessing. Since nearly all of the SharePoint 2003 UI is hard coded in the site definitions, CSS provides one of the best ways to update the UI. But the SharePoint CSS is also pretty unruly and can be quite daunting at first glance. Let’s go ahead and get the numbers out on the table.

For a SharePoint 2003 Portal and WSS install, there are 7 separate style sheets (excluding themes), totaling to 7,403 lines of code and 1,227 style statements. Ouch! Luckily some of that we can slash off pretty quick. Four of the seven style sheets I have yet to ever have to edit to affect a site (Menu.css, OWSmac.css, OWSnocr.css, Paystub.css). The other three are pretty easy:

• SPS.css: SharePoint 2003 Portal style sheet
• OWS.css: SharePoint 2003 Portal style sheet AND Windows SharePoint Services style sheet
• OWSPERS.css: SharePoint 2003 Portal Personal Sites (My Sites) style sheet.
• OWSPERS.css is a combination of a copy of SPS.css and OWS.css with a few things tweaked here and there. You can condense the style statements in OWSPERS.css to something more manageable and less repetitive. I tell you how here.

SPS.css and OWS.css have a few quirks. There are style selectors that are repeated in each. In some cases, the duplicate styles are not connected and control WSS and Portal separately, but in other cases the two are connected and what you have in one can possibly override the other, making for a confusing and frustrating situation. Additionally, the styles may share the same selector, but list different properties in the declaration.

When a portal page is rendered, it pulls in several style sheets, in this order 1) OWS.css; 2) MENU.css; 3) SPS.css.

When a WSS site is rendered, it pulls in the OWS.css style sheet and then the theme style sheet if a theme has been applied to a site.

The order of which the style sheets are called in the code is important. The way CSS works, generally the last property specified in a declaration for a selector is the property that is used for rendering the element. So if the same selector is in both SPS.css and OWS.css, a portal will use the declaration listed in SPS.css for the element because SPS.css is called after OWS.css in the code. This is the basis behind how themes work as well. In a theme, you only need to include updated declarations in the theme style sheet, and when the site is rendered the new declarations in the theme style sheet will override anything set in OWS.css.

Edit the CSS files on the web server

Portal/WSS: Both
Sites affected: Entire environment

Editing the style sheets directly used by SharePoint requires zero duplication of code and fast results, but can cause maintenance issues further down the road. With any patch or upgrade you run the risk of losing your changes. Your changes would have to be reapplied as opposed to other approaches of just resynching up pointers to custom style sheets. The other hindrance is that the SharePoint style sheets are very long and the number of styles you will actually end up needing to edit will pale in comparison to the final statement count in the files. So you will have to deal with a lot of finding of statements and wading through untouched statements. This is not the cleanest way to specify new styles.

Read more on how to use CSS on SharePoint