Skip to content

The Pains of Altering the SharePoint UI

Hirschs Branding Effort
Hirsch's Branding Effort

I was recently tagged to “brand” a SharePoint installation for Hirsch Pipe & Supply Co.  I knew it would be an interesting challenge, but I had no idea how bad it truly would be.

SharePoint is built on ASP.NET 2.0 which I had worked with in my previous job. I found ASP.NET very powerful and flexible. Master pages, App_Themes, CSS Friendly Adapters, and more made working on ASP.NET interfaces relatively painless.  Knowing that SharePoint utilized master pages I thought it would be much easier than it was.  However, it turned out to not be the case.

The Default Master Page

I was immediately struck by the mess that is the default master page.  The master page is laid out with, of course, tables which is reminiscent of why Microsoft is such a joke in the designer world.  Well, I decided to rip out the tables, and surely that would make it easier right?  No.  It turns out that SharePoint only uses one standard ASP.NET control (the navigation control), and the rest are SharePoint specific “delegate” controls which made layouts with CSS difficult.  These are of course stored on the file system, and the only way to edit them is to create painful features.  It looked as though I was stuck with extensive tables for much of the layout.

When I did yank out much of the table layouts it only opened up a headache down the road.  It was actually more painful to try and layout it with CSS then just sticking with the table layouts.  What made it difficult are the extensive nuances in the SharePoint interface that are dependent on others.  For instance, I would lay it out in CSS, but when I went to edit the page to add web parts everything went awry due to dependencies on extensive tables for layout.  I was able to lay out the majority of the default master page with CSS, but I ended up reverting to tables for the main content area due to pain after pain. I did go with Heather Solomon’s minimal base master page for publishing sites which was a better start then I had.


The fun doesn’t stop there.  SharePoint has a core stylesheet that is over 4,000 lines long.  I’ve dealt with more styles in one shot, but looking at the stylesheet you would think a 10th grader created them.  There is a lack of shorthand, units of measure, and extensive IE proprietary styles.  Add onto the fact there are no comments in the stylesheet it is absolutely useless to attempt to decode it.  You also can’t simply remove the core styles; well, you could, but it’s another headache that is ultimately not worth tackling.  It’s again easier to deal with the bad then try to make it better.

SharePoint does allow you to specify an alternate stylesheet which does, thankfully, get rendered after the core styles.  The cascade becomes your best friend in altering the styles.  You’ll also notice the “classitis” that abounds in the master page and core styles.  They all have a prefix of ms- which is unneeded and unhelpful.  I wasn’t surprised to find a lack of advanced CSS 2 selectors due to the pressure to support IE 6, but they are hardly any descendant selectors which would drastically decrease the amount of classes in the markup.

The JavaScript

I know Microsoft is now supporting jQuery which we can only hope will reduce the amount of “obtrusive” JavaScript through the site.  It reminds me of how I wrote JavaScript back in the day.  Attempting to decode the core JavaScript is a puzzle I didn’t even attempt.  You are once again forced to use proprietary JavaScript instead of taking it on to write it any better.  If they did abstract the obtrusive JavaScript it would drastically decrease the complexity of the markup sent to the browser. I did end up using jQuery to set the size of certain divs, and I also attempted to clone() and append() DOM elements but it proved fruitless.

Hope for SharePoint vNext

I hope, first that I never have to alter the SharePoint UI again, but that the next version of SharePoint will construct a better default UI with the following changes.

  1. Use CSS for layouts.
  2. Ditch the delegate controls to use more of the standard ASP.NET controls (or at least improve them).
  3. Use a well-commented core CSS file with advanced selectors to eliminate the need for classes.
  4. Switch to an unobtrusive JavaScript model.
  5. An increased focus on accessibility for public-facing sites.


  1. Danny

    In total agreement with you. Heather’s “minimal” master page and the themes Woody linked are great resources. Another major point of “pain” has been the fact that the application pages (“_layouts”) do not use the same master page as the default pages. So searches and list views and such clunk back and forth in terms of design. There are tools in codeplex to address this issue but I’ve not had any success with them to date.

  2. @Danny, That’s why I always reocommend going to CSS and Themes first, then just tweaking the master where needed, rather than going straight to building a master page from scratch.

  3. Thanks guys for stopping by.

    @Danny: You are right that the fact they use different master pages is baffling, but you can specify to use the same master page for both layout and regular pages when you specify and alternate master page.

    @Woody: From my experience of using a minimal master page I would agree that it is more pain than it is worth.

  4. […] Okay. Okay. Let’s assume you are having no problems customizing SharePoint to your satisfaction. Let’s go further and grant you the super-power of customizing SharePoint files on disk without fear of Microsoft corrupting your changes with a Service Pack or simply by running the SharePoint Products and Technologies Configuration Wizard. Let me direct you to the bottom line as described by a SharePoint consultant in “The Pains of Altering the SharePoint UI”: […]

  5. Absolutely valid comments. Branding in SharePoint can be a royal pain in the a$$, luckly vnext is much much better on pretty much all points that your hoping for (MS got the message lol). I always thought they ran out of resources and had the intern take care of branding functionality :) .

    Saying that the one thing I thought worth noting is your comment on delegate controls. Typically Delegate controls are actually standard controls at run time. Delegate controls are just a way for SharePoint to designate what goes inside the delegate “bucket” that can be changed easily without updating the masterpage. For example if your using WSS you get the “basic” search control, if you’re in MOSS then you get the advanced workflow without having to update your masterpage but its all in the search delegate control. If you want to ditch the delegate control and “hard code” whichever version you want to get more control you can do that. Good luck on your new role :)

  6. @Josh: Thanks for your comments. I just posted another post on my feelings regarding the markup in 2010. Thanks also for your clarification on delegate controls. I’m no ASP.NET master!

    I tried to load your site, but it’s not resolving.

Leave a Reply

Your email address will not be published. Required fields are marked *