I learn best when I see examples like this one. I find it gives me insights that one rarely finds in documentation.
From this example, I gather that XAML has a specialized syntax for dealing with two argument static/shared setters, like this one. As I have not seen this design pattern I dig further, and find that Avalon supports Dynamic Properties. Encapsulating such properties with static methods does seem like a reasonable thing to do, and then adapting the syntax of XAML to optimize for this also seems like a reasonable next step. Call it co-evolution at work.
But, as I said, documentation typically is not written this way. Pity.
The next things I see is what I perceive as a deficiency of XAML and/or Avalon. In order to make things more visually appealing, Chris added a border around these cells. This required the addition of an XML element for each cell.
In CSS, this could have been done once:
GridPanel SimpleText { border-color: White; }
I recognize that what I am describing is slightly different than what is actually going on in Avalon. In CSS, the equivalent of UIElement is a Box - complete with margins, borders, and padding. In Avalon, additional objects are required to achieve a similar effect.
That being said, and independent of the syntax for describing such things, is there value in being able to factor out the style from the content? Put another way, are all but the most trivial XAML documents destined to become as opaque as web pages which employ nested tables and spacer gifs?
We all knew that 'separation of content and presentation' thing wouldn't last...
The Microsoft position on XAML as applied to documents (thus supplanting XHTML/CSS) appears to be "You want to do what? No, don't think of this as a web page," but I'm not sure they're fooling anyone.
Given that XAML seems to be designed for building GUIs, you should probably ask yourself why you are overriding the default presentation of the controls at all?
In the case of GUIs, the app author generally provides the "content", while the operating system provides the "style/presentation" (in the form of the user's selected theme/colour scheme) -- contrast this to the web, where the author usually provides content and style.
The "Background" property used in those examples is an override in the same way that the style attribute in HTML is. If you are going to use these sorts of overrides in a GUI intended for general use, you should have a very good reason -- they can screw up the accessibility of a program.
Setting both foreground and background together isn't the answer either, since any combination you can think of is going to be unreadable to some people. The defaults are the only thing you can trust.
If I make a web site and specify in my CSS file that H1 is always 200% (or 2em or 24px or whatever), that applies to my entire site. If I make an application and have a number of similar dialogs and specify that the first line of each of them should be bold and left-justified with a 20px left margin, I would like that to apply to my entire application. Can I do that in XAML? (I'm honestly asking.)
I've conquered the Herculean task of enforcing GUI standards across a large-scale client/server ERP system (~2000 separate entry screens, in Powerbuilder which has no concept of datawindow inheritance or grouping). It wasn't fun. If I had to do that again with XAML, would my life be easier or harder?