Please, review the following pull request #6168. These changes allow to cancel styles from above logical tree

[npolyak]

Please, review the following pull request #6168

Here is an example of having two buttons without styles with one button containing a FluentTheme button style. The trick is to add a Styles to CanceledStyles property of a Visual element to cancel all the styles with that selector defined above in the logical tree:

<StackPanel x:Name="PanelWithCanceledButtonStyle1">
  <StackPanel.CanceledStyles>
    <Style Selector="Button"/>
  </StackPanel.CanceledStyles>
  <Button x:Name="RetemplatedButton1"
          Width="250"
          HorizontalAlignment="Center"
          VerticalAlignment="Center"
          Content="Hello World">
    <Button.Template>
      <ControlTemplate TargetType="Button">
        <Border BorderBrush="Black"
                BorderThickness="5"
                Background="Red"
                Width="50"
                Height="50"/>
      </ControlTemplate>
    </Button.Template>
  </Button>
</StackPanel>

<Button x:Name="ThemeButton"
    Width="250"
    HorizontalAlignment="Center"
    VerticalAlignment="Center"
    Content="Hello World"/>

<StackPanel x:Name="PanelWithCanceledButtonStyle2">
    <StackPanel.CanceledStyles>
      <Style Selector="Button"/>
    </StackPanel.CanceledStyles>
    <Button x:Name="RetemplatedButton2"
            Width="250"
            HorizontalAlignment="Center"
            VerticalAlignment="Center"
            Content="Hello World">
    <Button.Template>
      <ControlTemplate TargetType="Button">
        <Border BorderBrush="Black"
                BorderThickness="5"
                Background="Red"
                Width="100"
                Height="100"/>
      </ControlTemplate>
    </Button.Template>
  </Button>
</StackPanel>

And here is how it looks:

the retemplated buttons do not have any styles from the top, so they do not shrink when clicked.

[maxkatz6]

I see how it can be useful and agree that we should have it.
But not sure about this specific API. It doesn't look intuitive for me.

Since we're following CSS-like selectors and styles, it might make sense to port CSS "all" property, see
https://developer.mozilla.org/en-US/docs/Web/CSS/all
https://bitsofco.de/initial-inherit-unset-and-revert/

So I would imagine something like

<Style Selector="Button.with-all-unset">
    <SetterAll Value="Unset" />
    <Setter Property="Foreground" Value="Blue" />
    <Setter Property="Template" Value="{StaticResource CustomButtonTemplate}" />
</Style>

But it's only my thoughts. @AvaloniaUI/core

[maxkatz6]

it might be a little difficult to implement though, and I am not sure I'll have time for it right now

That's fine. I personally also not sure about how hard is to implement my idea. So that's why I pinged team to give some opinions.

So perhaps we can have my solution as a temporary fix and then go all the way with the CSS

The problem is that we will need to deprecate previous solution or have two solutions for the same problem. And either way doesn't feels great. Although we might add some lower-level APIs that might allow cancelling styles, so develop will be able to implement some attached property or kind to do the same (i.e. without adding Style.Cancel or CancelledStyles).

I think we can do simpler and better than that - just my opinion. I prefer the straightforwardness of WPF.

Yeah, I agree that we shouldn't bring legacy from HTML/CSS to XAML frameworks. Although styling is one of the places, where CSS did it more flexible, when you can combine class-names. Let's say, it does not requires re-templating whole control, if you need to change properties of specific template child (but I remember it's not your case).

[npolyak]

Speaking of Styling - I think WPF styling is missing the multiple Style inheritance. If we can implement a WPF-like style with multiple inheritance it will probably be more powerful than WPF and clearer than CSS. I need something of that sort in order to be able to use Avalonia efficiently, so I might work on it.

[npolyak]

Speaking of allowing /template part of the selector to modify the template - perhaps I am a little tied to WPF thinking, but I think it might be a bit over permitting. In the perfect WPF world where I am coming from, if a developer wants to allow the user to modify something within a template - he'd have to create a dependency or attached property to control that feature and bring it out to the control's level. When something has to be modified on an already existing control for which one does not have a code - one can also do it by inserting a binding on some new attached property and the element in the visual tree you want to modify. It is pretty difficult to do but, quite possible. /template part of the selector is something I have doubts about.

[grokys]

Speaking of allowing /template part of the selector to modify the template - perhaps I am a little tied to WPF thinking, but I think it might be a bit over permitting

Definitely. I think /template/ is one of those features that seemed like a good idea at the time, but now I regret... The contents of a control template should really be considered an implementation detail but /template/ breaks this encapsulation.

To give some history, it came from the CSS /deep/ selector which existed when I originally wrote the feature but was removed for exactly this reason.

[Splitwirez]

@grokys Seriously? IMO /template/ is a HUGE step forward for lookless controls, and helps to address the absurd levels of code duplication you could end up with in WPF and co. Is it perfect? No, I don't think it is...but it helps a lot at times.

...I am curious, now, as to what the problem with /template/ is...

[grokys]

Yeah, a change like this would need a lot of discussion I think. We already have plans in place to address the issue that you were experiencing (#2769) I think but that's a longer-term project that is going to need proper support from the XAML compiler.

So perhaps we can have my solution as a temporary fix and then go all the way with the CSS.

As Max said, unfortunately temporary fixes aren't really acceptable at this point in the project. Once people start using it, it's going to be very difficult to remove because people will start depending on it.

However... I think your solution could be implemented without making any changes to Avalonia if you're sure that this is what you want and you don't want to wait for us. If I get a bit of time, I can try to put together a solution. Basically, we allow you to override the IStyler used to apply styles. You should be able to create your own styler and put this logic in it. You should also be able to use this to implement the WPF-like styling system that you were talking about should you like.

[npolyak]

Hey Steven, I was thinking of the same - re-implementing the styler, but then I noticed that it will not be sufficient - you have to specify the styles you want to remove at the logical tree level. In general - I view the styles as a collection - you allow adding styles at each level. In that case, you should also allow removing them - just like if you'd only allow the event handlers to be added and not removed - it would not be sufficient. So .Styles property is for adding styles - we should probably have another property to remove the styles by their Selector. I am willing to participate in any discussion. Also, I would like to implement the WPF type styles (as specified in #2769) with additional multiple Style inheritance - should take about a week or so, if I'll be allowed to do the change. I believe, the solution along the lines I described above can be a permanent one as long as we do not need to mimic the CSS.