SharePoint Branding & CSS Specificity
We all know that best practices SharePoint branding avoids the use of !important in your CSS, but how do you correctly control the specificity of your CSS to mitigate the need for it?
The order of operations for your CSS depends on a number of factors, including the loading order of the stylesheet, the order of the styles within that stylesheet, and lastly the specificity of the style. SharePoint allows us to use the <SharePoint:CssRegistration> tag to help provide greater control over the loading order of stylesheets and ensure that your custom style sheet is loaded after all of the core ones. This allows us to easily override the out of the box classes easily, since styles loaded later will override matching properties of identically named styles loaded previously.
I recently ran into a problem when branding SharePoint 2010 MySites for a client. The SharePoint core CSS has classes for branding the “Add New” links on the bottom of list/library web parts (.ms-addnew a:visited, .ms-addnew a:active, .ms-addnew a, etc.). Simple enough, my custom stylesheet that is loaded after all of the core ones overrides the link color to my desired color. But on the MySite, there’s another core stylesheet (portal.css) that gets loaded as part of the layout of the MySite. The CSS link is actually rendered inside the main content placeholder, not in the head. These same few styles are redefined in portal.css, and since that is loaded later, it overrides my override of the core style.
Some people might now stand up, voilla… this is one of those cases where “you HAVE to use !important”, but this is not the case. Remember that little thing called specificity? A style loaded later will not override a previous style if that previous style has greater specificity. Since .class .class element is more specific than .class element, the browser will always choose a more specific style over a newer one.
This being said, crack open your custom master page, and find the opening <body> tag. If your masterpage has been derived from the default out of the box master, you’ll likely see that the body tag has a class attribute with a value of “v4master“. Add a second value to the class attribute (ie: class=”v4master customBranding”). We can now define more specific styles using the .customBranding selector. Using .customBranding .ms-addnew a will always take precedence over the .ms-addnew a in portal.css purely because it’s more specific than any styles already defined in the core stylesheets. No !important here.
Enhancing SharePoint 2010 for the iPad (SPSAusTX 2012)
Despite being marketed as an entertainment device rather than a mobile platform for business, the iPad continues to gain traction as a mobile device for the next generation business user. For some organizations, the rich user interaction and usability afforded by the iPad is a compelling reason to work towards cross-platform capability or iPad specific versions of line-of-business systems. In this session we’ll review custom iPad specific enhancements for SharePoint 2010, including changes to the user interface based on the orientation of the device.
Presented at SharePoint Saturday Austin, TX (January 21, 2012).
Demonstration Video:
Enhancing SharePoint 2010 for the iPad (SPSVB 2012)
Despite being marketed as an entertainment device rather than a mobile platform for business, the iPad continues to gain traction as a mobile device for the next generation business user. For some organizations, the rich user interaction and usability afforded by the iPad is a compelling reason to work towards cross-platform capability or iPad specific versions of line-of-business systems. In this session we’ll review custom iPad specific enhancements for SharePoint 2010, including changes to the user interface based on the orientation of the device.
Presented at SharePoint Saturday Virginia Beach (January 7, 2012).
Custom CSS and SharePoint Branding (The Right Way)
There was a post on Stack Exchange this morning that struck a bit of a nerve with me. I don’t aggravate easily, but I’m a firm believer that the purpose of public discussions is to promote best practice methods and share that knowledge with people that have asked for answers to their problems. When best practice approaches were suggested by James Love (@jimmywim) and myself, we were practically attacked by people insisting that their practices were the way things should be done. I’m not naive–there’s a lot of people that make a lot of bad decisions–but the purpose of the community should be (and largely is) to help share the right way things should be done. The size of the deployment or scope of the customizations shouldn’t be an excuse for making bad decisions and following bad practices. At the risk of beating a dead horse, this is the best practices approach for deploying custom CSS styling in SharePoint (and why you shouldn’t be using these other methods).
Suggested Method 1: Write your own custom CSS selectors, and put !important on every selector.
The first suggestion on Stack Exchange was that you had to put !Important on all of your selectors to override any SharePoint styles. If you find that you need to use !important to make your CSS take priority over the out of the box CSS, either your selectors are wrong, or your custom CSS is being loaded before the core CSS. When CSS is rendered, the highest priority selectors will be those that are the last to be loaded (unless an !important declaration exists). Not as big of a deal here but in terms of the actual order of operations, your browser will also treat any inline style attribute as a higher priority than your stylesheet (be it embedded or linked). SharePoint’s core CSS uses nested selectors, so the selectors for your custom CSS must follow suit. If SharePoint us using “body .s4-ca” and you make a custom selector called “.s4-ca”, the browser will render the more specific selector since it has a higher priority. Using !important is a bad practice (for all CSS/web development, not just SharePoint), because it drastically changes the approach you need to use to override that selector/class later. Finally, you need to think about cross-browser compatibility. In SharePoint 2010, this absolutely applies. In a lot of cases, you must write a style one way, then write a modifier to make that style render correctly in older browsers. Flagging !important on all of your styles makes this a real mess.
The use of the !important flag is simply a lack of understanding for how the browser will prioritize CSS markup. There’s a lot of resources out on the web that cover this, but in a nutshell: more specific selectors have priority over less specific ones, and in a scenario where two rules have the same weight, the last one specified will have a higher priority. Use debugging tools such as those in Internet Explorer or the ones within Google Chrome or the Firebug extension for Firefox to identify the selectors that SharePoint uses. Personally, I prefer Chrome because the developer tools are included without the need of an add-on, and you can make real-time changes to the CSS which are rendered in the browser as you edit (making it an excellent development companion when authoring new CSS). Once you know what selector SharePoint is using, use that same selector. Lastly, make sure that your custom style sheet is being loaded into the master AFTER SharePoint’s core files because remember, when rules have the same weight, the last one loaded takes priority. This ensures that your styles take over, without filling your markup with !important flags.
Suggested Method 2: Just modify the core files in SharePoint Designer.
Obviously it’s a bad practice to edit any core files, be it Master Pages, CSS or JavaScript. A particular user was adamant that it was an acceptable method because when you customize a file in SharePoint Designer a local copy is created just for that site, so you’re not affecting any other sites on the farm. While this is true, updates to core files can still be made during service packs or patches, leaving your customized file behind. Granted your custom master pages are never going to be updated, but keeping the core files uncustomized ensures you have a supported rollback plan–something you obviously loose when you start customizing the core files. There’s a lot of talk about SharePoint upgrades these days, and this is one of the things that will potentially make your upgrade an utter nightmare. Sure, you can go in and reset all of the customized files to their definition, but should you have to? Making a copy of a file takes all of a couple seconds and it will make your life 10 times easier if you need to reset to vanilla SharePoint. Can you just edit files, yes. Does it work, yes. Should you do it, no.
Best Practice Method 1: Branding Deployed via Solution
Hands down, the best practice for branding deployment is a Visual Studio solution packaged into a WSP and deployed to the farm. This method makes maintenance and updates to your branding solution easier, gives you more robust change control, and integration with source control (such as Team Foundation Server). Deployment via solution also makes your branding reusable between multiple site collections. Unlike modification of files in SharePoint Designer, you no longer have to touch 10 master page files to brand 10 sites; simply activate the solution. If you need to deploy an update to your solution, the update will automatically be pushed to each site where the solution is active (assuming you haven’t customized the files in SharePoint Designer). A correctly built branding package will also give you the capability to rollback to vanilla SharePoint with just a few clicks. It may not seem like an important thing now, but when you go to upgrade to the next version of SharePoint you’ll be glad you can do that.
Best Practice Alternative: SharePoint Designer
SharePoint Designer is a tool that has a lot of functionality. Yes, you have the ability to modify master pages and things of that nature, but it doesn’t mean that you should. Simply because you can do something doesn’t make it a best practice. That said, in certain environments you may not have the ability to deploy a solution; either due to a lack of staff with the know-how, a policy restriction, or lack of the necessary access to the server. In those scenarios (and only in those scenarios) should SharePoint Designer be used for branding. If you must use SharePoint Designer, you should follow some common-sense guidelines, one of the fundamental ones being to not modify out of the box files. If you need a custom master page, make a copy of the v4.master and work from that.
Where Should the CSS Live?
The purpose of a stylesheet is to promote reuse. It doesn’t make much sense to include your styles in every page, and in SharePoint 2010 where we have standard and minimal masters, it doesn’t make sense to duplicate your common styles by including them in each master page. Your stylesheet should be an external file, stored where it can be used by all instances of the masterpage(s) using them. If you’re deploying your branding using a solution, then most likely these files should live in a folder within the 14 hive. I’m personally not a fan of putting them in the style library, since (despite being able to manage it from the 14 hive), your browser will treat them as separate files for each site collection. This means that my browser will re-cache my stylesheet for each site I go to, even though they’re exactly the same file. If it’s 10 lines of CSS then this is negligible, but if I’ve got a few hundred it makes a difference.
Continuing Education
I’m not one of those people that usually promotes books, but if this topic is something that you wish to brush up on I suggest you get your hands on a copy of Randy Drisgill’s (@drisgill) book. He covers (in detail) processes for branding as well as the issue of CSS priority.
Demo
James created a great screencast that shows the process for correctly referencing external CSS files using the SharePoint:CSSRegistration tag. Check that out below, and visit his blog at http://e-junkie-chronicles.blogspot.com/.
SharePoint Saturday Tampa
For anyone interested, here’s the slide deck that I presented at SharePoint Saturday Tampa on June 11, 2011 on Enhancing SharePoint 2010 for the iPad. You can also download a copy of the slides here.
Enhancing the SharePoint 2010 UI: Scripted Orientation Aware Content
In my previous post we looked at enhancing the SharePoint 2010 UI through CSS based orientation detection. In this post, we will take it one step further and use some client side script to detect orientation and output content accordingly.
The CSS approach utilizes orientation aware style sheets which are loaded based on the appropriate orientation of the device (in this case an iPad). While this approach is simple to implement, it’s not necessarily the most robust solution or the most scalable solution. The CSS approach is best suited to deployment with your site’s branded master page, when orientation detection is a big part of your design. What if you only wanted it on one or two pages of your site, if you don’t have access to deploy a new master page, or if you want more advanced orientation detection?
Enhancing the SharePoint 2010 UI: iPad Orientation Detection
I recently had a chance to sit down and rapid prototype some iPad UI Enhancements for SharePoint 2010. I had previously done some light orientation detection for the iPod and iPhone, but with the iPad there’s a lot more power in utilizing orientation detection. As the iPad gains more traction in the business world I expect to see more and more requirements to make enterprise platforms [like SharePoint] usable on the iPad. With Microsoft’s commitment to cross-browser functionality in SharePoint 2010 we’re fortunate that SharePoint 2010 will render on the iPad without any customizations needed.
The typical approach to porting desktop content to a mobile device is to scale content down to fit it all within the mobile device’s display. With orientation detection we can turn off specific regions of content, or change the layout completely in order to maximize on the screen real estate and mitigate the need to scale down content–relative to how the user is holding the device. If we use the iPad as an example, in landscape orientation the resolution is 1024 x 768 but when we move it to portrait orientation the resolution swaps to 768 x 1024 (~250 pixels less on the width). Again, typically we’d just scale everything down to compensate for that drop on horizontal screen real estate. With a platform like SharePoint, making things smaller inherently makes it more difficult to navigate and the two-finger horizontal scroll on the iPad isn’t really all that intuitive. The solution is to detect the orientation of the device and restructure content accordingly.
Print Formatting via CSS
There was a post over on End User SharePoint: Stump the Panel that talked to the notion of generating SharePoint reports for print. While the use of a print media stylesheet wasn’t necessarily the only solution to this particular users problem, it was an interesting point that is not often mentioned or implemented well. As opposed to writing a full fledged article I thought I’d offer some informal points on the matter.
Many websites offer single-click facilities for users to print page content, but quite often those buttons call a page that’s been specifically formatted for print, or restructured to purely tabular data. However, it’s amazingly simple to control print formatting via a print media stylesheet, and can save a lot of resources when compared to the approach of standing up separate print scripts and pages.
Before we show you how to do it, let’s look at an example. The Dell Community blogs, notably Direct2Dell are setup with a print media stylesheet. If you were to go to the Direct2Dell blog and view the source, you’ll notice a link reference for a stylesheet that defines the media parameter as “print”. This indicates that the stylesheet in question will be applied when the page is processed by a browser print operation. Likewise, you’ll also see a link reference for a “screen,print” stylesheet. This combination of values indicates that the stylesheet will be used for both print operations, and on screen rendering. This capability means we can contain the core brand elements such as font, color, and other general formatting in our common stylesheet, then apply additional constraints or formatting rules for print media.