My Favorite JavaScript Libraries and jQuery plugins

These are a few of my favorite and go to JavaScript libraries. These tend to work well in SharePoint with no problem. This is my personal list that I use


Console Log




Click Outside

Mutate / Resize

Select Box (supports Multi)

Time / Date

Truncating Text

Layouts (masonry type)

Notify / Alerts


Scroll Bars

SharePoint Specific


Free Floating Quick Launch Navigation for SharePoint 2010 using jQuery

Recently I was asked to make a free floating navigation element, so that when you scroll down the page it would follow. There are many adaptations of this but for standard html websites, but I was unable to find a SharePoint specific one. Until writing this post I just recently noticed an alternate but similar approach here


Download the code snippet from here

Add the script references to the files in the Master Page, or CEWP.


Once you add that to your pages it’s activated. This is tested to work on standard V4.master.



If you’re quick launch is larger than the view then it will constantly be scrolling down, and you’ll never see the bottom of the quick launch .

Your quick launch must be smaller than the actual view.

I’m using jQuery from the Google hosted API libraries –

Here is a look at the actual script




Customize Table of Contents Web Part: Remove Libraries & Navigation Headers

This article is based off Thomas Sondergaard’s post located here:

This version is slightly different, I approach it similar but in a different way. That version uses javascript and scans all <A> tags on the page, it did not remove the extra items added from Quick Launch navigation.

My version will remove all the lists and libraries as well as any nodes added from the quick launch navigation, and it specifically targets the table of contents web part only.


Standard Table of Content webpart will display all Items in the site and any additional headings and links added in the Quick Launch.


It pretty much shows everything that’s in the quick launch.


My client had the requirement of a site map type web part for SharePoint Online (o365). So I could not program anything and the Table of Content web part was great because we could sort, but they did not want all this ‘other’ stuff, Libraries & Lists & Navigation Headers, appearing in the site map type webpart. They did want it to appear in the quick launch, so I could not remove it from there. The Table of Content is reading directly from the Quick Launch navigation provider so I was stuck.


Using jQuery I iterate throught all the headers, then I find which ones are list and libraries.

Lists and Libraries will have an <a> tag which contains ‘BaseType’

Or I check to see if it’s a standard link and remove that. All the automatically generated one would be relative links. And all the ones added to the quick launch we added as absolute.

If the section did not contain a link, then it’s detected as a Header from the quick launch nav provider and I remove that.

Below is the script, I load jQuery via a CDN first. Then I’ll add this to the page in a <script></script> tag. In my actual deployment I added my script to the MasterPage so it would be used site wide.

jQuery(document).ready(function () {

    var url = window.location.pathname;
    jQuery(".toc-layout-main .headermarker").each(function () {

        var result = jQuery(this).find("a").each(function () {
            var href = jQuery(this).attr("href");
            if (href.indexOf('BaseType') != -1) {
                var topNode = jQuery(this).parent().parent().parent().parent();
                if (topNode.hasClass("level-section")) {
            else if(href.indexOf('http') != -1) {
                var topNode = jQuery(this).parent().parent().parent();
                 if (topNode.hasClass("dfwp-list")) {

        if (result.length == 0) {
            var topNode = jQuery(this).parent().parent().parent();
            if (topNode.hasClass("level-section")) {



That’s it. Your final results should look be reduced to only sites and sub sites.


Cache Busting Using CssRegistration & ScriptLink in SharePoint 2010

What is cache busting?

Cache busting is way to ensure that the browser will download a new version of your file. This is easily accomplished using a simple technique of appending a ? with some unique characters at the end.


<link rel="stylesheet" href="/css/example.css?v1.0" type="text/css" />

The browser sees this as a different file and will then download and cache this new file. Each time the browser see’s a different string it will download the file and cache it. Some methods use a revision number, a date, random number, or a signature as a query string parameter. Taking a look at the example above you will see a version number is specified at the end of the .css file to do the cache busting.

SharePoint 2010 uses a technique which involved computing a MD5 hash signature of the file and appending a ?rev={MD5HASH} to the link. This technique works very well because the computed hash won’t change unless you change something in the file.  Also the computed MD5 hash will be unique to ensure that the file will appear new to the browser. For all you super technical people, yes MD5 is not guaranteed to be unique, there is a very very small chance of the hash being the same. This technique of the computed MD5 hash signature is used for both CssRegistration and ScriptLink in SharePoint 2010. If you are interested in more detail then reflect into Microsoft.SharePoint.dll –> Microsoft.SharePoint.Utilities –> SPUtility –> MakeBrowserCacheSafeLayoutsUrl

Cache busting for CssLink

When using CssRegistration the files need to be relative to the Layouts folder, more specifically LAYOUTS\1033\STYLES\{CssFile}.



If you do not keep the files in the LAYOUTS\1033\STYLES then you will receive an error


Below is the rendered html output of the CssRegistration tag above


You can see that “/_layouts/1033/styles/” is prepended to the ‘Name’ property provided in the CssRegistration tag and your .css file is successfully cache safe.

Cache busting for ScriptLink

When using ScriptLink the files need to be relative to the Layouts folder. Unlike the CssRegistration, ScriptLink has a property called ‘Localizable’.  In the asp tag below I specify Localizable=”False”

If you don’t specify Localizable=”False” then you need to put the files relative to the Layouts\1033 folder.



Below is the rendered html output of the ScriptLink tag above


You can see that the “/_layouts/” is prepended to the ‘Name’ property provided in the ScriptLink tag and your .js file is successfully cache safe.

What if I am deploying files to the Style Library?

In the scenario where you are deploy CSS to the Site Collection style library then there is no automated way of using the SharePoint cache busting from the CssLink, however you can take a look at Chris O’Brien’s posting – Avoiding bugs from cached JavaScript and CSS files in SharePoint. In this posting he has a solution in which he creates a new class inheriting from CssLink and adds his own mechanism of cache busting. He also mentions that there is no equivalent way to do the same for JavaScript files stored in the content db.


SharePoint 2010 provides an easy way to do cache busting on CSS and JS files stored in the LAYOUTS folder.

If you store your files in the ‘Style Library’ or content DB then you have to revert to manual methods or get creative with your own solutions.

Theme Builder Lives On!

For those working with SharePoint 2010 themes this tools seemed to be amazing at giving me those .THMX files. Until they took it away, but they never told me it would come back as something else.

If you go to and sign in with you window live id you’ll notice a nice error message


Theme Builder has been reincarnated and I just found it yesterday. I’ve always kept a copy of the original Theme Builder anyway. But now here it is

Open XML Theme Builder

SharePoint CSSRegistration or Link?

I must say that I’ve been using <link> for my style sheets for some times now. Until recently have seen the benefits from using the CSSRegstration method and now using that exclusively from now on. Even in my master page where I know the CSS files will only load once I will use it. I was unaware that CSSRegistration had Conditional Expression built in to target other browsers, but now that I know that I have no excuse not to use it.

Using the After property

Most of the time you’ll want to load your CSS file after the core V4 css gets loaded. To do this you’ll use the property After=”corev4″.css”


You’ll see in image below that the files are appearing after the corev4.css file which is the main SharePoint styling CSS file.


Removing the After property you’ll see the style0.css applied before the corve4.css and style1.css applied after it.



Order of Loading

Take notice to the order that you are setting them in the master page. The style sheets set first in the master page will be applied last on page load.


When the page loads you can see the output.

Style1.css , then Style0.css


Using Conditional CSS

The CSSRegstration class has properties to target specific browsers similar to this method.


Which renders like this, where the comments will target different browsers.


You don’t have to enter the IF in the condition, that is done for you. But to access NON IE browsers you’ll have to specify another property to reach downlevel clients. Pay special attention to the ConditionalExpression which is set to !IE, to reach other browsers you need to also specify the RevealToNonIE=”True”


Doing so will prepare that conditional CSS comments in a way that Firefox, Chrome or other Non-IE browsers can read them.


Controlling Multiple Loading

On benefit of using the SharePoint:CSSRegistration tag is to handle the issue of loading a CSS file multiple times. As CSS files grow bigger and bigger it can be a problem with page load times if you are loading multiple web parts and using the link tag

By using the regular <link> tag to reference your CSS files each time that gets hit it will load your css to the page.

Using CSS Registration will not do that. take this example below. I’m attempting to register the Style1.css, 2 additional times, and style0.css 1 additional time


and the output will only load the css files once


Specifying Current Site Collection Urls

Another benefit of using the SharePoint:CSSRegistration tag is the ability to specify files that live in the Style Library in a Site Collection not located at the root of the domain. What do I mean by that? Consider that we are building a branding solution and we are storing the files in the Style Library of that site collection and say for example that the domain is

So deploying our solution to would put the files in at Library/mycss.css. Now when we register the CSS files using the <link> tag it would look like this


Say you have sub site collections under another managed path that link would break. For example, consider another site collection called /Sites/SC1. This would be and the masterpage would try to find the file at Library using that <link> tag above.

That would NORMALLY not be a problem if the branding solution or files were deployed to the site collection at “/” and then at “/sites/sc1”. BUT if you only deploy the branding to the “/site/sc1” site collection the files would only exist in that Style Library for that site collection. So the links to the css would be looking at Library/mycss.css and be broken because the files are NOT there and the files are at Library/SC1.

So as confusing as that may have sounded there is an answer to handle that situation.

1. You deploy CSS and images to the Layouts folder – This makes the files available globally. Any reference to CSS or images should start with  /_layouts/MyDeploymentFolder/myCss.css

2. Use SPUrl to handle the adjustment of the link to the appropriate site collection.

Examining #2 – SPUrl

By using the $SPUrl:~SiteCollection you can specify a parameter which will return the current site collection. Below I’ve embedded into a master page


This is the result on my root site collection “/”


This is the result on another site collection under a managed path “/sites/sc1”


So as you can see, using this method you can deploy your css / images to the Style Library and be able to access them using this current site collection url parameter.

This about wraps up the major aspects of using CSSRegistration over Link. To sum up the main benefits we have:

Achieved with Link or CSS Registration

  • Controlling load order
  • Conditional CSS
  • Specify site collection relative style sheets

Achieved with CSS Registration only

  • Preventing loading the same file multiple times

SharePoint Saturday Boston – Slides & Demos

spsbostonWhat a great time the following weekend @ SPSBoston! The organizers did a fantastic job as usual.

Thank You to my session attendees. I’m hoping you learned at least 1 thing. I appreciate the great questions and the positive feedback! I had an amazing time up at SPS Boston and hope to have the opportunity to return next year when it will be at the new Microsoft office in Cambridge.

So a few things, my slides are available on Slide Share . I’ve added some Resources at the end of MSDN articles. I’ve added in the beginning a listing of tools and some links which I grazed over during the presentation but you can find out more from those links.

I’m temporarily hosting theme builder on my company’s site until they fix the download link –

And my project solution is available at –

My clean v4 masterpage is available at –

Thanks again, don’t hesitate to contact me with comments or questions.