Date Picker controls have variable width

I’m beginning to hate the SharePoint DatePicker control. It displays with different widths:

What defines the width of this control? Damned if I can see – it appears to be the widest element within it. This means either:

  • the length of the date link at the bottom of the control
  • the length of one of the week rows

This is probably less of an issue for Americans (right) than the British (left) – I presume that other Europeans will have the same issue.

Certainly, this will result in some squashed looking calendars on certain months. Yet try as I might, I couldn’t get the calendar to fill an entire area.

And why does the American format give the day and the normal format not?

Date Picker controls have variable width

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

The lunacy of the SharePoint DatePicker control

More branding – I’d rebranded the SharePoint calendar. It looks nice, and not ‘SharePoint Blue’. “Great”, I thought, “I give that a quick check and move on to the next task”. So I gave it a check – and found that while the DatePicker that appears in the left navigation of the page was fine, the DatePicker control which appears for Date & Time fields had not picked up the styles I’d defined.

Arse. Mine was supposed to be red, not blue. So I began to wonder where this control was actually coming from. It wasn’t coming from my page – viewing the source, it wasn’t there, and if it had been I’d’ve expected it to be styled.

I didn’t think it was dynamically produced by JavaScript – I was sure there was an .aspx file behind it. I had a nasty feeling, so I went and checked the _layouts directory, but didn’t see anything that looked related to DatePickers.

Next up I tried the IIS logs – and found it. I was right – the DatePicker was being generated by iframe.aspx – and it was in the _layouts directory. (This makes me wonder – is this the only place where an iframe is used in SharePoint? Would something like datepicker.aspx or even datepickeriframe.aspx not have been a more obvious name?)

Anyway, so it’s in the _layout directory. It’s trivial to change it so that it also uses my stylesheet – but that will change it farm-wide, or configuration changes. I guess I’ll be looking at kb-944105 how to customize application pages in the layouts folder in wss 3 and moss 2007.

Edit: Michelle has an excellent suggestion, and she’s blogged about it here. It’s still a hack, really, but there are worse ones!

The lunacy of the SharePoint DatePicker control