Spec: Upgraded Styling System Proposal

[robloo]

Upgraded Styling System

The styling system in Avalonia is extremely powerful in several areas over what was offered in WPF/UWP. A lot of this power comes from Selectors that allow drilling down deep into controls and classes coming from CSS.

The styling system still has a number of shortcoming though. These have been mentioned and discussed all over the place:

• Styles leak, there is no way to restrict at a control-level what style should apply.
• Replacement styles do not fully override base styles and both will end up being set in order.
• There is no support to easily base another style off from another style.
• Selector and style performance leaves some areas of improvement.

In this spec I make an attempt to solve these issues in a backwards-compatible way. Here is a list of the other open discussions:

• Default Control Themes #1883
• WPF-style styles #2765
• Control themes #2769
• Control themes #7120
• Performance issues caused by the styling system #5027

Proposal

Encapsulating Styles in a single Class

I think Styles themselves need to be re-worked and containerized -- within a hierarchy if necessary. Right now styles are just fragments and there are fragments with selectors for everything. All those fragments are handled separately.

In WPF a style was nicely containerized and all the 'sub-styles' for pointer-over, enabled, etc. were triggers and handled from within the style itself quite nicely. Even in UWP which moves to named states similar to psudoclasses, all the states are handled within the same style as visual states. In effect this means a style would have a single type it applies to that also restricts all the 'sub-styles' from ever being evaluated for other situations.

Switching to a more containerized style system like WPF/UWP would be cleaner in my opinion and match closer to the framework designs: object-oriented visual trees shouldn't have a lot of style fragments. Of course we still need to support the amazing power of selectors to drill down into templates and do things impossible in WPF/UWP.

To start, there needs to be some way of encapsulating a style into a single data structure or container. This was first proposed as ControlTheme (#7120) and also as a StyleContainer (#5027 (comment)) or StyleGroup -- referred to as StyleGroup going forward. Each of these StyleGroup concepts would essentially encapsulate the various existing styles and then requires a type to be specified.

Benefits of doing this include:

1. Styles are nicely encapsulated/containerized in a single class. This logically makes more sense for everyone faimilar with existing XAML frameworks.
2. Ensuring all styles for a control are all in the same class means it's much easier to switch that style out.
3. There should be performance benefits as evaluation of selectors would be much quicker. Children are only evaluated if the parent group matches. Setters are ignored entirely for all the secondary state styles (pressed, etc.) except for the precise controls that need them.

StyleGroup XAML Example 1

<StyleGroup Selector="Button">
  <Style Selector="Button">
    <Setter Property="Background" Value="{DynamicResource ButtonBackground}" />
    <Setter Property="Foreground" Value="{DynamicResource ButtonForeground}" />
    <Setter Property="Template">
      <ControlTemplate>
        <ContentPresenter x:Name="PART_ContentPresenter"
                          Background="{TemplateBinding Background}"
                          BorderBrush="{TemplateBinding BorderBrush}"
                          BorderThickness="{TemplateBinding BorderThickness}"
                          CornerRadius="{TemplateBinding CornerRadius}"
                          Content="{TemplateBinding Content}"
                          ContentTemplate="{TemplateBinding ContentTemplate}"
                          Padding="{TemplateBinding Padding}"
                          RecognizesAccessKey="True"
                          HorizontalContentAlignment="{TemplateBinding HorizontalContentAlignment}"
                          VerticalContentAlignment="{TemplateBinding VerticalContentAlignment}" />
      </ControlTemplate>
    </Setter>
  </Style>

  <!-- PointerOverState -->  
  <Style Selector="Button:pointerover /template/ ContentPresenter#PART_ContentPresenter">
    <Setter Property="Background" Value="{DynamicResource ButtonBackgroundPointerOver}" />
    <Setter Property="BorderBrush" Value="{DynamicResource ButtonBorderBrushPointerOver}" />
    <Setter Property="TextBlock.Foreground" Value="{DynamicResource ButtonForegroundPointerOver}" />
  </Style>
  
  <Style Selector="Button:pressed  /template/ ContentPresenter#PART_ContentPresenter">
    <Setter Property="Background" Value="{DynamicResource ButtonBackgroundPressed}" />
    <Setter Property="BorderBrush" Value="{DynamicResource ButtonBorderBrushPressed}" />
    <Setter Property="TextBlock.Foreground" Value="{DynamicResource ButtonForegroundPressed}" />
  </Style>

</StyleGroup>

StyleGroup XAML Example 2

        <ControlTheme BasedOn="{x:StaticResource SomeBaseButtonTheme}">
             <Setter Property="Background" "Value"="Red"/>
             <Style Selector=":pointerover">
               <Setter Property="Background" "Value"="Green"/>
             </Style>
        </ControlTheme>

All of this said, there is another way that doesn't introduce a new StyleGroup class: simply support directly nested styles. It would allow styles to be containerized like a style group. However, a StyleGroup would only support a single parent-child relationship and not a full hierarchy. Nesting the styles supports a full hierarchy of multiple parent-child relationships.

Purely nested styles seems to be the perfect solution to all of this and I don’t think there should be a separate StyleContainer, StyleGroup or ControlTheme at all. Everything should be within Style just like it is in WPF/UWP. Style will get a Children or Styles property to hold the collection of ‘sub-styles’ for each control. This has enormous benefits:

1. Fully backwards compatible with existing styles in XAML or otherwise. It wouldn’t break apps and require rewriting exiting themes. Everything can be upgraded gradually.
2. Implementation in Avalonia should be quite simple as there are no new classes – except perhaps a new StyleCollection.
3. Naming isn’t ambiguous – Style remains the container as in WPF/UWP. We aren't introducing new classes to confuse people.
4. Nested Styles in a hierarchy provide significant benefits as discussed in several places
   1. Only need to evaluate child selectors if the parent matches – a performance benefit for default control styles/templates and the various states (pressed, etc.).
   2. Logically it will make more sense to control authors especially those coming from WPF/UWP as default styles can be fully self-contained. Everything is cleaner with all the various state styles under the same parent style.
   3. This opens the door up for some very-interesting and powerful future areas of expansion. Having a hierarchy in the style itself should allow sharing even more setters for various states where it makes sense. It could be possible to have a depth of 2 or 3 common in future default styles where the states logically branch apart. Instead of having separate styles for "pointer over", "pointer over pressed", for example, "pointer over pressed" would be a child of "pointer over" and "pointer over" a child of the base style. As far as I’m aware this hasn’t been considered before in any XAML styling system and it interests me quite a bit. The possibilities here are exciting to think about!

Nexted Styles XAML Example

<Style Selector="Button">
    <Setter Property="Background" Value="{DynamicResource ButtonBackground}" />
    <Setter Property="Foreground" Value="{DynamicResource ButtonForeground}" />
    <Setter Property="Template">
      <ControlTemplate>
        <ContentPresenter x:Name="PART_ContentPresenter"
                          Background="{TemplateBinding Background}"
                          BorderBrush="{TemplateBinding BorderBrush}"
                          BorderThickness="{TemplateBinding BorderThickness}"
                          CornerRadius="{TemplateBinding CornerRadius}"
                          Content="{TemplateBinding Content}"
                          ContentTemplate="{TemplateBinding ContentTemplate}"
                          Padding="{TemplateBinding Padding}"
                          RecognizesAccessKey="True"
                          HorizontalContentAlignment="{TemplateBinding HorizontalContentAlignment}"
                          VerticalContentAlignment="{TemplateBinding VerticalContentAlignment}" />
      </ControlTemplate>
    </Setter>

  <!-- PointerOverState -->  
  <Style Selector="Button:pointerover /template/ ContentPresenter#PART_ContentPresenter">
    <Setter Property="Background" Value="{DynamicResource ButtonBackgroundPointerOver}" />
    <Setter Property="BorderBrush" Value="{DynamicResource ButtonBorderBrushPointerOver}" />
    <Setter Property="TextBlock.Foreground" Value="{DynamicResource ButtonForegroundPointerOver}" />
  </Style>
  
  <Style Selector="Button:pressed  /template/ ContentPresenter#PART_ContentPresenter">
    <Setter Property="Background" Value="{DynamicResource ButtonBackgroundPressed}" />
    <Setter Property="BorderBrush" Value="{DynamicResource ButtonBorderBrushPressed}" />
    <Setter Property="TextBlock.Foreground" Value="{DynamicResource ButtonForegroundPressed}" />
  </Style>
</Style>

Key Support in Styles

With styles grouped together there still needs to be a way to reference the style as a group. Fundamentally, selectors allow styles to specify a control (style -> control); however, that is only part of a style's usage in other XAML frameworks. Styles actually need to be referenced:

1. Style -> Control : Accomplished using existing Selectors
2. Control -> Style : Needs a Style Key property
3. Style -> Style : Needs a Style Key property.

This means the styling system must be extended to support keys directly as a property of the root/parent Style. This allows controls to directly specify which style they would like, overriding any selectors (the type still needs to match) <Button Style="MyAwesomeButtonStyle"/>

As a side-effect of adding keys, all themes such as fluent will need to specify keys for all the default styles. This is the same as is done in upstream WinUI. Key="DefaultButtonStyle", Key="DefaultTextBlockStyle", etc.

Summary

Most of these ideas are not entirely new. It can be summarized in the below table:

UWP	Avalonia
Style	Style (with nesting)
TargetType	Selector (with restrictions)
Key	Key
BasedOn	BasedOn
-	Replaces

• Style : The group of setters and child styles that apply for a single control. There are default styles in the framework.
• TargetType/Selector : The selector would be treated as a much more powerful TargetType property from UWP. This means it is primarily restricted in the case of parent StyleGroup to support only specifying the target type. However, multiple types can be specified.
• Key : A selector allows a style to specify controls, a key allows controls to specify styles. A key can also allow styles to specify other styles for BasedOn and a potential new Replaces property.
• BasedOn : Allows a style to derive from a base style by key. Same as WPF/UWP.
• Replaces : A brand new property that allows a style to completely replace another where otherwise the selectors would apply both styles.

Finally, a brand-new style for Button in an app may look as below and be used with <Button Style="MyAwesomeButtonStyle"/>

<Style Selector="Button" Key="MyAwesomeButtonStyle" BasedOn="DefaultButtonStyle">
   <Setter Property="CornerRadius" Value="8" />
   <Style Selector="Button:pointerover /template/ ContentPresenter#PART_ContentPresenter">
     <Setter Property="Background" Value="Red" />
     <Setter Property="BorderBrush" Value="DarkRed" />
     <Setter Property="TextBlock.Foreground" Value="White" />
  </Style>
</Style>

[grokys]

Thanks for the proposal - it doesn't actually seem to be that different from #7120 (though that proposal is very barebones) from my understanding.

The main things I don't see addressed here are:

• How would the the "default" theme be chosen when a user adds a simple <Button> to a Window?
• How would a "generic theme" for a 3rd-party control be located?

[robloo]

This is why allowing default styles to exist in something like a resource dictionary registered at the app level always made sense to me.

New third party styles could also use the 'Replaces' and 'BasedOn' properties to totally overwrite the default loaded styles.

I really don't have experience in this area of avalonia though so feedback to fix gaps like this is more than welcome.

[robloo]

As I work through styling issues I realize how increasingly important this type of change is for Avalonia to scale. It's extremely difficult to manage style fragments for all controls when the ordering matters across many different files. A hierarchy to manage this is sorely needed.