Andy Burns' SharePoint Blog » Branding

Adding CSS links to your SharePoint pages or code…

Andy — Mon, 20 Jul 2009 11:14:29 +0000

I love Twitter – you get some though provoking questions on it. Thomas Resing asked the other day:

How are you applying styles to your custom web parts in #SharePoint? using CSSClass property, stuck on deploying css tag in the head

Well, for pages themselves you have the CSSRegistration control. It’s an ASP.NET control, and looks something like:

"/_layouts/myBrand/SomeStyle.css" runat="server"/>

This control registers the URL with the page, but doesn’t emit anything. That’s controlled by the CssLink control:

"server" />

It actually outputs the elements, and this means that you can have a CSSRegistration control low down in the page (in a Content control, for example) and you can still output it in the of your page. There’s a good post about this on CleverWorkarounds.

So, could we use that control? Well, we should be able to instantiate one – except it turns out that we don’t have to. We can just use the CSSRegistration.Register() static method – something like:

protected override void CreateChildControls(){ CssRegistration.Register("/_layouts/myBrand/SomeStyle.css"); }

Job done…

Rounded Corners on Web Parts

Andy — Tue, 30 Jun 2009 11:40:20 +0000

The Holy Grail of SharePoint branding - at least as far as I’m concerned – is rounded corners on Web Parts. Every design that comes in has this at first. As mentioned yesterday there are examples of doing this for the web part’s title - I’ve done this using Madalina’s instructions and Heather Solomon has some instructions too.

However, as far as I know nobody has yet figured out a way of putting rounded corners on the bottom corners of web parts. The HTML they have does not suit them to do this via CSS. The only idea I’ve had previously was to use ControlAdapters to modify the output of of the Web Part itself. And I’m pretty sure you’d have to write an adapter per web parts. That kind of sucks; no customer is going to be in a hurry to pay for that.

Well, when I was looking at putting borders around an entire web part zone, I had a thought. What we really need to do is insert elements into our page. jQuery can do that sort of thing. Could I use jQuery to find each web part and wrap some tags around it?

Looking in the HTML produced for a page, I noticed that web parts all seem to exist in a table cell with an ID that begins ‘MSOZoneCell_WebPart‘ so I tried querying for that, and wrapping it in DIV tags (the same structure as used yesterday for the whole zone):

Erm, this worked (Image below is just one web part zone):

Clearly, that style sucks. And you’d want to work on the styles of the web parts themselves – removing borders and the like. And I think that having separately styled ‘titles’ and ‘bodies’ might be… awkward. But those are borders around individual web parts. They do show up in Edit mode, and they do move when you drag the web parts around:

Unfortunately, I do seem to be getting a JavaScript Error now. When I open it up to look at it I see:

I’m pretty sure I’ve never written 120 million lines of code, so I’m not quite sure what’s going on here. It doesn’t seem to cause any problems though. I don’t know if somone can take this prototype on and solve that one – but I can’t find the problem. It sounds very similar to this bug report.

Rounded Corners on Web Part Zones

Andy — Mon, 29 Jun 2009 10:50:10 +0000

Curiously, one of my more popular blog posts is about putting rounded corners on things in SharePoint. It does seem that this is a pretty popular question. As a side note, Heather Solomon has a post about doing this for web part titles, though I followed Madalina’s instructions.

Anyway, one design requirement that come up repeatedly is rounded borders on Web Parts. I swear, it comes up with every design – and it isn’t possible (although I have an idea – more on that tomorrow). What you can do, though, is have a rounded border about the entire web part zone…

Of course, the problem with this is that if you put two web parts in one zone you get something like the following:

Actually, that can sometimes work quite well, but it’s something else to consider when you (or your users) are laying out their web parts. Still, it’s pretty easy – here are the image files used for the border (I put them into a folder in LAYOUTS):

I then put a whole bunch of DIV tags into my page for the borders. I don’t like having all of them, but it’s a fairly standard way of doing this (browsers – please support CSS for corner radius soon).

Yuck! Lots of DIVs, but combined with these CSS Styles …

… it puts our border around our web part zone. Obviously, for a real system you’d use a nice looking border – mine is for prototype only.

One issue that remains, though, is what happens if there are no web parts in the web part zone? Well, as it stands you’d have a nice empty box which would shrink to its minimum size, as there are not contents. This isn’t ideal – if it’s empty, we’d rather not see it at all. SharePoint seems to deal with this for square borders using the MSO_Layouts_MakeInvisibleIfEmpty() Javascript function. JavaScript? Pah! Quaint and old school – I used a bit of jQuery:

What this code does is get the innermost DIV tag of every bordered area. If that DIV tag doesn’t have any children, we find the first parent DIV tag at the ‘top’ of my set of nested DIVs, and hide it! And that works nicely:

Next up, I’ll take a look at borders on web parts themselves…

Automatically add themes to the SPThemes.xml file

Andy — Thu, 25 Jun 2009 09:45:15 +0000

I’m not sure I’ll use themes again over the AlternateCssUrl again in a hurry, but I did decide to take a look at the 10 example themes Microsoft Released in March. I’ll blog about how they look – sometime! (The short answer – some good, some bad, some awful!)

Anyway, I was interested that the themes could all be activated as features. This rather kept with my feeling on how branding should be deployed.

However, some of the themes (though not all) were suddenly available in the ‘Site Themes’ page of my SharePoint system. I knew from experience that this isn’t something that ‘just happens’ – previously, I’ve done it by hand.

EDIT: See the comments – they describe an possible pit fall, but both have articles about how to do the same thing…

I became curious, so I opened up Reflector. I found that there is a method called when the feature is installed to update the SPThemes.xml file:

ModificationType is just a private enumeration to tell you whether you are adding or removing an entry from the SPThemes file. This code is called from within a Feature Receiver during FeatureActivated FeatureInstalling (need to check, see comments below)

Anyway, I’ll remember this in case I should need to do similar. Obviously, the original code is probably simpler than the decompiled stuff.

Using jQuery to fix the removal of the Title column of a list

Andy — Tue, 02 Jun 2009 12:20:52 +0000

SharePoint List items all have a Title column (although it’s display name might be changed to something else). This Title column is a string, which is unfortunate as sometimes you really don’t need a string column on a list; this was the need I faced.

You can make a Title column not required:

Also, if you go to the ‘Advanced Settings’ page of your list and ‘Allow management of Content Types’ you can then go into your content types and Hide the Title column. This is okay – but the Title column is still there – it’s just being displayed with “(no title)”…

That’s not such a problem for views on a list – you can simply choose to not show the Title column. But unfortunately, some other pages (such as EditForm.aspx and DispForm.aspx) use the Title column in their title and navigation:

“(no title)” sucks a bit, especially as we probably do have something better to use as a title. I decided to use jQuery to replace the “(no title)”s in the Edit and Display forms:

Or, as text:

Here I’m getting the new title from my user field – but you might want to use another field. Whatever, the same principle of using jQuery to get the value would work.

Then I update the Browser’s title bar with the new title.

Next, I select the page title and replace “(no title)” with my new title, before writing the html back, and finally I repeat this with the “(no title)” link in the breadcrumb. The end result is:

Nice. I repeated this for my Dispform.aspx too, though not the new Item form – it doesn’t display the title at all (as a new item doesn’t have one yet!) I also added an edit button to my list so that users can still edit these items:

(And yes, there are other ways of dealing with this – building proper custom edit and display forms, for example – but this is quite low effort)

Putting actions into the PlaceHolderLeftActions

Andy — Fri, 17 Apr 2009 14:00:53 +0000

The Wiki and Blog sites have pages that make use of the PlaceHolderLeftActions content placeholder. I’ve mentioned this before regarding putting a web part zone below the quick launch menu. This time I wanted to list some actions for our ‘case’ system.

The code to do this? Not very hard. Naturally, we’ll actually have some code to generate our actions and links…





Case Actions








Action 1







Action 2

What do out-of-box pages do with their Breadcrumbs?

Andy — Wed, 01 Apr 2009 16:52:27 +0000

As I’ve described before (and repeatedly bemoaned!) some page layouts hide the page level breadcrumb and display their own. Worse – they don’t all do this in the same way! All of this continues to feed my idea that you shouldn’t use any of the OOB publishing sites if you can help it.

However, sometimes we don’t have that luxury (i.e. I’ve never had that option) – so what do those crazy out-of-the-box page layouts do with their breadcrumbs? Well, Martijn Molegraaf has been kind enough to provide a chart. Nice one. And I feel your pain.

Out-of-Box Publishing Page layouts suck too

Andy — Tue, 31 Mar 2009 19:00:35 +0000

So, might not be news, but SharePoint’s out of box Page Layouts suck. I’ve already described how the page layouts have an image on branding, introducing styles to change the navigation, etc.. This has led me to the conclusion that you shouldn’t use the out-of-box publishing sites – start from a minimal publishing site, and build from the ground up.

But what of customers who have naively thought that, I don’t know, a Collaboration Site Template might be a good template to use for the collaboration site? Well, this is the problem I’ve got now; a customer has used the out-of-box page layouts extensively, and now wants the styles of the text and so on to be consistent. How can I do that? Well, that’s where things get tricky. For Page Editor controls in some page layouts they are within a

tag using the PageContent style. This is true for the Article Page page layouts, and some of the Welcome Page layouts:

Yup, that grey text in Tahoma font is actually defined by the CSS class of the enclosing

tag. But here’s the problem. Some of the other page layouts don’t have the

tag and PageContent CSS style. There is little we can do about all of them, other than adding the

tag onto the remaining Page Layouts; we could try changing styles further up the structure of the page, but that could change a lot more too – and my customer isn’t ready to embark on a full rebranding.

To make matters worse, they have some custom page layouts which use the Telerik RadEditor control. Now, this is fine in Display Mode, but in Edit Mode the RadEditor puts the text to be edited into an IFRAME – which is now out of the styling scope of the enclosing

tag! Display view – grey Tahoma text. Edit view – black Times New Roman!

So, how did I deal with that? Well, in the CSS file that defines the styles for the RadEditor (I’d created one and configured the RadEditor to use it) I defined a tag with a style that matched the style of the surround

tag. It’s a bit of a hack, but at least it did make the text appear the same in Edit and Display modes.

Why so much harder than it should be, though? Couldn’t the page layouts have been consistent? What’s with all the rubbish page layouts anyway? Only the Article Page layouts make sense!

SharePoint Designer – grrr….

Andy — Fri, 20 Mar 2009 17:18:18 +0000

SharePoint designer is so like a wife – I love it to bits, sometimes I hate it, and I fervently hope for a cuter version in the future! No, I’m kidding.

But SPD currently has this persistence in adding a in front of my page’s title field. I don’t need that non-breaking space. I don’t want that non-breaking space. But I keep deleting it, and Designer keeps adding it back in.

For me, it’s a sign one of the two big problems with SharePoint Designer – robustness. When I’m in Visual Studio, I’m comfortable; it’s pretty reliable, normally, and behaves in ways I understand. Even the things that can blow it up are pretty well understood. Much as I hate to admit it, I do think that the reason that C# won out over Java was simpler, robust tooling – Visual Studio.

However, with SharePoint designer all sorts of weird stuff happens…

These bloody character that keep appearing
Spurious and apparently random errors from the Dataview web part – sometimes…
The ‘Select Data Source’ dialog rendering sometimes failing
The fact that I have to try twice to get into the _catalogs folder when I open a site – though in fairness, that could just be SharePoint…
Inserting Web parts is sometimes available – and sometimes not. And Lord help you if you want to insert one into the code view.
Randomly losing connectivity to Servers that I know are available.
Falling over all the time.

SharePoint 14 is, I hope, going to be an ‘evolutionary’ step – or put another way, a few extra features hiding the world’s largest service pack! I do hope that the plan is to do the same with Designer. It feels very powerful, but very… version 1.

The other problem with designer, as I see it, is complexity. It’s pretty much as complex as Visual Studio – but it’s supposed to be the lightweight ‘business user’ tool. I mean yes, what that business user is up to can be pretty complex too. But would a lightweight ‘workflow designer’ not be good as another tool? How about making the ‘New Page’ dialogs a bit more… SharePoint? I mean, creating Standard ASP.Master pages – but for SharePoint? It is SharePoint Designer, right? CSS page layouts? Very cool, shame the team building designer didn’t meet the team who built SharePoint’s pages – ‘cos they’re not the most useful in SharePoint. Web components – FrontPage Extensions relic. This list goes on.

Now, I realise that SharePoint Designer won’t ever be as simple as, say, NotePad (thankfully it’s a bit more feature rich). But what would be good for the next version is that, if this is to be SharePoint Designer, could someone please strip out all of the stuff that isn’t about SharePoint? FTP settings! And rethink the dialogs? And make the Accessibility checker work (I think if that worked it would be fantastic!)

Oh well, I live in hope. A bit of a rant, I know, and I both see the point of Designer, and think it has great potential – but I reckon it’s still showing it’s Frontpage heritage

Deploy Publishing Pages and Content Types as a feature

Andy — Fri, 13 Mar 2009 12:58:40 +0000

Aka “CAML is the bastard spawn of Satan”.

So, I’m writing a site definition to create a Publishing site. This is a bit of a first for me. One of the things I want to do is deploy a new Publishing Page Content type, and associate some layouts with it.

I started by following Andrew Connell’s instructions for a Minimal Site Definition (as in his book). This all seemed to go pretty well; testing created a new, minimal site.

Next up I wanted to deploy the Content Type and associated page layouts. Well, there wasn’t much information in his book on this – like him, I’d figured I’d write a separate Feature for deploying just the content type and page layouts – but there was very little information in his book about this.

My first efforts were pretty unsuccessful. I used his STSADM commands to pull the content type I wanted to use out of SharePoint as CAML, and wrote the feature to deploy that content type and my page layout files. However, when I activated the feature, if I went to the ‘Create New Page’ page or the ‘Site Content Types’ page my CPU usage went to 100% and sat there. Looked like it was an infinite loop.

“Hmm. Something wrong with the Content Type” I thought – but could I see what was wrong? My first thought was that it was the presence of the fields defined by the parent Page content type, but fixing that still resulted in nothing. Eventually, after a couple of hours of experimentation and trawling of the web, I found this explanation.

the XML generated does not contain the XML Namespace: Also note that this tool doesn’t create XML that is 100% correct for use in a Feature.

Thanks Daniel Pollard, good to know. Added my NamespaceURL as shown below, and my content type deployed correctly, without high CPU usage.

http://schemas.microsoft.com/sharepoint/"> http://schemas.microsoft.com/sharepoint/v3/contenttype/forms"> http://schemas.microsoft.com/sharepoint/v3/contenttype/forms"> DocumentLibraryForm DocumentLibraryForm DocumentLibraryForm

Of course, it then occurred to me that I probably didn’t need the XMLDocuments section. So I deleted it:

http://schemas.microsoft.com/sharepoint/">

Reams of CAML cut down to a few lines. Next time, I’m just writing all this by hand.

Anyway, the content type was going in alright, but my page layouts were not attached to it. I couldn’t find any documentation about that either in MSDN. Then I found a useful article by Josh Carlisle trying to so what I was doing - deploy a content type and a page layout. Ah-ha! PublishingAssociatedContentType looks promising. Indeed Chris O’Brien has a good description of the fields of this too.

That seems to work nicely – it deploys the page layout, gives it a friendly name and preview image, and hooks it up to the content type. Note: the Content Type property is not the SharePoint Content type, but some text saying that this file is a page layout. See the resources for CMSCore to see the exact text.

So, what did I make of this experience? Well, lot’s of CAML – which is virtually some obscure dead language spoken by a strange tribe lost in the artic wilderness. I actually think it might’ve been easier to write C# code to do all this set up. Anyway, it does appear that blogs are better than Microsoft’s documentation.

What’s wrong with SharePoint Branding?

Andy — Sat, 07 Mar 2009 11:20:49 +0000

Joel Oleson asks an interesting question:

Why don’t we have a community around our masterpages and themes?

It’s a good question. I can download a million and one Wordpress themes, but very few SharePoint ones. Why? Well, I like to answer a question with another question, so here’s a few:

What’s the market? Who want’s ‘em? Well, amongst our customers, corporates mainly. These are the chaps who have expensively developed corporate brands. Off-the-shelf brands and themes aren’t going to meet their expectations.
Are there small organisations? How many small/non-corportate SharePoint systems are there? The reason so many Wordpress themes get written is that there are a lot of WordPress bloggers out there, and lots of hobbyists. How many SharePoint ones are there? Yes, WSS3 is inexpensive – but to work with it, you’re raising the bar on technical expertise requirements. Most blogging plaforms – simple. SharePoint – colossal. And SharePoint Designer costs money – most of the other’s need NotePad, or have a built in editor. Once you’ve started to get into spending money like that, either companies go with the out of the box branding (“we just want the functionality”) or pay (“it must be our brand”).
Why is it so freakin’ complex? Core .css is 81Kb and 4350 lines long. That’s before you start looking at the other CSS files that you typically need to change – like Controls.css, Calendar.css, Portal.css, DatePicker.css, the HTML editor ones, the menus … ! My styles directory holds 220Kb’s of CSS! Compare that to a WordPress blog. I get why designers and hobbyists build WordPress themes – but what sort of masochist is going to write a SharePoint one for fun?
Which Master Page? The Default Master? What about the Meeting Workspace Master? And, not wanting to scare anyone, but Application.master and Simple.master, which you can’t change (but can redirect – with code). And your users will see pages that use the Application.master – document upload, recycle bin, viewing all site contents. So a ‘new master page’ is not just one, it’s many, and it takes technical cleverness to replace some of the master pages involved. Most designers are into technical cleverness – nor should they be, it ain’t there job.
Themes? Themes are good, but limited – there’s no out-of-box way to apply them to a hierarchy of sites, and they can’t make major structural changes to pages. Sure, they can be used sometimes, but again, takes technical expertise. And they don’t style the Date Picker; for some obscure reason, it’s not coded to support themes.

So, I guess in summary, it’s too complex for the typical design crowd, and way beyond the general Web Dev hobbyist community. Most of the designers who can do this sort of work are already doing so – for large companies who pay to have their brand, and don’t want an off the shelf one. I mean, I reckon I can rebrand a SharePoint site pretty completely – though I’ve never tried My Sites (another complexity!), and by the time I’ve done the images, the styles, changes to the master pages, tested it all, wrapped in a feature, you’re looking at, well, days, probably more than a man week, for someone who knows what they’re doing, isn’t aiming for accessibility, and is clear about their objective.

All in all, it’s harder than it oughta be.

Style individual web parts

Andy — Wed, 25 Feb 2009 11:33:15 +0000

Like Heather Solomon, I’m sometimes asked about styling individual web parts differently to the rest. I didn’t know of any way of doing this; instead, we’d typically style particular web part zones differently, but this meant that all web parts in that area looked differently.

Well, Heather has now posted ‘Controling single web parts with CSS‘. Neat. I didn’t know you could do that attribute selection.

The downer about this technique is that you have to set a DOCTYPE – and I can see that causing all sorts of grief as stuff breaks… …so it’s probably not something you’d do unless you’re building reasonably custom master page.

Feature Stapling for Branding

Andy — Thu, 12 Feb 2009 13:59:00 +0000

As I’ve mentioned before, I reckon that from now on I’ll do all SharePoint branding through features alone – not using themes or the ‘choose master page’ page. Which is fine, and useful too – one of the questions that has been raised recently is how to automatically apply the branding when a new site is provided. Well, feature stapling is the way to do that.

For those who don’t know, feature stapling is creating a feature which associates another feature with a Site Definition. When a site is provided by that site template the associated feature is activated. So, for example, we might have a BrandingFeature feature, which does all of our setting alternate CSS, setting master pages, etc., and then use a BrandingStapler feature to associate that with some (or all) of our site definitions.

I won’t bother repeating the ‘how to’ of it, as there are plenty of good posts about it.

Build page layouts without Breadcrumbs or a Title

Andy — Thu, 22 Jan 2009 17:19:22 +0000

Right, so SharePoint uses pages and page layouts – I won’t talk about the different types, but ask a couple of questions that’ve come up a few times.

If I create a new page layout in SharePoint, how do I get rid of the breadcrumbs?
How can I get breadcrumbs, but like the home page?

Here’s how…

Some page layouts don’t have space above the main content for a title, or for breadcrumbs.

By contrast, a lot of other pages do:

So what happens when we create a new page layout in SharePoint Designer? Well, they have breadcrumbs, and room for a title:

So, how do I fix that? Well, go back to SharePoint Designer (you just created the page layout with it, right?) Let’s look at the code:

Right, pretty straight forward – some content controls overriding the master page’s content placeholders. I’m assuming that you’re familiar with Master Pages in ASP.NET. Now, we can get rid of the breadcrumbs, title and the page image (which is sometimes shown on the left) by overriding those content controls. Paste this code into your page:

What we’re doing there is setting those to empty content (or, for the Page image, an invisible 1 pixel image. No, I don’t know why, but that seems to be how SharePoint always does it)

Fine, what does this give?

No breadcrumbs or title, but still a big gap. How do we get rid of that? Well, we can use CSS to shrink the gap. This CSS is inserted into the PlaceHolderAdditionalPageHead

This CSS gets inserted in the header, and it’s just setting the height of that region to 10 pixels or so. Now we get:

Hmm. Nearly there – but the border isn’t right. There should be a 1pixel blue border at the top and left of the main content area. How does SharePoint normally do that?

Well, it cheats. The blue border comes from a table that is put into the main content area, and is set to fill the content area. For an example, put this code into your main content area:

Test Content

It shows:

Now you can change this table to show the content you want!

What if I want the breadcrumb in the main content area? Sort of like the home page to a collaboration site? Or even a team site?

Well, there are a couple of more steps. First off, replace the text you just put into your main content area with this:

Test Content

This will show:

Nearly, but not quite. The breadcrumb is there, and styled right, but it is padded in from the edge of the page.

To get rid of the padding, we have to insert CSS content into another content placeholder. Add this to your page:

And this produces:

A completed page, with the breadcrumb in the main content area, and no title breadcrumb or title. Sure, I’ll have to build some padding into the table in my main content area, but this is simple HTML, and I’ll leave for the reader to figure out.

Another day, another master page

Andy — Thu, 13 Nov 2008 12:00:53 +0000

Well, I’ve just built a lovely little HTTP Module that lets us redirect the application pages for a site or site collection to a new master page. I’m quite pleased, to be honest. Anyway, I noticed that the error pages in the site I was testing on were not using my new master page, so I started to examine this. I found that the error page (_layouts/error.aspx) is busy using simple.master. WTF?

It makes sense, I guess. You do need a master page which doesn’t run in an authenticated context, and a brief check shows that this is the master pages for the out-of-box Forms authentication page.

I decided to check out if there were other master pages in Layouts – and there were. My list of master pages is now:

Default.master – used in normal sites. Often replaced for publishing sites.
MwsDefault.master – use in Meeting Workspaces. Awkward to replace, but can be done through code or SharePoint designer.
Application.master – used in ‘administration’ pages, and sometimes pages such as ‘View all site contents’, Recycle bin, and uploading a file.
Simple.master – used in pages that need to run in an unauthenticated context – such as error pages, or forms authentication pages.
sspadmin.master – seems to be used editing audiences, in excel services configuration, in profile administration, and handful of other places.
layouts.master – no idea what this is for. Can’t find where it is used!
dialog.master – used in the little pop-up dialogs, such as when you’re adding or editing a Hyperlink.
pickerdialog.master – used in pop-up dialogs such as the web part gallery, or selecting users.

The master pages in italics are comparatively easy to replace; the rest are much more difficult. And try as I might, I couldn’t change the master page for Errors in my HTTP Module. I guess what I’ll do is write another one to redirect errors to my own custom-branded error page.

Where to put CSS when branding?

Andy — Mon, 10 Nov 2008 12:00:07 +0000

I’ve recently come to the conclusion that I’m unlikely to use Themes in SharePoint again in a hurry. Why?

Themes allow you to provide a bunch of CSS styles. So does the AlternateCssURL.
Themes have to be applied site-by-site (unless you do some programming, or extend STSADM). Alternate CSS or Master Pages can be changed for a site and subsites, for a Publishing site anyway (although with some limitations).
Alternate CSS can be provisioned from a single URL – so benefiting from browser caching just like images.
The Alternate CSS can style the DatePicker. Themes can’t.
The Alternate CSS can style Application Pages, just like Themes (but unlike Master Pages).
No problems with ‘Style Merging’ when the Theme is provisioned.
Style can be updated in one location.
Themes can be changed through the UI for any site. Only Publishing sites have a user interface for changing the Alternate CSS.

Yes, many of the same distinctions between Master Pages and Themes still exist, and the same sort of analysis and choice of approach should be done. However, it means that we can kind of ignore Master Pages, and just focus on Alternate CSS vs Themes – and it seems to me that apart from the last point above, the Alternate CSS approach seems to equal or better than Themes.

Regarding the last point, well, to apply my theme I’d set the Alternate CSS in a Feature Receiver. This is okay, though, as I’d probably be writing one anyway to apply the correct master page to different types of site.

So, the answer I’ve come to now – I’d use the _layouts directory – create a sub-directory for your brand, and put your CSS and images in there.

What is MSOLayouts_MakeInvisibleIfEmpty()

Andy — Fri, 07 Nov 2008 09:21:31 +0000

I was looking through the code of SharePoint’s Blank Web Part page layout, and I kept finding elements called _invisibleIfEmpty. Now, I’d noticed that some page layouts, such as the Splash page layout had borders on their web part zones which were only shown if the zone contained a web part. I was interested in how this might work. People keep asking for web parts with borders, preferrably ones with rounded corners.

The code on the page looked like:

…and there were a lot of table cells looking like that, and with that id. Lower in the page I then noticed:

Hmm. So if this function exists, it’s run. For it’s name, it sounds related. After some digging, I found it in defined in:

IE50UP.js
IE55UP.js
NON_IE.js

Interesting… IE5 is, well, pretty ancient now, so I’m guessing that this stuff is a bit, well, WSS2 legacy. What does the code do? Well, looking in one of those files:

Yup, so it makes table cells called _invisibleIfEmpty not display if they have no child nodes. That’s a little strange though – table cells do collapse anyway if there are no contents, and doing this in Javascript just seems a bit old school.

I went and looked inside the Splash page layout and found that that is exactly how it works – the table cell’s borders don’t appear if the cell is empty:

However, the table cells do still appear to take up space – ‘cos each table cell has a width set:

If we took that width=”50%” away, though, the cells would just collapse as normal for empty table cells in HTML.

Still, the who thing did make me wonder – could I do my ’round cornered borders on web part zones’ with Javascript?

My Sites links HoverCellActive doesn’t show the top border

Andy — Thu, 06 Nov 2008 15:52:19 +0000

This has caught me out three times now – I build style, but the top border for the global links ‘My Links’ link didn’t show:

I checked my style, and there it was. So I tried adding a margin, or padding in the cell that contained it.

Wrong. It needs it’s height to be set to 100%.

.ms-globalbreadcrumb .ms-HoverCellActive, .ms-globalbreadcrumb .ms-HoverCellInctive, .ms-globalbreadcrumb .ms-HoverCellActiveDark{ height:100%; padding-top:1px; }

Stuff I forgot to style

Andy — Tue, 04 Nov 2008 12:00:31 +0000

SharePoint has a lot of page elements, and it’s hard to brand it all without missing things. Lists of Page elements like Heather Solomon’s CSS Reference Chart and her “Oh crap, I missed that” list help, but I still found a few that weren’t mentioned. So, I guess this is my “Thank God my testing found I’d missed that” list:

	Advanced Search Page – nice grey.
	Creation Information Panel – when you hover over an item on the ‘Create’ page, you’ll see this.
	People Search Options – shown dynamically when you click the link.
	Gantt views - as used in projects
	Repeating Meeting Left Nav
	WSS Search results page – just ‘cos you’re using it doesn’t mean it isn’t there – or that it won’t be seen…
	The Date Picker – and all the problems inherent in that…

What happens when a Theme is applied?

Andy — Mon, 03 Nov 2008 13:40:58 +0000

You can apply themes to sites in SharePoint – but what actually happens when you do? Firstly, as a quick reminder, on the Site Administration pages, you can go to see the installed themes:

And select one:

Your site will then have a different theme. Great! But how does this work? Well, lets open our site in SharePoint Designer:

That’s right, a folder _themes, containing the theme we just applied in a folder. That theme is the CSS and all the images. Because of SharePoint’s virtual file system, that isn’t as inefficient as it sounds, but ‘cos our theme is being provided from our site, each CSS file and each image will be at a different URL for every site. This might be fine if you wanted to be able to customize the theme on a per-site basis (and you can!) – but it eliminates some of the advantage browser caching, and I don’t think most organisations will want their theme customised on any sites – branding should be consistent.

The observant of you will notice multiple CSS files in the Theme folder (‘Plastic’ above). How does that work?

Well, if you look in 12/TEMPLATES/THEMES, the themes themeselves don’t have the CSS file that you’ll find referenced in your Site’s pages. Instead, when you apply the theme, SharePoint takes all of the CSS files and appends them together into one file which it uses (Plas1011-650001.css, in yellow above).

I only actually found this as most instructions on creating a new theme start by telling you to copy an existing one. This is fine, but I forgot that there were more CSS files than just my Theme.css. Specifically, the mossExtension.css file was being added after the end of my themes, and it was overriding some of the styles I’d defined. As the order of the themes being defined is very important, I do think this ‘adding together’ of CSS files is somewhat dangerous.

Anyway, once a single CSS file has been created, the master page will insert a URL to that file into the page section, and that’s how your styles apply.