What is CAML? Officially, it stands for Collaborative Application Markup Language. Essentially, CAML is an xml structured intermediate query syntax for SharePoint to query against data structures (that can also be defined using CAML). Sounds a bit like SQL no? Well guess what CAML gets translated to in the back-end? Yep – SQL. SharePoint takes your CAML and queries against its sql backend. So in short, with CAML you have this massively verbose query syntax that requires nested xml tags, multi-line statements, and quoted attributes.

Enter Linq, with its terse sql-esque statements and amazing chainability. No more CAML!

Not quite.

Linq can only be used against a SPListItemCollection object which must be filled before use. The two most common ways to populate a SPListItemCollection is to either Get all items, or use a SPQuery object and CAML syntax to get a subset of items. As you can see, the dilemia presents itself that if you try to avoid CAML altogether, you will sacrifice performance when querying a list with potentially a large set of items.

So the best solution? Use both. Before using Linq directly to query items, first populate your SPListItemCollection with a CAML query that will do an adequate job of ensuring a manageable subset returned from the database. Then with Linq, fine-tune your SPListItemCollection to further sort and filter your result set. So Caml – Chainsaw, Linq – Carving Knife.

For more information, check out the excellent resource below:

LINQ and SharePoint Development: The benefits and the pitfalls

So how to get rid of them? If you’re using Outlook 2007, take the following steps:

Tools ->Options -> Junk Email…

Click on the last tab, “International”

And now click on “Block Encodings List…”

The following dialog appears…

Select Cyrillic for Russian characters, along with any other character sets you are unfamiliar with.

Click OK, then Apply.

So can’t I just add a height:0; rule to my css? Well that will work – until the control within my div decides to render content and now its hidden.

So the fix? Add an html comment within the div. Yep, sounds crazy – but if your empty div is empty, save for an html comment, it will now not render any height.

Here’s how the fix looks like:

For the default Month and Day view, you can apply the following style:

.ms-calheader img { width: auto; }

This will reset the width for a spacer image that the fine folks at Microsoft have decided to give this enormous amount of width to.

For the Week view, you need an additional style rule (hold your breath for this one):

.ms-cal-wtopday div img, .ms-cal-wtopdayL div img, .ms-cal-wtopdayLover div img, .ms-cal-wtopdayover div img, .ms-cal-wtopdayRTL div img, .ms-cal-wtopdayRTLL div img, .ms-cal-wtopdayRTLover div img, .ms-cal-wtopdayRTLLover div img, .ms-cal-wtopdayfocusover div img, .ms-cal-wtopdayfocusLover div img, .ms-cal-wtopdayfocusRTLover div img, .ms-cal-wtopdayfocusRTLLover div img, .ms-cal-wtopday-todayRTLover div img, .ms-cal-wtopday-todayRTLLover div img, .ms-cal-wtopday-todayRTL div img, .ms-cal-wtopday-todayRTLL div img, .ms-cal-wtopdayfocusRTL div img, .ms-cal-wtopdayfocusRTLL div img, .ms-cal-wtopdayfocusL div img, .ms-cal-wtopdayfocus div img
{
width: 80px;
}

Holy smokes! Good thing were not optimizing stylesheets for web performance right? This is a cumulative width that is specified for each day column. The value for the width you specify here will by multiplied by 7 to make up the overall width for the view.