Making SharePoint not look like SharePoint: An Odyssey - Part 1

Like I posted earlier, I have been working with a SharePoint design/branding project. I have to say that the available documentation for this is pretty vague. There is a lot of “you could do A, or B, or C” high level talk but very little details of the technical implementation of each option. Maybe it is because there are too many variable to write a comprehensive book.

Regardless, I am going to walk you through the way I did it. I doubt this is the best for everyone but this is low-code/minimum complexity way to create custom master page. In this project, I attempted to mimic an existing, public facing website for an internal portal. I did this by adding one customized master page, one CSS file, and a handful of graphics. I made no custom JavaScript and never fired up Visual Studio – this was done entirely from SharePoint Designer 2007.

After reading a lot of books and how to articles, I decided on some general rules for anyone tackling this for the first time:

Do not modify the basic SharePoint objects. Open and save as but do not just directly edit the default CSS styles, master pages, or graphics. It is highly likely that service packs or other upgrades will overwrite your changes. Also, it is sometimes hard to go back.

Double check your backups before you start. You have a pretty good chance to really screw things up so make sure you are backed up and run a test restore before you get started.

Never delete a tag from the master page. The master page forms the ultra-flexible “skin” for the website and these place holder objects tell other pages where you want things parked. If you are missing a placeholder, you get error messages. You can move place holders around and apply formatting but you have to publish with all of them. I create a panel at the bottom of my web pages that is hidden and park all of the placeholders I do not want to have displayed down there.

Don’t start from scratch. There is Microsoft TechNet article that tells you how to create an empty master page and you can design to your heart’s content. If you are new to this, like I was, “green field” development is tempting but just say NO. Open an existing master page and save as. You get some junk you don’t want but you will start with something that works.

SharePoint likes nested tables - live with it. I know that current web design treats nested tables as the dark spawn of Satan that leads to ultimate damnation but, unfortunately, SharePoint behaves better with nested tables. I am not sure why that is the case, but much of the pre-installed web components appear to assume that you are in nested tables where their CSS formatting is going to be isolated from the rest of the page. When the different styles become intermixed, you get some very entertaining results.

Test the Edit Page functions often. When trying to get the branding to look right, create the look, tweak the CSS, adjust the graphics, and take a look at the final page. Do yourself a big, big favor and select “Modify Web Part”, “Edit Page”, or any other site administrator function on the page. You may have accidentally shrunk, hidden, or mangled the toolbars that people need to actually get work done.

SharePoint Customization and Branding

I found a really good SharePoint related site from a consultant in called Clever Workarounds. I read through his four part series on SharePoint branding and made some additional experiments.

Whenever you want to change look and feel of a website, you normally want to adjust the CSS files that control it. Cascading Style Sheets are relatively straight forward and seem to behave logically. For example, you can have multiple definition of a paragraph and whichever style is applied last wins. It would seem that if you added your own CSS link, tweaked the settings you want, you wouldn’t make any changes to the preinstalled files. That way, patches and upgrades wouldn’t destroy your work - simple, right?

However, SharePoint has a big problem with this. The key problem with custom branding for SharePoint is that a large part of the functionality in SharePoint is defined by the CORE.CSS style sheet. No problem, right? You just need to add another CSS file below it in the header, and you’re done. Well, actually, it is not that simple. Unfortunately, the way that SharePoint builds the pages, the CORE.CSS file is always last - thus making it always be dominant.

Looking at the Clever Workarounds pages, it looked like getting around that would be very, very complicated. However, in reading the comments, there seemed like their might be a good way around it. Here is the comment (edited slightly for length):

Remember the Cascading part of cascading style sheets and the specificity of each rule. It doesn’t matter if your css rule appears before or after core.css If you want your rule to win you make it more specific. I have used this approach since SharePoint 2001 and have never had any problems. I place a unique, short ID attribute on my body element in the master page. Example Then when I find a rule that I want to override that core.css is currently rendering I create a duplicate rule in my stylesheet but place #dm in front of the rule. So for example .ms-WPHeader in core.css becomes #dm .ms-WPHeader in my stylesheet. Now that I have a more specific rule my style rule wins. Works every time … and it requires no custom code or major modifications to SharePoint.

So, I gave this a shot:

• You create your own CSS page and link to it.
• At the body level, inside a table tag, or whatever makes since, add the ID tag (the commenter used DM for his example but it can be anything)
• View your pages and see what CORE.CSS styles need changing
• The internet explorer Developer Toolbar is very useful for this
• In your custom CSS page, create rule with the same name and add the #ID in front of the definition
• Save and refresh – repeat as necessary.
  
  

Doing some development work

Recently, I’ve doing some development work instead of my more normal systems administration work. I’ve always done VBScript scripting of administration tasks, started fooling with PowerShell, and have always been messing around with websites but I’ve been going past that, recently. I’ve had a couple of things I’ve been working on:

• Creating custom “look and feel” to SharePoint sites
• Creating web parts for SharePoint sites
• Creating a C# web application for linking an outsourced CRM system to Groove
• Creating a C# console application to read three different calendars and then create a survey questionnaire based on information inside the meeting

It has been a real challenge I’m going to try and write some posts based on what I learned. For those of you with real developer experience, you will probably laugh over some of the things I had trouble with. Hopefully, if there is any other sysadmin that needs to do some quick prototype code, they can benefit from my experiments.