Supporters of End User
Web

MOSS 2007, CSS, and you, the Non-Developer - Part 7: Pulling It All Together

Item is currently unrated. Press SHIFT+ENTER to rate this item.1 star selected. Press SHIFT+ENTER to submit. Press TAB to increase rating. Press SHIFT+ESCAPE to leave rating submit mode.2 stars selected. Press SHIFT+ENTER to submit. Press TAB to increase rating. Press SHIFT+TAB to decrease rating. Press SHIFT+ESCAPE to leave rating submit mode.3 stars selected. Press SHIFT+ENTER to submit. Press TAB to increase rating. Press SHIFT+TAB to decrease rating. Press SHIFT+ESCAPE to leave rating submit mode.4 stars selected. Press SHIFT+ENTER to submit. Press TAB to increase rating. Press SHIFT+TAB to decrease rating. Press SHIFT+ESCAPE to leave rating submit mode.5 stars selected. Press SHIFT+ENTER to submit. Press SHIFT+TAB to decrease rating. Press SHIFT+ESCAPE to leave rating submit mode.
Categories:SharePoint 2010 Branding; Branding; Site Manager/Power User; MOSS; WSS; 2007; 2010; Content Editor Web Part; CSS for Non-Developers

 

We've walked through just about every part of the main page of a SharePoint site so now it's time to bring it all together. In this article we're going to discuss what best practices to follow, how .css files are applied in a SharePoint environment, some of the lessons I've learned along the way and look at where we started and our "finished" product. We'll start out by going over some best practices for working with .css files both in general and in SharePoint.

CSS Best Practices (includes reference links) - these lists are primarily intended for any classes of your own that you may add as part of a customization or for better organization of your custom CSS file. Some of these are simply common sense from my standpoint, some are from Smashing Magazine and some are from Microsoft (references are noted).

From Smashing Magazine - 70 Expert Ideas for Better CSS Coding:

  • Organize your CSS-styles. You can do this using comment blocks or by breaking the style sheet down into 3 or 4 specific sections (Navigation, Body, Web Parts and Headers perhaps).
  • Keep style properties to a minimum. If you don't need it and it's already there remove it. If it isn't there and you don't need it don't add it. This will be especially true in those classes where you have removed an image file. There will likely be additional properties that should be removed for efficiencies sake.
  • Use a common naming system for any classes you may add. Being consistent will make your life (or your successors) much easier somewhere down the road.
  • Where you've changed colors consider using "shorthand". In CSS when you use a hexadecimal color notation you can write that notation in a more efficient manner by omitting every second digit. For example #000 is the same as #000000
  • Any CSS classes you add MUST be unique. It is also important to know that if you are styling a class your selector will start with a period, if you are styling an Id the selector will start with a # sign. An example would be if you were attempting to style the sblink class your selector would start as follows; .ms-sblink. If you were attempting to apply styling to a specific navigational tab in the globaltopnav your selector might start as follows; #zz1_TopNavigationMenu0.

From Microsoft - How to Optimize a SharePoint Server 2007 WCM Site for Performance

  • Elements should be positioned using CSS2 and not tables
  • All ornamental lines, borders, background colors and -images, underlines and other decorational elements should be rendered with CSS2.
  • Text should be formatted with CSS1, not with font tags.
  • All style sheets should be included in reusable, centrally maintainable, and cacheable external CSS files, not as redundant code within the HTML files.

Simply common sense as I see it

  • Never, ever make any changes to the core.css file. Either make or get a copy of the core.css and make your changes to the copy.
  • In your copy of the core.css any classes or Ids you are not making a change to should be removed. The core.css file is some 4300+ lines of code; you don't want SharePoint to have to run through all that code twice. By removing anything that has not been edited from your custom.css file you will make the file more manageable for both SharePoint and yourself.
  • If you make a change add a comment documenting what the effect of the change is. This will help you as well as anyone that may take over for you while you are on vacation, travel or after you have moved on to other responsibilities. Aside from that most folks would consider doing so common courtesy, I know I would.
  • If you have more than one custom.css file come up with a naming convention for your CSS files and stick with it. I use SiteName_Custom.css for my custom CSS files.

This is just a short list but you get the idea. We assume that Microsoft is following generally accepted best practices and make sure that any classes we add follow them as well. As I mentioned above I would strongly recommend organizing your CSS files if at all possible. I think you'll find that it makes it much easier to locate a class you are looking for in the style sheet.

How CSS Style Sheets are applied to a SharePoint Master Page

This section is best described by Heather Solomon. Her write up is far better than anything I can put together. I'm going to add a short version of her breakdown on how styles are pulled into SharePoint and a link to her page at the end of this section. I strongly recommend taking a few minutes to read over, and understand it.

  • If your master page links to a custom CSS file the custom file will be pulled before the core.css
  • If your master page links to a custom css file and core.css has been unghosted for the site the custom.css will be pulled after the core.css
  • If you specify your custom.css through the Administrative UI (Site Actions > Site Settings > Master Pages) your custom.css file will be pulled after the core.css. You should note that any styles defined in your custom.css that apply to _layout pages will be applied successfully.
  • Any styles listed or linked to in the PlaceHolderAdditionalPageHead ASP content placeholder will get pulled after the core.css file. There are problems to be noted per Heathers article about using this approach.
  • Styles listed in the master page file (not linked to but actually listed out in a set of STYLE tags) will be pulled after all css files including the core.css
  • Any master pages deployed via a feature will pull the core.css after your custom.css file.
  • Note that inline styles (styles embedded into the master page) will override any other CSS.
  • Heather Solomon - CSS Options with Master Pages

How can you apply your custom.css file?

There are a number of different ways to apply your custom.css file. One other thing you will have to take into consideration is where do you want to store your CSS files? As with anything else we have done there will be advantages and drawbacks to whichever option you choose, you'll have to decide which option best fits your environment.

  • Reference your custom.css via a link in the master page also known in some circles as "relative CSS". The obvious drawback here is that you will be customizing your master page. That may, or may not, be allowable in your environment. One thing to take into consideration here would be how many different custom.css files are you deploying? If it's a significant number this might not be an option you want to consider.
  • Reference your custom.css file through the Master pages setting of the Administrative UI. There is a mix of advantages and drawbacks to using this method. For me the advantages outweighed the drawbacks and this was the method I chose for my most recent deployment.
    • Advantages
      • No server access is required
      • Because the custom.css file is stored in the styles library for your site collection it is also stored in the content database for your site collection.
      • You can turn versioning on in the styles library and if you manage to mess something up you do have the ability to revert to an earlier version.
      • Because files are not stored on the server itself they are easily modified or replaced.
    • Drawbacks
      • Because files are not stored on the server itself they are easily modified or replaced. This can be a two-edged sword if you don't have good governance or change control processes in place.
      • Could be labor intensive if you have lots of sites that will use different custom style sheets.
      • Requires MOSS with the publishing feature activated. This is something I normally do anyway but there are those that don't see a need to have the publishing feature activated unless it is absolutely necessary. For a WSS instance or a MOSS instance with no publishing activated you'll need to select a different method of applying your style sheets.
  • I haven't tested this yet but fully intend to over the next few weeks but I think you could probably take your custom.css and convert it to a custom theme. If that's the case while you would need server access or the assistance of your server team you would be able to push your theme to any site you wished regardless of activated features or version of SharePoint being used in your organization. More on that in a few weeksJ.

Some of the lessons I've learned along the way

  • Working with CSS in SharePoint can, and will, frustrate you to the point of pulling handfuls of your hair out. You will find that when it gets especially frustrating the best thing you can do is put everything down and walk away for a bit. Of course that could be said of a lot of things couldn't it? It just seems more apparent lately for me I guess.
  • Document, document, document, I hate writing documentation but it is absolutely essential in this case. Several times while I was working through all this I struggled with getting something to work and when I finally did get it right found that I had neglected to add comments to my code so I would know what I had done and where I had done it. Those tend to be those "I'm not smarter than a 5th grader" moments.
  • There are going to be instances where the order of your classes WILL make a difference. You will find this to be true especially when working with modifying the behavior of your links, in particular the "Hover'" property.
  • Plan ahead! Put some thought and planning into color schemes, how you'll handle navigation, font colors and behaviors, and how you'll structure your custom.css file.
  • The Internet Explorer Developer tools are your best friend. Todd Bleeker's CEWP script works very, very well in those environments where the IE Developer tools are not allowed but if you can get them, use them!

Article References

Smashing Magazine - 70 Expert Ideas for Better CSS Coding
Microsoft - How to Optimize a SharePoint Server 2007 WCM Site for Performance
Heather Solomon - CSS Options with Master Pages

A Little Before and After


  After                                           Before

And as promised a copy of my commented CSS file for you. You'll need to remove/change images where appropriate but other than that it should work. Also, you should note that I have not organized this file in any way as I mention above in the Best Practices section. Nor have I removed any unnecessary code, I wanted you to see what is there by default for the most part.

MyCustom.CSS

Well friends and neighbors that's it for now. I don't claim that this series is the work of a know all, end all, expert. These are my experiences documented in hopes that they will be helpful to someone else. As I mentioned early on, please, PLEASE, make sure that you test anything you pull off the web before dropping it into production.

More to come very soon...

Comments

SPguy

MOSS 2007, CSS, and you, the Non-Developer – Part 7: Pulling It All Together

Could you link me to "Todd Bleeker’s CEWP script"? Thanks!

Posted 13-May-2010 by SPguy
Jay

MOSS 2007, CSS, and you, the Non-Developer – Part 7: Pulling It All Together

Todd has moved his CEWP script into the Premium area at Mindsharp. There is no charge for any of the content there but you will have to create a free account in order to access everything there.

http://www.mindsharp.com/?premium=Default

Look under the presentations listing and it's part of his Content Editor Web Part (CEWP) Tricks presentation.

Hope that helps!

- Jay

Posted 13-May-2010 by Jay
Umar

MOSS 2007, CSS, and you, the Non-Developer – Part 7: Pulling It All Together

Very Nice , Thanks for the work you have done for all of us . I was wondering if most of the tags and option will be same in SP2010 and we can use the same method to modify SP2010 sites? any idea ?

Posted 24-May-2010 by Umar
Jay

MOSS 2007, CSS, and you, the Non-Developer – Part 7: Pulling It All Together

Thanks Umar I'm glad you've found it useful.

To answer your question about 2010 I'm not really sure. I know that there have been some major changes in how master pages are structured (no more tables!) and it looks like there might be some changes in the core css and themes. Specifically what I don't know since I haven't really looked.

Cathy Dew has her session on branding 2010 from SharePoint Saturday DC posted. You might take a look at that and see what you can get out of it.

http://www.sharepointsaturday.org/dc/Pages/speakerdecks.aspx

- Jay

Posted 24-May-2010 by Jay
MOSS 2007, CSS, and you, the Non-Developer – Part 8: Customizing a Blog Site | EndUserSharePoint.com

MOSS 2007, CSS, and you, the Non-Developer – Part 7: Pulling It All Together

[...] started by creating a blog site under the Demo site we finished up with in my LAST article. Out of the box, with no custom CSS file applied the site uses the default blue theme that [...]

Posted 23-Aug-2010 by MOSS 2007, CSS, and you, the Non-Developer – Part 8: Customizing a Blog Site | EndUserSharePoint.com

Notify me of comments to this article

E-mail:
   

Add Comment

Title:

 
Comment:
Email:

   


Name:

 
Url: