The Pains of Altering the SharePoint UI

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 CSS

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.