Matt (no link) comments on my styling post "Why not use CSS, instead of re-inventing it?"...

Avalon originally started with a very CSS-like styling mechanism. I say "CSS-like" because we tried to implement the syntax and rules of CSS, but not the property set. Because we made the decision to base our object model on .NET conventions, the property set for our styles needed to be the same. We didn't want "font-family" in the style, and "FontFamily" in the programing model and markup. It looked something like:

<Window ...>
    <Window.Style>
        Button { Background="Red"; }
    </Window.Style>
</Window>

We got a lot of feedback from internal customers. First, there was the complaint that this syntax wasn't XML. Secondly, there was the complaint that the CSS mechanism for dealing with namespaces was pretty nasty (using pipes). In CSS today most people don't use namespaces, but because of attached properties in Avalon (DockPanel.Dock for example) we would be using these a lot. Third was the lack of support for complex elements. Consider defining a linear gradient in XAML:

<LinearGradientBrush>
    <LinearGradientBrush.GradientStops>
        <GradientStop Offset="0" Color="Red" />
        <GradientStop Offset=".2" Color="Blue" />
        <GradientStop Offset="1" Color="Transparent" />
    </LinearGradientBrush.GradientStops>
</LinearGradientBrush>

That doesn't quite work in the CSS syntax. We where then faced with creating a syntax that wasn't XML, CSS, or anything else people had used - and didn't actually solve all the problems that we needed.

In addition, the CSS model of "rule based" styles (that is, you have a prescedence of rules applied based upon the specificity of them) was a performance nightmare. We knew that we wanted scoped styles, default styles, and massive element composition (50K elements as a goal). Very recently (earlier this year) we did a rearchitecture and part of that was switching from the CSS-like rule based style engine to the simpler explicit XML based style system.

Our goals for the new model where:

• Better performance
• Easier to tool
• Support for complex object definitions
• Unified syntax (no special parser for style)

In addition, there were several features that we could accomplish with our CSS-like approach - namely the notion of "BasedOn" styles. This is a lot like Microsoft Word's model where you can have one style inherit from another style explicitly. In CSS you can kinda make this happen by having two rules have the same sets of rules, but it isn't intuitive and it isn't really possible to provide a good tool experience.

Unfortunately we didn't fully succeed on the unified parser for style and "regular" XAML. From the developer perspective the syntax is the same, but internally we have to create FrameworkElementFactories isntead of inline elements, because the style can be applied multiple times we must provide a model for cloning the trees of elements that are defined within the style.

Which leads us to the other features - VisualTree and VisualTriggers. In Avalon the Style object (which is a CLR object) has several properties, of which VisualTree and VisualTrigger are the two most interesting for this discussion. While CSS has a huge amount of overlap with the property sets that occur in a style, there isn't a part of CSS that works for defining the visual triggers (property sets to occur when a property value or event occurs) and visual tree (the template for the display of that element). Of course, CSS attribute selectors can accomplish some of the work of visual triggers, but they don't support the event based edge triggers that we are planning in the future.

Our goal with XAML (and Avalon) was to provide a simple unified programming model for UI, Documents, and Media. This includes timelines, animation, video, controls, rich text, etc. We felt a unified approach was the only way to produce a simple understandable object model and markup.

Now, for the big pitch...

This is a developer preview. We want your feedback, we are listening to your feedback. The pushback on XUL, CSS, etc, is being listened to. I can't say that we will implement every suggestion that is given, but the entire purpose of this early preview of our technology is to get feedback from the development community. Tell me how to avoid having two languages - CSS for style and XAML for UI, tell me how to make CSS easier to tool, tell me how to make it perform and scale to tens of thousands of elements with nested style sheets... We are listening.