Reminders on customising the RichTextField control in Publishing

Right, so, again I’m looking at the problem of consistent formatting of client authored text in SharePoint. (Incredibly, it’s 4 years since I first looked at this).

Anyway, as a note to myself… Continue reading “Reminders on customising the RichTextField control in Publishing”

Reminders on customising the RichTextField control in Publishing

No CssRegistration control in Sandbox

Hmm – and interesting problem; in the Sandbox you don’t have any access to the CssRegistration class. It’s in the Microsoft.SharePoint.WebControls namespace, and you don’t have access to that.

So, what do you do to link to an external stylesheet? Um, well, there isn’t any pretty story. The best I’ve come across is by Ian Chivers, who uses JavaScript to add another <Link> tag into the <Head> of the page.

Clever, but yuck! Continue reading “No CssRegistration control in Sandbox”

No CssRegistration control in Sandbox

Adding CSS links to your SharePoint pages or code…

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 <Link> tag in the head

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

<SharePoint:CssRegistration name="/_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:

<Sharepoint:CssLink runat="server" />

It actually outputs the <link> 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 <head> 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(){

Job done…

Adding CSS links to your SharePoint pages or code…

Style individual web parts

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.

Style individual web parts

Where to put CSS when branding?

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.

Where to put CSS when branding?

Stuff I forgot to style

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…
Stuff I forgot to style

Applying Themes

Themes have a couple of big advantages over Master Pages:

  • Any type of site will let you change the theme.
  • They style the Site Admin pages too.

…but there are some pain points too:

It’s certainly worth considering how your theme will be applied up front – although you could using the Alternate CSS url to ‘apply’ your theme. Personally, I think I like the idea of using a Feature.

Applying Themes

Corrupt Breadcrumbs in the in PageAreaTitleFrame

I was tempted to call this “The incredible case of the bust rendering of SharePoint pages”, but it seemed a bit long, to be honest. This is a bit of a detective story (and if I’d the developer who built this in the first place, there’d be a murder) so stick with me… Continue reading “Corrupt Breadcrumbs in the in PageAreaTitleFrame”

Corrupt Breadcrumbs in the in PageAreaTitleFrame

Style the DatePicker using an Alternate CSS

A while back I posted about the how daft that the datepicker control isn’t styled by themes, and is in the _layouts directory, so you shouldn’t edit them.

Well, a while later Michelle posted with a good idea of how to brand them – use an alternate CSS URL. I must confess, this tip passed me by until my recent branding efforts, and I discovered her tip.

So why does this work? Well, if we crack open the file iframe.aspx (which I still think is a bloody stupid name. I mean, the defining feature is the DatePicker control, not the bloody iframe it uses) we can see the code:

There we go – code to insert the alternate CSS url (but not themes – obviously).

So, I gave this a go:

Tada! Styled date picker, nice one Michelle. However, she notes that it has to be applied to a publishing site, or to a publishing site and all sites below it. Site collections based around a team site would be tricky. Normally, this page is used to set the alternate CSS…

[image of site]

… and, well, Team sites don’t give you that page.

However, we can achieve this in code! All the admin page does is change the SPWeb.AlternateCssUrl property for a site or set of sites. We could have a feature receiver (a bit of code that is run when a feature is activated or deactivated) to do this:

public override void FeatureActivated( SPFeatureReceiverProperties properties ) {

SPWeb site = properties.Feature.Parent as SPWeb;

site.AlternateCssUrl = "[Your URL here]";



More evidence that brands are best applied by feature receivers. Maybe I should make an example of this…

Style the DatePicker using an Alternate CSS