SharePoint 2010 Scrolling
If I have one gripe about SharePoint 2010, it’s scrolling. It’s something I’ve bumped into in every 2010 project I’ve worked on thus far (which has been a lot). First, I’ll explain the problem, and we’ll subsequently look at some potential solutions (which have their drawbacks) for this highly visible and hotly debated element of the SharePoint interface.
First of all, I’d like to say that as a designer, there are a few things that you simply don’t touch. The interface of the browser window is really quite simple: an address bar, navigation buttons (back and forward), refresh, stop, and a big area where users can read, click, and scroll. This is the very essence of the web, and it’s something that, as a designer, you simply don’t undermine. Ever.
As I’m browsing a website, I expect these fundamental elements of the browser to function at all times. It drives me crazy if suddenly I decide to use the “Back” button and get an error message, as if I have done something “wrong” by using these common features of my browser window. Assume your users will utilize these features, and never, ever undermine the functionality of these exceedingly important user interactions. It’s up to you to handle the interface and the functionality of your website, not your users.
And thus, we reach my gripes about the SharePoint interface and issues I have had with scrolling. As an internet user, I expect to have the ability to scroll. That sounds so simple, so easy, but for some reason, the SharePoint 2010 interface undermines this scrolling behavior. The
v4.master master page file includes a line of code that looks a little like this:
Furthermore, this breaks the functionality of any anchors on your page. For instance, if you click on a link that includes
#comments on the end of the URL, users will not be able to see the comments section of the page that subsequently loads. Instead, pages are always displayed starting at the top of the page. This is definitely not a practice in progressive enhancement.
FixRibbonAndWorkspaceDimensions() function will run to ensure that the ribbon and content divisions are appropriately docked within the browser window.
I can definitely understand the reason for wanting a fixed ribbon, but what I don’t understand is the manner in which it was implemented. Personally, I would have implemented this almost entirely using CSS (
<body>tag (this fixes scrolling on older browsers like IE6).
- Inside a
- In a
<style>block or in an attached CSS style sheet, add the following CSS rules to override the default overflow styles:
s4-workspace divisions, I’m simply adding some padding to the top of the
s4-workspace element. Every time the ribbon “resize” script runs, it bumps your content down a little to make sure you can still see your site header.
This should work on any master page that uses the “v4” SharePoint interface. I’ll be using this method on every SharePoint site I create from this point forward, so definitely keep this in mind in your own SharePoint design ventures! Best of luck, and please let me know if this helps you in any way.
Update 1/28/2011: Slightly modified script and CSS to resolve a couple minor bugs that I found in SharePoint dialogs.