intertwingly

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?