This final blog post (for now) in the SharePoint Branding Issues series is one regarding web parts and their branding issues. I’m assuming most of you know what web parts are. They are like mini applications within a web page. As they are so small, you’ll often add several of them together on the same web page. In other technologies, such applications are called widgets or gadgets or whatever. But basicly, their ideology is the same. A nice example is featured on live.com.

To get back to .NET, web parts are a new technology within ASP.NET (and unified in version 2). In previous versions of SharePoint, they used some custom made framework. And now in WSS 3.0, they are slowly migrating to the new ASP.NET 2 standard, which allows far more easy web part development. Finally to be complete, a few more statements regarding web parts. Web parts are placed within horizontal or vertical web parts zones. These zones can define the chrome style used for the web parts within. The web part chrome, for those who do not know, is a fancy word for its border decoration. Furthermore, the web parts need one single web part manager, per page, for.. well.. managing purposes. Finally, all of these concepts have a corresponding class within the System.Web.UI.WebControls.WebParts namespace. And basicly this is, in a nutshell, what web part infrastructure is all about.

Now, the thing with SharePoint. They decided to overwrite all of these classes (just as we would for a custom branding job in ASP.NET). But somewhy they made the decision to make the new classes all sealed. So basicly you can not change anything, except, of course, if you rewrite every single class… I know… And as one of my hungarian colleagues would say in such a situation: nice!

The chrome in SharePoint consists of 5 fixed chrome types (Default, None, Title and Border, Title Only and Border Only). These are implemented in an internal SPChromeHelper. What this class does, is adding the following structure as chrome:

<table>
    <tr>
        <td>
            <table>
        </td>
    </tr>
    <tr>
        <td>
            <div>
        </td>
    </tr>
</table>

Depending of the style the first row, which is the header, will be generated or not. Accordingly CSS classes are attached to the rows, the inner div and the inner table. As you can imagine, this kind of structure can be really restrictive. It is very difficult to add gimmicks, like rounded corners, to such a composition.

What can we do then? Well, basicly, applying tricks and hacking our way in. To achieve this, once again, our friend is CSS. By adding some classes to the right place and by using some specific CSS selectors, one can manage to achieve some degree of customization. A possible solution could be to add a specific CSS tag name to the declaration of the zone tag in your page. This way you can reach its inner web parts through the use of CSS selectors. In most cases you can define your own zones, so this can potentially be a solution for the problem. Another, more obvious solution, consists of simply overwriting the fixed chrome type’s CSS styles. The issue here is that every web part has to be set with the correct fixed chrome type to display your customizations. Of course, you still have the same limitations as the previous solution, as the structure of the chrome is still the same. More over, you usually cannot reach all generated HTML tags using only the fixed CSS class names.

While writing this article, I found this post written by Daniel Terborn. Daniel tackled the same problem and supplied another possible solution. He decided to create a base web part which implements all of the layout. Finally, with some CSS hooks, he manages to get really nice web parts. The problem with this solution is that it only applies to custom written web parts. In some situations this can be acceptable (by only using custom web parts), but most of the time you’ll want to use the out-of-the-box web parts too, for obvious reasons.

Conclusion? There is no clean and neat solution for web part branding within the current iteration of SharePoint products. We can only hope the sealed classes will be opened up in future versions. Until then, happy SharePointing.

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.

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?

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.

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.