Ahhhh, the Ribbon!

Let me say first that I definitely like the Ribbon, especially from a user interaction perspective. You have to get used to it, but we have to admit that this kind of user experience was not introduced with SharePoint 2010!

We got Office 2007 some years ago. We are seeing Windows tools that have been rebranded this way (Paint? Wordpad?). Components vendors are providing a ribbon framework since 3 or 4 years, which means that a crew of developers are releasing Windows Applications with a ribbon on top (even when it is not suggested by official or common-sense guidelines).

That said – and here my complaints start – the ribbon is quite an obtrusive component. And this is especially true when it is used in web applications, where you have a much more fragile control over the final layout your users will be experiencing. I’m a fan of the ribbon, but I still have to struggle a little bit to convince myself that it’s good as well for html rendering.

Let me expand these considerations with a couple of more practical examples.

Imagine you are realizing a public, internet-facing web site. And you do this with SharePoint, right? J

It will take you a couple of hours to realize that the ribbon should be made available to content editors, but you need it to be hidden to anonymous users (or more generally to site viewers).

A ton of articles and tutorials have been written, and it’s not so complicated as it may seem: you can use some trimming controls (SPSecurityTrimmedControl, LoginView, EditModePanel, AuthoringContainer, something you have developed yourself, etc) and just prevent it from rendering.

Will the ribbon be visible? No. Will it take part to the page markup? It depends.

The reason why it depends is strictly related to the way you are hiding the SPRibbon control.

Are you using some CSS attributes (display:none) applied to some container? Ok, go back immediately and try another approach: the markup fragment is there, and it is useless.

Are you using some server-side visibility logic (as suggested above)? Ok, the ribbon markup is not there any longer. Much better! Well done! But…

Have ever noticed that you are emitting tons of javascript code and did you ever wonder where that script code comes from?

Most of the times, ASP.NET controls generate JS code by with the help of some ClientScript.Register<Something> method. If you want to spend some time in front of a decompiler and start investigating how SharePoint controls behave, you’ll find out that many of them contain a bunch of code like the one I’m showing right below:

If (SPRibbon.GetCurrent(Page) != null)


// Write 10 KBs of ugly JS


Is this harmful? Hopefully not.

Does this execute if you have hidden the ribbon control? Probably yes.

Indeed, many conditional panels (SPSecurityTrimmedControl, for example) apply their conditional logic very late in the page rendering lifecycle (usually during the PreRender phase). And they are just preventing the ribbon to render, they are not eliminating it from the page control tree!

Which means that any control on the page that checks for the existence of the ribbon will succeed in

this check and perform whatever operation it is supposed to do.

Summing it up:

· The ribbon is hidden

· It does not occupy bytes inside the page body by itself

· It has “side effects”, causing other controls to emit extra markup or, more generally, to behave inconsistently

How can you fix this?

You could use some smarter conditional logics (a SmartPanel, if you like the name) that could just “ignore” its contents if the condition is not met. By “ignore” I mean that this panel should not add its child controls to the control tree at all.

While I would suggest you to carefully consider this approach, I would also like to point-out some drawbacks you may face.

If you remember, I had mentioned two side effects at the beginning of this article. So here’s the other one.

The SPRibbon control automatically sets the MaintainScrollPositionOnPostback property on the page to true. Which means that, after a postback, the user navigation is taken back to the same vertical scroll position he had set before.

Is this good or bad?

Well, it depends, of course.

But you have to take care of this behavior, since the sole presence of the Ribbon control may vary this after-postback setting: if you hide or show the ribbon based on the user rights, you end up having users with different rights having a different navigation experience. And… this does not depend, this is bad by definition J

Leave a Reply

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