Style Basics

WSS Branding Options:

• HTML Styles
• Inline
• Embedded CSS
• Style Sheet via HTML Link
• Style Sheet vis SharePoint:CSSLink
• Theme
• Master Pages

MOSS ECM Additions:

• Page Layout
• Central part of ECM Publishing Features

Master Pages vs. Styles:

• Styles
• Colors
• Borders
• Fonts
• Background Images
• Hide Elements
• Positioning and Layout (note: CSS are able to do a lot with regards to positioning and layout and people with experience of CSS when they started to work with Sharepoint tend to using css as opposed to using table. The problem with that is that Sharepoint is composed of so many parts that are not under the direct control of the person who is doing the branding, for example say you've got the layout look right on a page, all of a sudden, some other elements which you have no control over comes in and mess up your layout, attempting to use CSS for layout in SharePoint is a specially frustrating proposition because of the way inheritance works in CSS. The advise here is to use table as opposed to CSS.)
• Master Pages
  • Provide Structure
  • Full control of layout and default elements including styles

SharePoint CSS

• Located at 12\TEMPLATE\LAYOUTS\1033\STYLES
• WSS
• Core.css - primary style sheet
• CALENDAR.css
• datepicker.css
• MOSS Additions
  • Portal.css - Search center and site directory
  • HtmlEditorCustomStyles.css
  • HtmlEditorTableFormats.css
• Various others for backward compatibility

How to Affect Styles:

• Content Editor Web Part (can put style tag on a page)
• Pros
  • Requires only designer permission access
  • Position on the page means it is never overridden by a cascading style
  • Good for styling a single page
  • Does not require unghosting the page
• Cons
• Good for styling a single page, limited reuse
• Embedded Style in Page (from page opened in SP designer or page created and deployed through Feature)
  • Pros
    • Simple, minimal parts
    • Good for modifying a single page
    • Position on page means it can only be overridden by a Content Editor Web Part
  • Cons
    • Involves unghosting the page when outside feature of site definition
• Use AlternateCSSLink in ONET.xml (used to specify the css to use in addition to core.css) or HTML link in Master page
  • Pros
    • Affects all non-application pages
    • Provides central control
  • Cons
    • Doesn't affect pages in _Layouts (all the site setting pages do not pick up the css defined here)
    • Stomped by SharePoint:CSSLink for customised pages
• Theme
  • Pros
    • Applies to all pages including _layouts
    • Centralized control
  • Cons
    • Require features stapling and event receivers to activate automatically on new webs
    • Must be installed on the server
• Embedded Style in Master Page
• Pros
  • Affects all non-application pages
  • Provides central control
  • Prevents themes from affecting named styles
• Cons
• Doesn't affect pages in _Layouts

Core.css

• When the page is customized, Sharepoint changes the order the core.css is placed. It will place core.css last in the list when the page is customized.
• Generally,editing the Core.css is a bad idea. For one it affects everything on the server. And for another, hotfix and service pack can override it at any time.

Picking an Approach:

• What is the scope of the style changes? (single page or new feature or new site definition)
• What is your level of privilege on the site and server?
• Is the desired look and feel configurable by the users via themes?
• Are you gonna override Sharepoint's style or declaring your own?
• Should the styles affect the application pages? (If yes, the advice is to use theme)