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
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.
I recognize that what I am describing is slightly different than
what is actually going on in Avalon. In CSS, the equivalent
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.
The "official" Microsoft party line according to Chris Anderson (XAML/Avalon "Architect") is that CSS is too slow and clumsy and it's not XML either. I'm not fooled but who am I. Anyway, for more insight check out Chris Anderson's blog online @ [link]
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?
Let's see. There's this new language+API. It is, in theory platform independent. It's pretty high level. Below the high-level description, it runs on top of a virtual machine. It's verbose. Some people say it will never work. Gotta be Swing, right?...
My uninformed guess at why XAML doesn't (appear to) support a CSS-like mechanism for defining style externally is that it is designed to be edited in a form builder. It's significantly harder to have a visual form designer that plays nicely with externally designed stylesheets than it is to do the whole thing by dumping the style with the structure. You can see this in all "wysiwyg" HTML editors - the default editing style (the effect you get by using the toolbars and menus to apply style to blocks of text) is to dump all the presentation either in the markup directly (using b, font, etc.) or in style attributes. Any CSS editing capabilities are off in separate dialogs, and don't interact well with the other formatting options.
I am shocked, SHOCKED, to hear you suggest that Microsoft, a company that makes money selling developer tools, is inventing new standards that are de facto impossible to implement without the newest version of their developer tools.
Sam Ruby also was inspired by Chris Sells' XAML and Dynamic Properties post. Sam laments Chris' use of individual Background attributes on each Border element and proposes a CSS-based alternative. Either ChrisAn or Rob have...