Archive for the ‘SharePoint’ Category

Friday, October 12th, 2007

SharePoint Branding Issues: Table Of Contents WebPart

On one of my projects I had to customize the table of contents webpart. This webpart can list pages, lists and subsites of a specific site, and this in a custom organization and presentation. When using it on the default master page, it shows the content in different levels with some nice indentation applied to it.

Table of Contents using default.master

But when I activated my custom master page, the indentation suddenly did not show. My first reaction was: “OK, this surely is some classic CSS problem. I’ll just set the correct class back in my custom CSS file.” However, whatever I tried, whatever CSS rule I put in, the indentation did not come back. Worse, there’s already margin applied to the elements, hard coded in the webpart. But Internet Explorer did not seem to wanna show it when using my master page. And this was only the beginning…

When stripping down both the default master page and my custom master page down to the bare necessities (no css files, no other controls, … nothing), the default master page still showed the indents while my master page didn’t! And to get even more confused, the other MOSS master pages do not show the margins either! This is weird.. very weird. What the hell makes the difference?

Table of Contents using OrangeSingleLevel.master

And then it hit me. My master page and the MOSS master pages use following code, where the default.master does not:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

For those of you who do not know what this is, you can read all about it over here . Basicly, it instructs the browser how to parse the HTML and CSS. How is this relevant, you ask? Well, as I said, the table of contents uses some inline code to display the indentation.

      <div style="margin-left:12;">

At first glance, this seems spot on, correct. Except, it isn’t. Though the default behaviour of Internet Explorer would accept this line. When using the doctype, Internet Explorer demands more precision and clarity. What kind of clarity? This kind:

      <div style="margin-left:12px;">

Yes, indeed, it’s the unit. Doctype requires correct values and units. And if those are not available, the browser will simply ignore the values. So what are the implications? All MOSS master pages and custom master pages, using this kind of doctype, will not show the identations. Talking about a bug.. ;-)

The solution, of course, is adding the ‘px’ unit to the style. Luckily, the table of contents is one of those webparts which uses XSL style sheets to format its data and makes those available in the Style Library within your SharePoint site collection. Once inside this style sheet (LevelStyle.xsl), one can easily add the px to the different styles using the margin. This creates an instant solution to the problem. If you want to apply this to your entire farm, go to your server and adjust the LevelStyle.xsl in the PublishingResources feature.

Fixed Table of Contents using OrangeSingleLevel.master

For the aftermath: this is sort of a silly problem. It could have been easily prevented. Nevertheless, these kind of problems are very hard to track down. My fear is this is not an isolated case and there could be more of those little ‘bugs’ within SharePoint, due to inconsistent use of CSS. This is quite a shame, I think, for such a rich product. :-(   But anyway, what have we learned today? Always set your units in CSS! ;-) See ya next time.

Wednesday, October 10th, 2007

SharePoint Branding Issues: ASP.NET Flyout Menus

The most prominent way to navigate within a SharePoint site is using the menus. SharePoint has two menu structures: the top main navigation, and the quick launch navigation which is usually located at the left side of your screen. When you’re defining the menu structure, you might consider flyout menu’s. These javascript powered menus will popup whenever you hover over their parent’s node. They have a huge space saving gain, so they are quite frequentaly used.
As they are native ASP.NET controls, you can somewhat customize these menus. This can be done by editing the master page. See msdn for more options on these menus.
There is, however, a nasty little issue when custom branding these flyout menus. Let me show you:

Dynamic menu with background color issue.

For some reason the background of a dynamic menu would not change when setting it in the CSS class of the menu. (You can specify a CSS class for the ASP.NET menu to use) A possible resolution would be to change the background of the nodes themselves.

Dynamic menu with item background colored. 

Unfortunately this gives some nasty gaps when using margins. I just had to find a way to color the background all together. When investigating the thing, I discovered this in the output.

.zz1_GlobalNav_0 { background-color:white;visibility:hidden;display:none;position:absolute;left:0px;top:0px; }

Somewhy, something had outputted some extra styles straight into the master page. Firstly, inline CSS, I really discourage using CSS like this, unless for testing purposes or if there really is no ther way. However, even I get sometimes tempted. But the point is, it’s bad, as it blocks using external CSS files. Secondly, why is the background color white? Once again I had to rely on Reflector as the ultimate resort to find what went wrong and how those styles were rendered. This is what I found in the PopOutPanelStyle class:

if (base.BackColor.IsEmpty && ((this._owner == null) || this._owner.BackColor.IsEmpty))
{
attributes.Add(HtmlTextWriterStyle.BackgroundColor, "white");
}

In other words, ASP.NET automaticly adds a white background when there is no background color defined in the color and the when the parent is empty. And this was the case in my example. So what is the solution? Putting the color directly as parameter in the control using BackColor.

You didn’t really think I would leave it at that, now did you? Well, there is another solution. As I couldn’t live with the fact there was a color directly defined in the master page, I continued searching. Finally, it was the magical CSS which, once again, offered a nice way out. When rendering a dynamic menu, ASP.NET first renders an absolute positioned panel with the actual menu table in it. And it’s this panel which has the menu’s CSS class reference, instead of the table with static menus. This gives us some flexibility. Thanks to the cascading styles, we can reach the untampered table with the following reference: .navGlobalFlyOuts table, allowing us to set the background after all:

.navGlobalFlyOuts table
{
background: #F7DCEA;
}

Once again, CSS has saved the day. Thank you CSS. ;-)

Dynamic menu with correct background color.

Tuesday, October 9th, 2007

SharePoint Branding Issues: MySite Control

This is the first of the more specific articles regarding SharePoint Branding. They will go from small issues to bigger ones.

One of the controls a SharePoint design usually sports is the My Site control. This is a control with a link to the current user’s MySite. But unfortunately this is not the only thing this controls adds. It also adds a pipe character (|) just to the right of the link. No problem, I thought. As it is a delegate control, it’ll use some custom control from the control templates. I’ll just have to remove the pipe from the control. I went to the control templates and bingo, there was MySiteLink.ascx. Wrong, as it seems, the control uses some code behind file where it programatically adds the pipe.

this.hlMySiteSpacerSuffix.Text =
  "<span style='padding-left:4px;padding-right:3px'>|</span>";

So how can I quickly remove the pipe, without having to rewrite another delegate control to take its place, or a whole new other control to render the special MySite link? The answer is CSS. As it turns out, the pipe is rendered within a span tag. So when adding the delegate control, make sure you encapsulate it within a specific css reference, for example: .removeSpan. In your css, you just have to define the following:

.removeSpan span
{
  display: none
}

Voila, one pipe free MySite link. Sure, it’s still on the page, but the design does not get screwed up by it. Problem solved.

Monday, October 1st, 2007

SharePoint Branding Issues

As promised, I am writing a series of blogposts regarding issues you may encouter when developing a custom branding solution for SharePoint. Customers usually want to customize the out of the box design SharePoint is offering. It often simply does not reflect their company’s branding. SharePoint uses master pages and CSS to provide a consistent look throughout their pages. But when developing a custom design, you will notice it is not that easy to customize the things you want. So how do I tackle this?

I always create a custom master page. Why do you ask? The master pages SharePoint provides do not always provide CSS support on all it tags, and codewise the HTML is not really clean. The number one thing to remember when developing a minimal or custom master page for SharePoint is that SharePoint expects a number of PlaceHolders to be within the master page.  If there’s some content in a placeholder you don’t want to be available on the page, don’t simply remove the place holder. Move the place holder within a hidden ASP panel.
So is that it? Obviously, no. SharePoint makes extensive use of controls within its pages. You can add and remove them at your discretion. Though there are a couple one which are pretty critical to ensure SharePoint running correctly. Namely, You better declare a SPWebPartManager on your page, otherwise WebParts won’t work. Another thing is to include the form tag right after the beginning of the body tag. This to ensure pages can be posted. Some other controls you might want to include, but which aren’t necessary include wssuc:Welcome, PublishingSiteAction:SiteActionMenu and PublishingConsole:Console.

In short:

  • add a form tag (don’t forget the JS wrapper functions)
  • include all place holders
  • add a WebPartManager control

So, now you have your master page. What about the CSS? SharePoint uses the CSSLink control to add references to their CSS files, of which core.css is the most important. The default way to do CSS in SharePoint is to overwrite the SharePoint CSS in custom CSS files. Unfortunately this method can be quite cumbersome, as core.css seems to be a SS rather than a CSS. They don’t really use the cascading part of style sheets. So, you have to overwrite multiple classes before a change comes through, and sometimes it’s impossible to overwrite a style whithout changing another style too.
My preferred way to work is to remove the CSSLink control altogether and use my own stylesheets. I have two. The first one is a CoreLight.css. It encapsulates only the most necessary classes from core.css and the ones who mostly do not have to be customized. Of course, I cleaned up this style sheet. This is a file I reuse with each project and keeps getting better with each project. The other file is the CSS specifically for the current project. It’ll define the styles, colors, layouts, typography the project uses.

In short:

  • do not use CSSLink
  • create a CoreLight, which incorporates the necessary core.css classes (and others)
  • create a specific stylesheet, where you define project related resources.

Mind that this way to work may not be the most recommended with SharePoint guidelines. It just makes my work far more easier. I can redesign a whole site within one work week. It is up to you to use the method you’re more at ease with.

This was my global approach for custom SharePoint branding. Following articles will deal with some specific issues when creating a custom SharePoint branding.