Allow setting classes in styles

[Mrxx99]

There are several reasons why it would be great to be able to set classes in styles.

Since Styles can't use BasedOn I would propose the following syntax to be able to compose styles:

<Style Selector="Button.bigboldblue">
   <ClassSetter Classes="big blue"/>
   <ClassSetter Classes="bold"/>
</Style>

This would allow to only add classes (not remove them) so there would be no problem with recursion (E.g. Style A sets class B, style B sets class A would not be a problem).
The setters from the classes added by the ClassSetters are added in the priority as they are written e.g. prio would be (from highest to lowest)

1. Setters written below a ClassSetter
2. Setters in classes defined in ClassSetters
3. Setters written above the ClassSetters

I know the example with bigboldblue is trivial but I think that would be a great improvements to styles as you could wrap, append and compose existing styles easily and avoid duplications.
Also it would allow the often used scenario in WPF that you add a stlye that is applied without a key (e.g. only Button, in WPF TargetType="Button") that is based on a previously defined style. E.g. you define some button styles in App.xaml and inside one UserControl you would want to have all Buttons styled with the same style which is one from App.xaml. You could with that add a style to the user control that has a ClassSetter for that Style from App.xaml:

<Style Selector="Button">
   <ClassSetter Classes="buttonbluedefault"/>
</Style>

[Mrxx99]

This could also allow applying classes to child controls

<Style Selector="Button.TopButton > TextBlock">
  <ClassSetter Classes="h1"/>
<Style/>

[grokys]

I'm generally in favour of this idea, though I'm not sure about the priority part - could you explain your thoughts in more detail?

The reason we've not implemented this before though is because we foresaw a couple of problems:

• What happens when multiple styles set the same class? We'd probably need to store a count alongside the class name in each control to allow this
• It'd probably be possible to cause a loop and hang the application. We might need to mitigate against that

[Mrxx99]

The priority I described was just what felt logical to me. How would you prefer it?
Maybe a simple approach would be that class setters will always be evaluated first (so lower priority) but should they than also only be allowed to be placed above any normal setters?

I don't see a problem when multiple styles add the same class, but I don't know much about the internals of the styling system. But it is already possible to manually set the same class multiple times on a Control as well as it is possible to define two styles with the same selector, the one closest wins. So the same logic could apply when classes are set in styles. Of those classes that are set multiple times use the instance that would be closest asuming setting a class with a ClassSetter has the same distance to the Control as the containing style. Why would it be needed to store the count? Would it allow faster reevaluation if e.g. a style with pseudo-class get's activated/deactivated? If yes, what would be a drawback of storing the count?

I think with the described design it should not be possible to cause a loop when it simply stops evaluating that part when it detects it is going to add a class that is already there. Maybe this will only works correctly if ClassSetters are always evaluated first. Or do you know any scenario where it could happen?
Note: To avoid propblems with recursion was one reason why I described it to not be able to remove classes only to add them.

[Mrxx99]

Or maybe there is no priority definition needed at all, because a ClassSetter does only set a class which does not directly represent a style but the styles that target that class are defined elsewhere anyway, so they just have their normal priority as always they just get activated by another style

[billhenn]

We also have run into some scenarios where it would be handy to be able to add/remove classes to controls within a template. For instance, if you are theming a ScrollBar and you create themes for its line up/down buttons, thumb, etc.. You might want to set a .vertical or .horizontal class on each of those sub-controls based on the ScrollBar.Orientation so they can change their appearance appropriately. However that is impossible right now via setters, so you are forced to duplicate the ScrollBar's ControlTemplate (one for :horizontal and one for :vertical) and hardcode the appropriate classes on the sub-controls based on which ControlTemplate you're in.

[Mrxx99]

Note: this proposal only proposes the ability to add classes not remove them intentionally. As I would see supporting removal would be very complicated to define a clear strategy how to handle this when on style adds and another removes it. E.g. What happens if a style A adds a class B that style B adds another class C which style rmoves the class A or B?