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.
The Problem
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:
<body scroll="no">
So as a user, when I first visit a page that is presented in the SharePoint 2010 interface, scrolling is disabled. As the content is loading, I am unable to view anything below the fold, and must wait for a JavaScript function to execute and allow me to view overflow content. Let’s just hope that there are no JavaScript errors that would disable scrolling completely!
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.
The Reason
The purpose of disabling scrolling is entirely due to the new SharePoint 2010 “ribbon” control. This is a very handy element of the SharePoint interface that stays fixed to the browser window, even as you scroll down the page. Microsoft’s approach to implementing this ribbon is to separate every SharePoint page into divisions that are subsequently sized to fit the browser window using JavaScript. Every time you load a page, resize your window, or interact with content, the 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 (position: fixed), rather than relying on JavaScript and undermining the default behavior of the browser window.
Update (1/27/2011): I was able to figure out how to properly override SharePoint’s default behavior in order to create a CSS/JavaScript hybrid approach that is much more accessible. Read on for instructions on implementing this new work-around!
The Solution
What’s done is done, and now that I’m done griping, let’s get constructive and look at some potential resolutions for this issue. Implementing this fix requires adding both CSS and JavaScript to your master page:
- Remove
scroll="no"from the<body>tag (this fixes scrolling on older browsers like IE6). - Inside a
<script>block or in an attached JavaScript file, add the following script:function FixRibbonAndWorkspaceDimensions(){ ULSxSy:; g_frl = true; var elmRibbon = GetCachedElement("s4-ribbonrow"); var elmWorkspace = GetCachedElement("s4-workspace"); var elmTitleArea = GetCachedElement("s4-titlerow"); var elmBodyTable = GetCachedElement("s4-bodyContainer"); if(!elmRibbon || !elmWorkspace || !elmBodyTable){ return; } if (!g_setWidthInited){ var setWidth = true; if (elmWorkspace.className.indexOf("s4-nosetwidth") > -1) setWidth = false; g_setWidth = setWidth; g_setWidthInited = true; } else{ var setWidth = g_setWidth; } var baseRibbonHeight = RibbonIsMinimized() ? 44 : 135; var ribbonHeight = baseRibbonHeight + g_wpadderHeight; if(GetCurrentEltStyle(elmRibbon, "visibility") == "hidden"){ ribbonHeight = 0; } // Override default resizing behavior // -- adds padding to the top of the "s4-workspace" <div> if the ribbon exists and has content // -- allows the ribbon to be positioned using CSS instead of JavaScript (more accessible) // -- checks to see if the page is inside a "no-ribbon" dialog if(elmRibbon.children.length > 0 && document.getElementsByTagName("html")[0].className.indexOf('ms-dialog-nr') == -1){ elmWorkspace.style.paddingTop = ribbonHeight + 'px'; } } - In a
<style>block or in an attached CSS style sheet, add the following CSS rules to override the default overflow styles:body.v4master { overflow: visible; height: inherit; width: inherit; } body #s4-workspace { overflow: visible !important; } body #s4-ribbonrow { position: fixed; z-index: 1000; } #s4-ribbonrow .ms-MenuUIPopupBody, #s4-ribbonrow .ms-popoutMenu, .ms-cui-menu[id ^= "Ribbon."] { position: fixed !important; } .ms-dlgOverlay { width: 100% !important; }
This solution does two things: first, it will override the default appearance and behavior of the SharePoint interface, enabling scrollbars on your pages by default (much rejoicing is in order). Second, it keeps the ribbon fixed to your browser window using CSS (instead of JavaScript). Instead of resizing the s4-ribbonrow and 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.
Thanks Kyle. This works great!
If you are using the starter master pages be careful as your body tag may not have the v4master class which is assumed above.
Nice solution of the problem with the scroll in Sharepoint 2010 for sites that are branded. If you edit a page with this solution the edit mode it will overlaying the page content (header content etc). Trying to figure out if you could expand the height more via Javascript?
Unfortunately, this breaks the notification API. To test this, open up firebug and pop this into the console using v4.master, then try it with your modification:
SP.UI.Notify.addNotification('this breaks',true)Hi, Ali. You can actually move the notification bar anywhere you want — I generally don’t leave this in the ribbon, but rather choose to place it beneath my site’s header, which makes it a little more consistent when using the scrolling fix.
HI man thx for that but I tried and have the following feedback:
1) on the iphone it fixed the issue, and scrolling worked. Yay
2) But on the iphone and other computers/browsers, it seemed the page content was stuffed underneath the ribbon a bit. I think the starting position of the page was parallel with the ribbon, and not below it. So like 40 or so pixels (or was it 100) was under the ribbon and unviewable.
I was also facing the same issue with the starting position of the page. In the style within body #s4-ribbonrow removed position: fixed;
and now it is coming properly.
Hi Kyle,
It works fine except chrome browser. white section appears at the end of the page.
Any idea?
Reuma, I’ve used this a number of times and haven’t seen anything like what you describe in Chrome. You may want to inspect the white area of the page to see if it’s padding, a margin, or a positioning thing from some element in your design.
Hi,
I am calling .net page into content editor webpart.
but internal scorll bar is happing,i dont want that..while increase the .net page heigh due to adding the content internal scoll bar apping.but i want dynamiclly increatse the size of the page(heigh) is there any solution….
Seems like it’s not working in IE7 :-(
I was trying this out and one thing I noliced is when I add a Calendar web part to my page, the ‘Add’ link does not position itself properly when hovering over the day. If I am at the top of the page and haven’t scrolled at all, then it shows up properly, but once I scroll at all on the page it no longer shows up on the correct day. Is this something you have seen and if so have you figured out a fix for this?
Hi Kyle – excellent solution. It’s similar to a solution from Greg Galipeau’s blog ( http://www.greggalipeau.com/2011/01/28/a-better-enhanced-sharepoint-2010-floating-ribbon/ ), but yours seems simpler and free from some of the complications I was having with Greg’s (namely, with his solution implemented, any time you tried to move a modal dialogue by grabbing the title bar, it would jump up and attach to the top of the browser window and would from then on only move on the x axis – though to be fair, it could have been a combination of his scripts and something else I was running).
The reason I’m posting, however, is that there are a few issues with your version you may not have found yet, all having to do with positioning of tooltips and other SharePoint pop-ups. The best place to see this is on a calendar page; if you’re scrolled to the top of the page, everything works fine, but if you are scrolled down at all, when you over over a date, the “Add” link that pops up is positioned incorrectly (above where it should be, sometimes even outside the viewport), as SharePoint’s scripts do not take into account the scroll position of the body, since it assumes (rather foolishly) that no one would ever override the default behavior and make the body scroll. Greg found this bug and provided a fix in his scripts, but unfortunately, there are other places where the exact same thing happens – for instance, if you have the Ribbon open while a page is scrolled down any amount and then hover over one of the Ribbon buttons with a tooltip, that tooltip’s position will be similarly incorrect (I’ve had complaints from users where the tooltip would come up and cover the button itself, and they didn’t know how to get it to go away). Very annoying.
Any ideas? I’m a bit afraid to use any of these methods of overriding the default SharePoint scrolling (awful as it is) until I can implement something that gives a reasonable guarantee of fixing these sorts of issues globally (because even if we fix these individually, as Greg did in his script, the really scary part is the possibility that there could be dozens of other places throughout SharePoint that would suffer the same positioning woes).
Thanks!
Lucid, I’ve seen that behavior and I haven’t yet found a fix for it — I’ll definitely update this post if I can get some time to look into it. Thanks for the heads-up!
…and yes, that was a very long comment. Sorry bout that!
Oh great! Thanks!!
Hi kyle,
your article is great but requirement is i neeed to disable the back buttton in sharepoint default.master page.Please guide me regarding this issue.
That sounds like a terrible idea. Never, ever, disable or hijack the most essential elements of the user browser experience — things like the address bar, back/forward buttons, etc. These are (rightly so) in control of the user, and it infuriates people when you attempt to override that behavior. It’s better to handle questions like “What happens when the user goes back?” with good application design or in your site’s back-end.
Outstanding solution. Thanks for sharing.
Hi…I’ve inherited a Sharepoint project in the middle of development and am working on implementing this solution. Something in this instance of Sharepoint has been modified such that the FixRibbonAndWorkspaceDimensions function is not being called on load, resize, etc. Does anyone know where that function is called from?
Thanks,
Darren
I had a small issue with the code: it was adding the padding for anonymous users. The reason turned out to be that your code checks for the Ribbon div’s visibility property, not whether the Ribbon div even exists. So I changed the following line:
if(GetCurrentEltStyle(elmRibbon, “visibility”) == “hidden”){
ribbonHeight = 0;
}
to this:
if(GetCurrentEltStyle(elmRibbon, “visibility”) == “hidden” || getElementById(‘Ribbon’) == null){
ribbonHeight = 0;
}
Thanks for the code!
Pasted the wrong code….
Change this line:
if(elmRibbon.children.length > 0 && document.getElementsByTagName(“html”)[0].className.indexOf(‘ms-dialog-nr’) == -1){
elmWorkspace.style.paddingTop = ribbonHeight + ‘px’;
}
To this:
var elmRibbonContainer = GetCachedElement(“RibbonContainer”);
if(elmRibbonContainer.children.length > 0 && document.getElementsByTagName(“html”)[0].className.indexOf(‘ms-dialog-nr’) == -1){
elmWorkspace.style.paddingTop = ribbonHeight + ‘px’;
}
On my site, at least, the “s4-ribbonrow” div has children even for anonymous users, so the padding was being added. The “RibbonContainer” div does not.
Kyle, this is brilliant!
I am having one issue, which I hope you can offer some insight.
When I try inserting ‘reusable content’ onto a page, as I move my mouse through the list of reusable content, often the content gets inserted right away, instead of simply presenting it as a preview. When this happens, the reusable content flyout menu closes – in the same way as if I actually clicked on a reusable content.
Cheers!
Mark
I forgot to mention the above behaviour only happens in IE. I don’t get this weird behaviour using FireFox.
Hi, Mark. I haven’t seen this yet, although most of the problems I’ve encountered with this script are related to drop-down menus in the ribbon. I’ll check it out and let you know if I figure out a solution.
Hello Kyle,
I was able to determine that the problem occurs when the reusable content HTML is vertically long. The content has to be vertically tall enough to populate beyond the physical fold of the page. If the reusable content vertical real estate is short enough, then I don’t see the problem.
I hope my explanation helps provide more insight.
Cheers
Kyle,
I continue to struggle to figure out a workaround to my issue. Do you have any tips on how I can determine which java-script function is responsible for the functionality behind the ‘insert reusable content’?
Cheers
this worked well but needed a few adjustments when being used for external websites with anonymous users.
Here is what I did to make it work for admin users and anonymous users:
1) In the Master, above , add:
document.getElementById(“s4-ribbonrow”).style.display = “none”;
document.getElementById(“s4-ribbonrow”).style.display = “block”;
2) Adjust the Javascript that Kyle had:
Was: if(GetCurrentEltStyle(elmRibbon, “visibility”) == “hidden”){ ribbonHeight = 0; }
Change to: if ((GetCurrentEltStyle(elmRibbon, “visibility”) == “hidden”) || (GetCurrentEltStyle(elmRibbon, “display”) == “none”)) {
ribbonHeight = 0;
}
Correction: The post didn’t paste the way I wanted: (I deleted the gt and lt in order to post)
Step 1 is:
script type=”text/javascript”
document.getElementById(“s4-ribbonrow”).style.display = “none”;
/script
Sharepoint:SPSecurityTrimmedControl ID=”SPSecurityTrimmedControl2″ runat=”server” PermissionsString=”AddAndCustomizePages”
script type=”text/javascript”
document.getElementById(“s4-ribbonrow”).style.display = “block”;
/script
/Sharepoint:SPSecurityTrimmedControl
that’s a bad idea for public internet sites using SP2010, because you’re still rendering all the markup at the server side for the ribbon control, and affecting the payload size. You should, instead, apply the SecurityTrimmedControl to the whole ribbon UI, so that it only loads up for authenticated users.
Anonymous users should not even get the markup, and should not have to rely on client script to hide something in the DOM.
When I apply your fix, the SP Status bar (pageStatusBar) disappears. This is only relevant for the authoring site, not the anonymous site, but I would like to see that status bar.
Also, as mentioned in the 1st comment, you’re assuming that we have the css class “v4master” applied to the body tag, but I started with the Starter Master Page, by Randy Drisgill, which does not have this class.
Hi, Thiago. I’ve had some trouble with the status bar as well — generally when I use this method to fix the scrolling issues in SP 2010, I’ll opt to move the status bar into a more static location (instead of in the ribbon). I generally place it in the header area of the page, like just beneath the global horizontal navigation menu. This seems to work a little better than trying to fit it into the ribbon.
Concerning the “v4master” CSS, the only thing in my code that uses this class is in the CSS where I’m trying to remove the “overflow” behavior of the <body> element. If you don’t have this class, you may need to inspect the page and make sure you don’t see
overflow:hiddenon the <body> element.Pingback: My bookmarks for the week « MarkjOwen's Blog
I had to remove the last 3 classes from the lot I copied here for the scrolling on my site to work, but I think it clashed with my existing styling. Very useful – Thanx a mil :)
Thanks it helps me lot..
Great, Exactly what I needed… cool staff :)
Thanks – I believe this solution is being used in the site I’m maintaining, however, we are having problems in FireFox when a dialog is opened. The height of the dialog is the same the height of the ribbon, so that scrolling doesn’t show the body of the dialog. Any idea how to fix?
It’s nice to work something out. But I think it’s a bit too much work for the solution.
The Scrolling isnt the main Problem imho, why dont just overwrite the Style?
Cheers
Kyle,
Many thanks, you made me save a lot of time!
Cheers
Many thanks and great job
I tried to use this in a MySite master page, but it added a significant amount of white space to the top of the page even in IE. Have you see that?
Grats. You just broke your calendars.
Pingback: Scripting the position of the ribbon on public facing sites - Small City Design
This fixes the scrolling issue in Chrome but breaks scrolling in IE7. Anyone have a solution or know how to correct it?
Thanks. It helped big way :)
Pingback: Robyn Hutton Cerda - SharePoint 2010 List Item Context Menu Scroll Positioning Issue
Pingback: How I fixed SharePoint 2010 scrolling for Chrome, iOS4 & Andorid | Brain Lava
Hi Kyle, I want to disable the horizontal scroll bar in my web page but not the vertical one.
So can you hhelp me,how can I proceed with the same if I want to do so by changing the html codes in the content editor web part??
Thanks in Advance…
I find something different when i click on “Modify Shared Webpart” in a particular page in my Sharepoint site.
Except that of the master page, all the other is compressed(we can say minimized) into one single line along with a small up and down scroll buttons.
When i click on the down button, i can see the contents moving inside a small area just below the title of the page.
This is very important.
I am not a sharepoint developer. I only have to post some content into the site.
Please Please Please Please find me a solution for this…!!!!!!
Mail me to vineeth.veetil@wipro.com
Pingback: Software Design » A Better Enhanced SharePoint 2010 Floating Ribbon
how do i make the page align to the left instead of centered?