Working on applications built with Silverlight, it is really common you have to deal with styles, templates, and often this means you have to build a theme pervading an entire application. Building a theme is not so simple as you may believe at the first sight. It requires instead a careful planning, from the conceptual side first and in the technical implementation then. There are lot of topics regarding the creation of a theme from the designer point of view but here I want to discuss about the implementation details that are often underestimated.
Styles are a great thing. But if you ever tried to use them without a careful planning you are aware that, more than often, they become a nightmare. We all are conscious about the reasons that move us to adopt styles in an application, but when the time comes we all tent to forget these reasons. And this is the mother of all the mistakes - ok, not only about styles - that usually makes our "stylesheet" more similar to a disordered trashcan instead of an useful thing. You start coding UI, then you understand that some properties have the same values, so you extract them and put it into a style. This may seems good but soon (or perhaps too late) you start to be unable to reuse the same style on more than two or three controls before you need to duplicate it.
Planning for styles is a difficult game, but it may change your life to the better if you know where to start from. And in my humble opinion the real start point - just after the end of the designer's work - is to create a palette. Colors and Brushes are usually the most obvious properties you move to a style, but having your colors spread over a 5 thousand rows stylesheet is almost not useful as if it was spread along all the pages. So, before you start, write down this sentence and put it on top of your monitor: "I will never write a color manually more than once".
#1 - Name your colors
It may seems silly but this rule automatically imply we have to name our colors. Ok guy, please stop writing now. Do not name Red as Red. Instead you have to use a more meaningful naming that adhere to the matter of your application. I usually make large use of adjectives like "Light" and "Dark". The reason to not name Red as Red (this is about to become another sentence to put on your monitor) it that easily, what it is Red now may become Green tomorrow and you for sure do not want to name as Red all your Green :) If a theme make its work fine it allows you to easily change lot of your UI without changing anything in the pages. So, here is a simple example of a named palette:
1: <Color x:Key="ExtraDarkColor">#FF333333</Color>
2: <Color x:Key="DarkColor">#FF666666</Color>
3: <Color x:Key="BasicColor">#FF888888</Color>
4: <Color x:Key="LightColor">#FFdddddd</Color>
5: <Color x:Key="ExtraLightColor">#FFeeeeee</Color>
This is a very simple example but it explains the point effectively. You have to choose your names basing more on where or when they are used instead of the color they represent. It is a good rule of thumb to have a scale of light fore each color you use in your palette. This makes your life easy when you need to present selections, embossed borders (really? please avoid emboss your borders) and so on. This section has to be written at the very start of a ResourceDictionary (in another post I will explain how to organize the dictionaries) and it is the sole point where a color appears in the one I call the "sharped form" (remember the "#" in front of the color? ok you got the sharp).
#2 - Name your brushes
Ok, I'm reading clear on you the doubt. What the hell I can do with a bunch of colors? You all are right, colors are a form that is not ready to be used in your markup. 9 times over 10 a property of an element does not accept an instance of Color but instead it requires a Brush. So, as you did with colors, now you have to name your brushes. Brush names are more close to the real usage, and please keep in mind that nothing prevent you from use the same color in two or more brushes. Here is a set of brushes:
1: <SolidColorBrush x:Key="BackgroundBrush" Color="{StaticResource ExtraLightColor}" />
2: <SolidColorBrush x:Key="HighlightBrush" Color="{StaticResource LightColor}" />
3: <SolidColorBrush x:Key="SelectionBrush" Color="{StaticResource LightColor}" />
4: <SolidColorBrush x:Key="AlertBrush" Color="{StaticResource DarkColor}" />
As you can see, the brushes' name suggests the use you have to do with it. In this example you have Highlights and Selections rendered with the same LightColor and the AlertBrush is a DarkColor. This one is a good example of the naming: you do not need to have the Alert as Red, you only have to use a color that stands over the BackgroundColor. An the naming here helps you to remember the meaning instead of it color.
#3 - Name your gradients
Some applications make use of gradients. As you know gradients are simply a transition between a series of colors. And with your named colors you can for sure create a set of named gradients. Thanks to the Brush concept you can avoid to put gradients in the markup but you can easily put them side by side with the palette and the solid brushes and this way you are able in the future to change a solidcolor to a gradient and a gradient to a solidcolor:
1: <LinearGradientBrush x:Key="SoftBrush" EndPoint="0.5,1" StartPoint="0.5,0">
2: <GradientStop Offset="0.0" Color="{StaticResource ExtraLightColor}" />
3: <GradientStop Offset="1.0" Color="{StaticResource LightColor}" />
4: </LinearGradientBrush>
5:
6: <LinearGradientBrush x:Key="ToolbarBrush" EndPoint="0.5,1" StartPoint="0.5,0">
7: <GradientStop Offset="0.0" Color="{StaticResource DarkColor}" />
8: <GradientStop Offset="1.0" Color="{StaticResource BasicColor}" />
9: </LinearGradientBrush>
In my old applications I was use to call gradients as a named followed by "Gradient" but recently I've understand that it is a bad policy like naming Red as Red. You will understand it the first time you whant to flat your embossed toolbar and you transform a gradient to a solid brush.
#4 - Take advantage of Blend (with care)
Once you have created a palette and a set of brushes you can start using them and Expression Blend is your best friend but you have to pay attention to something.
On the right side you see the color tool of Blend. Instead of it you see a tab named "Color Resources". Please always remember to never use it. This tab exposes the Color instances you named in your palette. At the first sight is may seems a good idea to select colors from here but is means you put a Brush in the markup and this brush wraps the color you have selected.
Just because Colors are not directly supported, Blend expose them to let you edit gradients easily but it wraps them into a brush before to set the property of the element you are editing. You have instead to use the last button on the very top of the window. It is named "Brush Resources" and it shows the brushes you have laboriously defined.
It is all about colors
As I've already said, your palette is the central point of the theme of your application. And planning themes carefully let you change the look & feel easily making its lifetime much more longer. XAML Resources are ten times more powerful than CSS and the content of this post is a good example of this power. As an interesting excercise, please try to reproduce the matter of this post in a CSS and you will understand that it is simply impossible.