What makes good SharePoint CSS?

I recently read an interesting post that I think is a good starting list for judging CSS files. You can check it out here: Judging CSS / Spotting Bad Code

Reading that article and my ensuing comment that I posted based on my experience with SharePoint led me to think… why not write this up for SharePoint?  So here I am.   🙂  Let’s get started with chatting briefly about why you should even care about what makes good SharePoint CSS code.

Consultants, money and getting cruddy files

A lot of companies turn to consultants for branding and custom development work.  At the end of the day you are spending money on files. Shouldn’t those files be the best they can be?  Don’t let a lack of code knowledge or comfort deter you from double checking the quality of the code you are purchasing.

Double checking your own stuff and getting a hand with a sanity check

SharePoint CSS code can lead any steely code warrior to crying silently in the corner. Despite how that may sound, I am not dogging SharePoint.  There is a lot of code in order to support such a huge application.  There are conflicts and a LOT of class names to keep straight. Hopefully this list will help you navigate the SharePoint CSS waters in regards to making sure your files are usable in the coming months and during your future upgrades. You may also want to check out my SharePoint 2010 CSS Chart.

Sanity Check #1:  Please for the love of all that is holy, don’t copy Corev4.css (or core.css or any SharePoint CSS file for that matter) and use that as a starting point for your CSS changes

I suggest you leave the Core(insertversionhere).css file alone and put all of your custom CSS changes in a separate file.  If you are not a CSS coder, open the CSS file given to you and see if it starts with this:

/* _lcid="1033" _version="14.0.4762"
_LocalBinding */
body,form{
margin:0;
}
.ms-toolbar{
font-family:verdana;
font-size:8pt;
text-decoration:none;
/* [ReplaceColor(themeColor:"Hyperlink")] */ color:#0072BC;
}

If it does, you are looking at a copy of Corev4.css for SharePoint 2010. This is the main CSS file used by SharePoint. There are over 7,000 lines of code in Corev4.css. You don’t want to bury your CSS changes/additions in this huge file. I *always* recommend creating a separate CSS file for your changes/additions and never integrating your styles within an  out-of-the-box SharePoint file. Keeping things separate will make updates much easier and upgrades a lot less painful.

Sanity Check #2: As a piggy back to #1, don’t allow SharePoint Designer to edit Corev4.css (or any other out-of-the-box SharePoint CSS file)

If you are working inside of SharePoint Designer and get a nifty notice that saving your changes will customize Corev4.css, please stop!  Through a wizard or tool pane or the like you have made a change to the SharePoint CSS file and SharePoint Designer is asking if you want to save these changes in a customized file, which is creating a copy of the CSS file (that includes your edits) in the content database.  You don’t want this for the reasons listed for #1 above and the added reason that you would be creating an isolated file with CSS changes/additions that is used by that one SharePoint site collection.  This will further complicate your upgrade, sharing of branding changes, etc.  If you are checking out code given to you by a third party, check to see if there are any CSS files that have been deployed as a part of the solution and if they are just a modified copy of Corev4.css.

Sanity Check #3: Avoid !important like the plague

Oh it is sooo tempting to slip in that little !important to get that pesky SharePoint element to mind it’s manners and listen to your style changes.  There are very few instances however that require !important in SharePoint.

A little background… !important is the last ditch method of making sure a CSS style statement will take effect in a web page, no matter what else has been set for the element (for example a link color or image size).  This method is used to override inline styles, which have a lot of weight with a browser and will be used to style an element no matter what is in the CSS file.  With CSS a general rule of thumb is “last thing specified is the last thing applied”.  Here is an example:

In your CSS file you have this style statement:

.SharePointStyle {color: red;}

In your HTML code, you see this:

<a href="link.com" class="SharePointStyle" style="color: green;">link</a>

Buried in the anchor tag is an inline style (style=”color: green;”) and your CSS style statement setting the font color to red won’t take effect, unless you do this:

.SharePointStyle {color: red !important;}

Yes, there are quite a few inline styles in SharePoint. But the key thing to remember is that there will be none or very few of them that you will actually need to target in your CSS because your design and branding requirements won’t require a UI change for that particular element. Save !important for the few times that you do need it and don’t use it as a blanket catchall method to ensure all of your custom styles are properly applied in SharePoint.

If you are checking the code you got from a third party, run a search for !important.  If you get a lot of hits, you don’t have clean CSS code on your hands.

Sanity Check #4: Build in future sanity checks

Comments are your best friend with SharePoint CSS.  That and a nice margarita but that is another blog post entirely.  I don’t know about you, but I can hardly remember what I fed my kid for breakfast today much less what some style statement is doing in SharePoint that I wrote three months ago.  Be kind to yourself and others using your code, please add comments to the CSS file.  Here is an example:

/* Dynamic nav item hover for top navigation drop down menu */	
	.menu ul.dynamic li a:hover {
		background: #d0ee6c;
	}

The comment is the first line in the example and must start with /* and end with */. You can even add comments within the style statement:

/* Change menu arrow that shows at the static level to indicate there is a dynamic menu */
.menu-horizontal a.dynamic-children span.additional-background, 
.menu-horizontal span.dynamic-children span.additional-background {
   background-image: url(image.png); /* Replace default arrow with custom image for dropdowns */
   padding-right: 32px; /* Increase padding to place arrow */
   height: 28px; /* set height to show full arrow image - this is the image height dimension */
	}

Sanity Check #5: Separate grouped selectors and add formatting to properties

One way to keep clean CSS code is to separate out grouped selectors to individual lines and indent properties using spaces or tabs. You can always minify the file if you are worried about file bloat. I bring this up because SharePoint loves to group selectors and if you are copying SharePoint style statements and making changes in your own file, you may change things you don’t want to alter. For property indention, it is just easier on you and anyone else working with the code to read the CSS. For example, check out this out-of-the-box SharePoint style statement:

.ms-cui-ctl-on,.ms-cui-ctl-dark-highlight,.ms-cui-ctl-a2.ms-cui-ctl-dark-highlight:hover,.ms-cui-ctl-a1.ms-cui-ctl-dark-highlight:hover,.ms-cui-mrusb-selecteditem a:hover,.ms-cui-ctl-hoveredOver{
border-color:#c2821b !important;
background-color:#ffd86c;
}

It is hard to see it, but there are actually six different selectors and two properties in that style statement. Here it is again with carriage returns and tabs added:

.ms-cui-ctl-on,
.ms-cui-ctl-dark-highlight,
.ms-cui-ctl-a2.ms-cui-ctl-dark-highlight:hover,
.ms-cui-ctl-a1.ms-cui-ctl-dark-highlight:hover,
.ms-cui-mrusb-selecteditem a:hover,
.ms-cui-ctl-hoveredOver{
	border-color:#c2821b !important;
	background-color:#ffd86c;
}

The commas that separate grouped selectors quickly and easily disappear when you are skimming over CSS code. Placing each selector on a line as well as adding tabs/spaces in front of properties will help with code readability now and in the future. If you are digging around code you have been given, check to see if there is a minified version of the file (all code will be on one line) vs. a copy meant for human consumption.  The latter should include the carriage returns and property indention/formatting.

Sanity Check #6: Keep it simple, keep it light, keep it clean

This is more for people writing CSS vs. those who are looking at files that have been handed to them.

  • Use simple selectors. Don’t add classes, IDs, etc. to a selector for the sake of it. Make sure every bit of that selector is really needed to apply the style.
  • Check for redundancy. Minimize how much your override your own CSS style statements. In some situations it is warranted but overall when you are finishing up your code, check for duplicated selectors, unnecessary overrides, etc. SharePoint does this in several places and it can add frustration to identifying the CSS that needs to be overwritten.
  • Clean your code. Run your code through CSS clean up tools to look for areas that can be improved. Always make a back up copy of your code first. Some available tools are:
    • CleanCSS
    • W3C CSS Validation Service
    • CSSTidy
    • Dirty Markup
    • CSS Lint
    • I am purposefully omitting browser tools from this list. There is great stuff out there but since SharePoint CSS will be included with your CSS the browser tools don’t do you a lot of good. You need to use something where you can run only your CSS through the tool.
  • Minify your CSS.You could argue back and forth on whether or not this will make a difference when using a SharePoint site but it is a good practice no matter what. Some available minify tools are:

Got more?

If there are things you look for or try to do with your SharePoint CSS, please leave a comment!