Nested /template/ selector in control themes use-cases

[grokys]

As discussed in this PR and in particular this comment we're planning on disallowing nested /template/ selectors with in the new ControlTheme feature (that is, /template/ selectors that probe into the template of an unrelated control).

Existing /template/ selectors in styles outside of control themes will continue working the same for the moment. We'd like to remove the /template/ selector in the long-term (with the exception of a single /template/ inside control themes) however because it breaks encapsulation and makes theme implementation details a public API.

So I'd like to discuss the current use-cases for nested /template/ selectors. In my initial port of the fluent theme to ControlThemes I came across the following use-cases. If you have any more, please note them here.

Modifying the colors of existing controls

Many controls need to modify the :pointerover, :pressed:, :disabled etc states in existing controls: for example the calendar needs to change the colors of these states to a specific resource: https://github.com/AvaloniaUI/Avalonia/pull/8479/files#diff-02d2f8266cc53d3b5141fdcc37693a1a177becf6fbb2ad5d890692296389dea6R47

Adding additional states to existing controls

Sometimes a control hosted in a template needs to have additional states to those defined on the control itself. For example the individual Buttons hosted in a SplitButton have two additional states: checked and flyout-open: https://github.com/AvaloniaUI/Avalonia/pull/8479/files#diff-02d2f8266cc53d3b5141fdcc37693a1a177becf6fbb2ad5d890692296389dea6R47

Modifying existing themes

This is a use-case outside ControlTheme where customers want to tweak an existing theme, such as the fluent theme in some way. I'd be interested to hear what tweaks people are applying in this way. My feeling is that modifying themes in this way is brittle, and we should be providing hooks to allow common customizations (which we already do to a degree by using resources for most things) or encouraging people to instead fork the theme.

[timunie]

I think this discussion should also be forwarded to the owner of theming libs, like:

• Aero Theme - Windows Aero Theme for Avalonia.
• Material Design - Collection of styles to help you customize your Avalonia application theme with Material Design
• Neumorphism.Avalonia - Easy to use and customizable Neumorphism Design implementation for Avalonia.
• Nickvision.Avalonia - A library for Avalonia app development that contains a lightweight MVVM framework, custom controls, and an update framework
• Aura.UI - A Library with a lot of Controls for AvaloniaUI
• AvaloniaRibbon - Ribbon for avalonia.
• ExtendedToolkit - Exteded Controls for Avalonia UI.
• FluentAvalonia - Fluent Design and WinUi Controls

I am sure there is more ^^

[Splitwirez]

I've been...intrigued by this ControlTheme...thing for some time now, so I guess now is about as good a time as any to ask...is that functionality implemented sufficiently to where I could clone the branch in question and just...play around with it, to get my bearings? The feature sounds great in theory and all, but it's hard to say anything meaningful without being able to take it for a spin in practice. This is even more true of any hope of commenting on the implications of the change being discussed here.

[grokys]

Yep, it should be just about stable enough to play around with!

[appleneko2001]

I want keep the flexility to change some small parts of my controls in my opinion, plus the avaloniaUI uses css-like styling system, it should be open sometimes

sounds great if you can encapsulate the styling library to protect it in some reason but I dont really interest this feature...

maybe we should ask how @SKProCH think? he are the second maintainer of Material.Avalonia

[SKProCH]

My opinion - that the key feature of Avalonia, it is possible through /template/ to overwrite this particular part of the style you need. This is very convenient and avoids WPF's situations when you need to change, for example, the color of the line, you'll need to dig out the entire style, paste it into your project and hope that it works (spoiler - not always).

However, on the other hand, I understand the reasons for preparing such changes. I think I'll try to see the implementation and maybe form a different opinion.

[timunie]

I feel the same. However I'd be suprised if Avalonia wants to make things more complicated. So I hope that the styling system is still that easy as it is now, maybe even more powerful and understanble for newbes.

[timunie]

@grokys do you have any sample of how the new theme / style will look like without using /template/ ? In the PR I don't find it and also I can't imagine it to be honest.

[maxkatz6]

Instead of restyling part of the of the template, for example specific property of the Thumb inside of the Slider control, you would need to replace whole ControlTheme of the Thumb.

This way your Slider won't rely on other defined Thumb styles, as you set specific control theme on it.

I would say, it's more wpf/uwp approach.

[pr8x]

[...] you would need to replace whole ControlTheme of the Thumb.

This sounds pretty painful. I think it's reasonable to expect a control having certain "parts" (we have [TemplatePart] after all which defines a contract of a necessary component the control relies on). So it's nice to be able to style these parts as well. Maybe every control could expose some of their "parts" publicly and only these can be styled from outside. This would not break encapsulation and we would style have the benefits of flexible styling.

Example:

<Style Selector="ComboBox /part/ Popup" />

Would focus the Popup part as defined by [TemplatePart] contract. Syntax debatable ofc :)

EDIT: Just saw that the idea is raised down in the thread 😅

[maxkatz6]

I don't think we should completely remove nested /template/ selectors, as it is indeed one of the key features of the styling in Avalonia. And it would make small style corrections in the final app way easier.
Though, it's quite interesting that CSS have removed this feature for the same reasons as you said.

But I do agree that we should recommend to NOT use it in control and theme libraries. As using ControlTheme without nested templates/template selectors is better performance wise and less error prone.

[maxkatz6]

As @kekekeks suggested, it might be a right thing to limit them to named controls like :part selector does.

This way it still will work as a feature, but way less error prone. When developer accidentally applied style on some random unnamed ControlPresenter.

[grokys]

Limiting it to named controls may be a decent compromise. Alternatively having some sort of property to indicate that you're designating a control as your public API.

Of course, there are performance implications for all of this too as @maxkatz6 said. Currently we only need to apply the control theme for the control being styled and its templated parent. If we want to allow nested control themes then it'll involve traversing the tree of TemplatedParents and applying all of those control themes to all controls, not sure what impact that would have: possibly not that much as we're already doing it for our existing styles.

[robloo]

Keep in mind CSS is a much larger beast than Avalonia styles ever will be. There are so many modules on websites now that reference each other and build off other styles its a mess. XAML styles have never gotten to be such a mess. There are at most 4 layers right now and that is manageable and all contained on a per-app basis.

1. Base Avalonia FluentTheme
2. Added controls DataGrid, ColorPicker
3. 3rd Party Themes
4. App Themes and Styles

So while I understand the logic with CSS decision to remove this it may not apply to XAML and Avalonia simply due to the difference of scale and real-world usage.

[grokys]

Btw, there's been a decent bit of discussion around this feature, but no-one's answered my question ;) What are your use-cases?

[robloo]

Here is the most recent example I have (it doesn't work due to priority but was hoping to fix it when I do the ControlTheme updates to ColorPicker). For now just consider this a conceptual example:

Avalonia/src/Avalonia.Controls.ColorPicker/Themes/Fluent/ColorPicker.xaml

Lines 85 to 89 in 0dca4be

	<!-- Adjust Background within Flyout -->
	<!-- Note: This is implemented but there seems to be an issue and the selector can't match across the Flyout -->
	<Style Selector="ColorPicker /template/ ColorView#FlyoutColorView /template/ Border#TabBackgroundBorder">
	<Setter Property="CornerRadius" Value="{DynamicResource TopOverlayCornerRadius}" />
	</Style>

Due to the size of the ColorView template it is easy to see why it's undesirable to re-template this to change one corner radius. Using a named control or defined part of the template would be acceptable here though.

[robloo]

Other examples are in the SplitButton which you have already seen I believe:

Avalonia/src/Avalonia.Themes.Fluent/Controls/SplitButton.xaml

Lines 147 to 156 in 0dca4be

	<Style Selector="SplitButton:pressed /template/ Button#PART_PrimaryButton /template/ ContentPresenter,
	SplitButton:pressed /template/ Button#PART_SecondaryButton /template/ ContentPresenter,
	SplitButton:pressed /template/ Border#SeparatorBorder">
	<Setter Property="Border.Background" Value="{DynamicResource SplitButtonBackgroundPressed}" />
	<Setter Property="Border.BorderBrush" Value="{DynamicResource SplitButtonBorderBrushPressed}" />
	<Setter Property="TextElement.Foreground" Value="{DynamicResource SplitButtonForegroundPressed}" />
	</Style>
	<Style Selector="SplitButton:pressed /template/ Button#PART_SecondaryButton PathIcon">
	<Setter Property="Foreground" Value="{DynamicResource SplitButtonForegroundPressed}" />
	</Style>

[robloo]

Apologies for another discussion. I am glad to see this is the public forum though as it's one of those things so fundamental to devs. I'm going to approach this at a high level to start:

This at first seems like a solution to a problem that doesn't exist (from an app dev standpoint). I haven't heard anyone complain about the ability to drill into templates with selectors. In fact, it is one of the most powerful features with Avalonia's styling system. Personally, I thought it was amazing when I saw this functionality for the first time. It saves a lot of time.

I also realize the concerns about public API surface area and the necessity to smoothly transition to Fluent v2 in the future for example. This kind-of puts frameworks in a no-win scenario where if you make everything "private" some devs still need it. And if you make things "public" devs complain when stiff breaks between major versions. However, as with everything, I don't think either of those two extremes is correct. Accessing templates should be allowed but only rarely or within a theme itself. Breaking is OK but silent breaking is the real issue. The Xaml compiler needs to detect and throw errors in this case. I think the compromise above of requiring named controls is a good middle road here.

Additionally, removing this feels analogous to Microsoft trying to remove visual tree accessing methods and abstract away the default styling implementation from apps. Their reasoning was similar: microsoft/microsoft-ui-xaml#1331. I ended up collecting many use cases over time to show why this was a bad idea in principle.

More fundamentally though, developers should be empowered to make the final decision themselves and for their own apps on doing things like accessing templates directly and making them inter-dependent. There are situations where the cost/benefit makes accessing the template directly an obvious choice. I can see countless examples over the years where the first recommendation is to do so. It really is a huge time saver (I don't have time to collect all the examples right now, nor do I think that is strictly necessary for a high-level, conceptual discussion).

Functionality like this being removed is more for the sake of the framework maintainers. From that viewpoint it makes sense. But a framework isn't really written for the framework maintainers -- it's written for app developers. At the end of the day app developer needs must take priority for the framework to be most successful.

With inter-dependencies in styles/themes, app code needs to change when default styles and themes are updated over the years. That's a normal thing in development though and would also be alleviated by splitting the themes up in separate nugets and allowing apps to use whichever theme wish (even old ones). Which leads to:

A single theme can have inter-dependencies.

The problem with this is, how do you define a theme? Are we talking about the fluent theme as defined in Avalonia.Themes.Fluent? Or does it include Avalonia.Controls.DataGrid/ColorPicker fluent themes? If it also includes those then it probably should include 3rd party fluent themes, right? And so you're back to having the contents of our themes be a public API.

In my mind the base FluentTheme in core Avalonia should be extensible so DataGrid and ColorPicker can add to it. So they are still part of the "FluentTheme"; however, the dependency is one-way ColorPicker/DataGrid -> Core Avalonia (no two-way dependency). This is the same for FluentAvalonia and higher level themes. They should be able to extend the core fluent theme and take dependencies one-way. So everything is still cleanly layered: Core Avalonia -> ColorPicker/DataGrid -> FluentAvalonia.

Bottom line though: /template/ in selectors IS the most powerful part of Avalonia's styling system in my opinion. Removing that would be a big loss. Requiring named controls is a good middle-road and would allow the XAML compiler to throw exceptions when things are moved/renamed (so things shouldn't silently break).

[grokys]

Functionality like this being removed is more for the sake of the framework maintainers. But a framework isn't really written for the framework maintainers -- it's written for app developers

Not really. ControTheme is mainly for theme maintainers, not app developers. App developers still have the existing functionality in regular styles for now (as much as I dislike it). I had imagined that encapsulation and being able to make changes to themes without breaking user code would be useful to theme developers. Features that improve this for theme developers will also be available to app developers, meaning they need to rely less on `/template/.

Accessing templates should be allowed but only rarely or within a theme itself.

And that's the problem - nested /template/s are used everywhere. That's because there's currently no alternative! When all you have is a hammer, everything looks like a nail. I think this is borne out by the fact that this discussion is currently only about the removal of the feature, there's no discussion of use-cases so far. Everything looks like a nail!

When I refactored our fluent theme, I had distinct flashbacks to when I started programming with VB6. Everything is public! You can do whatever you want! Now my boss loved that freedom and still made everything public even when we moved to C, but I had to maintain this VB6 code so I really appreciated private when it was given to me and tried my best to get him to use it (I failed). Similarly when refactoring the fluent theme, I had the feeling that not reaching into arbitrary controls and messing with their internals was an improvement. Sure there are some things that it made more difficult, but that's because we don't have any tools other than "everything is public!". Experiences vary though - @Takoooooo did part of the porting and he was pushing hard to allow nested /template/ selectors.

Bottom line though: /template/ in selectors IS the most powerful part of Avalonia's styling system in my opinion.

As an opposing voice, in my opinion, the /template/ selector was one of the biggest mistakes I made in the early days of Avalonia. Had I started a few years later - after the /deep/ selector had been removed from CSS - it wouldn't be there. The authors of CSS realized that they had made a mistake, removed it, and replaced it with something better. We should strive to do the same.

[timunie]

And that's where I currently stuck. I see no better option, but I may be wrong. What is an alternative you think of? Copy & Paste the complete control template like I did in WPF?

For a use-case consider this:

You have a DataGrid which is grouped. So far so good. But instead of ► and ▼ as a symbol you want [+] and [-] as a symbol. Right now it's easy like changing this:

Avalonia/src/Avalonia.Controls.DataGrid/Themes/Fluent.xaml

Lines 483 to 499 in e9aa43e

	<Style Selector="DataGridRowGroupHeader /template/ ToggleButton#ExpanderButton">
	<Setter Property="Template">
	<ControlTemplate>
	<Border Grid.Column="0"
	Width="12"
	Height="12"
	Background="Transparent"
	HorizontalAlignment="Center"
	VerticalAlignment="Center">
	<Path Fill="{TemplateBinding Foreground}"
	HorizontalAlignment="Right"
	VerticalAlignment="Center"
	Stretch="Uniform" />
	</Border>
	</ControlTemplate>
	</Setter>
	</Style>

What would be the new way to do?

[robloo]

Not really. ControTheme is mainly for theme maintainers, not app developers. App developers still have the existing functionality in regular styles for now (as much as I dislike it).

Every app I've ever written ends up with custom controls that will also have ControlTheme. So while I understand what you are saying, this is still for everyone even app developers. And I think the root change is still being driven from a framework mindset. (which reminds me, FluentTheme really needs to be extensible and I haven't seen that so far).

It's good app developers have this support still in styles but as mentioned elsewhere I know you want to remove it there too so I am speaking largely big-picture with that in mind.

And that's the problem - nested /template/s are used everywhere. That's because there's currently no alternative! When all you have is a hammer, everything looks like a nail. I think this is borne out by the fact that this discussion is currently only about the removal of the feature, there's no discussion of use-cases so far. Everything looks like a nail!

I created a separate thread for this. But it makes far more sense to do the opposite and allow access to the template within ControlTheme. Most of the time you are literally referencing parts within the same exact file. Why wouldn't this be allowed? My point was a theme itself absolutely should have this power. I think styles should too... but that use case is a little more grey because as you said devs use it everywhere (which actually indicates it might be very useful though).

I've also copied your long-term plan for some features to replace \template\ in ControlTheme as another thread below. We can talk about other types of tools besides "hammer". At the end of the day though, nothing I've seen even comes close to the speed and usefulness of \template. It's been thousands of years but you know what -- people still use hammers.

When I refactored our fluent theme, I had distinct flashbacks to when I started programming with VB6. Everything is public!

There is something fundamental here: You as a developer are empowered to make a mess of your own code base however you want. No matter how good the language is, no matter how good the tooling is, if you are bad at software architecture or undisciplined the app is going to be a mess. I've seen this countless times in LOB apps that are the ugliest pieces of software imaginable (and impossible to maintain once the original dev leaves). So I understand what you are trying to say here. However, that is the developer and lead engineer's fault... it isn't the fault of the language itself. C#, walks a nice balance between ease-of-use and power. However, developers aren't children and they need to make their own decisions -- and should be empowered to do so. C/C++ still exist for a reason: sometimes you need maximum control. Again, as a framework, you need to empower devs to do what they think is best. As soon as you think you know what is best for devs and remove functionality like they are children and don't know what they are doing I would say we've gone the wrong direction. I had several conversations with Microsoft about this same topic over the years...

Similarly when refactoring the fluent theme, I had the feeling that not reaching into arbitrary controls and messing with their internals was an improvement.

Everyone has a different gut feeling and opinion about this. In fact, I think you are in the minority. However, I think you are overlooking the other side of this considerably. In this specific case of porting the FluentTheme:

1. Why wouldn't a theme itself have access to it's own internals? That doesn't make sense to me. It makes more sense to allow it here than in Styles
2. Why would you want to duplicate all of these templates when you need to change something? (Duplicate code is also a big maintainability concern).
3. The time saved by using \template\ is considerable. A lot of us have used UWP for years and know very well the difference and have seen both sides. I'm telling you I personally never want to go back.
4. As mentioned elsewhere, using light-weight styling resources to change something is great when needed. However, no control author can think to make an independent resource for everything. \template\ is a powerful work-around when no resource exists that doesn't require re-templating. Again, big time saver and doesn't require duplicate code.

As an opposing voice, in my opinion, the /template/ selector was one of the biggest mistakes I made in the early days of Avalonia. Had I started a few years later - after the /deep/ selector had been removed from CSS - it wouldn't be there.

While it's true we probably never would know what we are missing if \template\ never existed; we are actually in a much better position to judge this now. We know what UWP is like vs current Avalonia with \template. It seems to me you made the right decision all those years ago so thank you for starting when you did :)

The authors of CSS realized that they had made a mistake, removed it, and replaced it with something better. We should strive to do the same.

I don't fundamentally disagree with this. I will however say I haven't seen anything better -- nothing even close actually. I copied your ideas in another thread below. Making Parts for everything is more of the same issues as light-weight resources though. We end up making everything a variable and styles become huge and we have the same maintainability concerns. We are also then locked in and can't change parts. So you aren't fundamentally solving ANY of the problems with \template\ you are just adding 1 or 2 more layers of abstraction to move the problem to and then adding complexity. Not good.

[robloo]

Add a :part selector - the details of this need to be fleshed out, but we already have concept of "parts" and we already have the [TemplatePart] attribute, so conceptually it's a good fit for Avalonia

A template part is traditionally only those named controls used with code behind. Within templates themselves, of course elements can be named and used in styling but that is independent of code-behind and is not a template part with a "PART_" prefix. So we would confuse things a little if we called both template parts.

[maxkatz6]

About what you mentioned in another thread about throwing an exception when something was renamed. I don't see how we can achieve it without [TemplatePart].
We can throw an exception if there is no name at all, sure. But how compiler would find out if something was renamed or moved? I believe we need some kind of an attribute for that, like TemplatePart. Or another one.
On other hand, it will add another limitation, if any named control wasn't defined with an attribute, selector would just throw an exception, even if it exists in the template itself.

[robloo]

We can throw an exception if there is no name at all, sure. But how compiler would find out if something was renamed or moved? I believe we need some kind of an attribute for that, like TemplatePart. Or another one.

If we require a name for all controls used with \template\ in a selector this should work. So for example:

1. \template\ Border is invalid and throws an exception: "Control name required"
2. \template\ Border#BackgroundBorder would compile just fine.

It wouldn't inform developers of new naming -- it would only say "Control of the name "BackgroundBorder" was not found within template". I think this should be possible?

I would avoid all new attributes.

[maxkatz6]

Control of the name "BackgroundBorder" was not found within template. I think this should be possible?

Only in runtime. Compile time we don't know what's inside of the template.

[robloo]

Well, I was thinking this was possible in compile time. Runtime exceptions for styles are generally frowned upon unfortunately (there was a big WinUI discussion about it).

[flarive]

Hi,

I just love using template selectors in Avalonia.
They are fast and simple to use with the Avalonia VS extension intellisense.

It would be so sad to see them disapear.
In Neumorphism.Avalonia i'm using template selectors a lot, i don't see very well how can i do without them.

Developping a new way to style template with ControlTheme could be usefull i suppose (even if i don't need it now because with template selectors i can acheive everything i want), but it would be great if it could be an optional feature that doesn't replace template selectors.

Avalonia doesn't have breaking changes since 0.10.0, it would be sad to have to replace all template selectors in existing code to solve a problem that i don't really understand and care.

Please don't break everything, please don't force developers to rewrite working code, please add new features next to existing ones (and not instead of existing ones) and don't break things...

Eviral

[flarive]

Hi Robloo,

I don't see how ControlTheme will work.
Will it be done in xaml files like template selectors ?

Could you show us a sample project showing how Avalonia controls could be themed using this new way please ?
It could be great to help us understand how it will works and to know if it will be possible for us to migrate from template selectors to ControlTheme without losing features in our custom themes projects.

Thanks a lot :)

[flarive]

Hi Grokys,

Really cool if template selectors will continue to work and will never disapear from Avalonia, great news !!!!

[robloo]

@flarive ControlTheme is the new term for the default style of a control -- including its control template. It is now fully self-contained and will be in resource collections separate from styles. You are able to specify the ControlTheme directly with each control's Theme property. This was discussed a bit more in the PR #8263. Otherwise, I'm not really the correct person to speak about this.

[maxkatz6]

@flarive you also can find more examples here #8479 , where whole Fluent theme was upgraded to use ControlThemes.
No matter how this discussion about /template/ will end, we really recommend control and theme creators to use ControlTheme feature, as it will make applications better. More information will be added later in the documentation after the 11.0 release.

[maxkatz6]

@flarive control themes are compatible with old styling. You still can apply many styles on top of a control theme. Though some details might be changed.

To explain control themes shortly, I would say it works like a group of styles, that are applied and removed together, and same control can have only one control theme at once. Similarly, how Styles work in UWP or WPF.

And some benefits:

1. You can easier remove old control theme from a control and replace it with another. Previously If you loaded application with a Fluent theme, you can't easily remove "Fluent" style from the button. You need to create your own one ON TOP of the fluent theme. That was biggest problem with old approach. With new approach you can replace ControlTheme completely.
2. Performance is better with control themes, as control will process only one group at once.
3. Styles inside of the ControlTheme group are isolated together.

It also works with nested styles.

[MikeCodesDotNET]

To add my 2 cents on the /template/ selector discussion and share how I use selectors to tweak. I've just looked at the theme for my lighting controller and see that my most frequent usage affects Borders. Commonly I'm tweaking corner radiuses, colours and handling states like checked, selected and all the pointer states.

I'll often copy and paste large chunks of a control's style from the fluent theme and then go to town on tweaking values. My tweaks typically involve removing references to or overriding resources defined in the Accents directory with resources defined within my controls styles (keeping everything in one place). You can see an example of this with this Button style.

I know I could have achieved 99% of what I desired by simply overriding existing resource values defined, but I found reasoning about the resource value particularly arduous. I'd find myself switching between multiple files and searching for the resource keys. For example, trying to style a Button background with the 'accent' selector meant I needed to look for the StaticResource named AccentButtonBackground, which references a SolidColorBrush named SystemControlBackgroundAccentBrush, which itself references a Color called SystemAccentColor. Once I found the color, I'd have to examine where else it's being used and then determine if I should change the value or create a new value.

In my mind, copying pieces of the existing control existing styles and overriding resource values within the same file made it easier and faster to make changes. While it adds unnecessary code and much duplication, it significantly reduced the need to bounce through multiple files as I traced values. By copying styles, including those using the /template/ selector, it was easier to reason about which properties I'd need/want to tweak.

I suppose the only reason I'm using the /template/ selector in the first place was that's how the existing styles do it. When the new approach is ready, I'll probably do what I did before and copy pieces of the default theme and make my changes. As long as I can continue to tweak values readily, then I'll be indifferent about the changes.

[grokys]

Thanks @MikeCodesDotNET - that's really useful information! And yes, overriding resources feels like the "right" way to do this, but as you say it's not easy to work out exactly which resources you need to override. That's definitely something we should look into improving.

(Do note though, that from your POV as an app author this won't even be a change as it only applies to ControlThemes not existing styles).

[robloo]

You have stated elsewhere that the long term goal is to remove /template/ from styles as well. I think all of us are cognizant of that and speaking in more broad terms with that in mind. Even a gradual change that is directionally disagreed with will meet resistance.

Long term, eventually do a gentle deprecation of the /template/ selector outside control themes

[kekekeks]

The deprecation is more about providing new better tools to achieve the same effect rather than feature removal. That's why we are asking for the use cases to better design such tools.

[robloo]

Change for the better is great of course. I haven't seen any option that is actually better though. You are going back to what UWP had which I've been using for years and know very well.

This whole discussion has a huge aspect to it you are both (@grokys @kekekeks) overlooking. That aspect is well outlined above: time. The cost/benefit of using /template/ in selectors is an massive advantage to Avalonia. It simply saves so much time and is so easy to use. I do not want to go back to what UWP had. I'll comment the rest on this when I get to answering my thread above.

[robloo]

I'm pulling this out part out as the "scope" of this change I think is relevant. @grokys has commented:

Do note though, that from your POV as an app author this won't even be a change as it only applies to ControlThemes not existing styles

Existing /template/ selectors in styles outside of control themes will continue working the same for the moment. We'd like to remove the /template/ selector in the long-term (with the exception of a single /template/ inside control themes) however because it breaks encapsulation and makes theme implementation details a public API.

and

that's exactly what it is - existing styles with /template/ selectors will continue working as they've always done.

The intention long term (unless that has changed in the last 48 hours) is to remove \template\ selector support from styles someday as well. A lot of the comments are already taking that into consideration.

That said, removing \template\ from ControlTheme is easier because its new. However, ControlTheme makes more sense to allow \template\ than Styles based on your logic. Simply put, ControlTheme IS the theme itself. It absolutely makes sense to reach in and change elements in it's own template or even nested templates. That makes total sense because a ControlTheme is defining the template.... why wouldn't it have access to it's own "internal" members?

Style is outside the control theme and heavily used by app authors. Allowing it here is exposing it as a public API and is actually the worst case for it (by your reasoning, NOT mine). If you allow it in Styles you should allow it in the ControlTheme. If you are disabling it in one of the two it should be allowed in ControlTheme but disabled in Style -- by your own logic of encapsulation and locking down "public" APIs.

[robloo]

Another broad comment here: You are trying to steer this discussion just to examples. That can sometimes help move things forward in a rational way. However, it would be nice to see a much more democratic process for these types of fundamental decisions BEFORE they are made.

There is a lot of knowledge in the users of Avalonia and they all have their own 'gut feeling' too that I think is relevant. I would normally like to see something like this discussion approached as "Should we keep /template/ support in selectors" rather than give me "\template\ selector use-cases" so I can make the final decision. You have a lot of bias already and I'm not sure any examples we give you will ever change your mind. Your reasoning is different and more fundamental.

[robloo]

I'm copying this over as well. #8479 (comment)
The discussion has already expanded beyond simple use cases so I think everyone should read the long-term plan here.

---

I've found other places where directly accessing the template of a control within a template is very useful. Not trying to start another big discussion but if I had a vote I would not want to remove this functionality.

Yeah we had a pretty intense discussion about this internally as well, but the general consensus was:

• The /template/ selector was generally speaking a mistake. It came from the CSS /deep/ selector which was removed and for good reason - it breaks encapsulation and is essentially the equivalent of changing private fields in a class using reflection
• A /template/ selector which can poke into any template was needed previously because of the way our styles worked - there was no scoping of styles
• The CSS /deep/ selector was replaced by the :part selector which is much better because it defines an API contract

So the plan is to:

• Add a :part selector - the details of this need to be fleshed out, but we already have concept of "parts" and we already have the [TemplatePart] attribute, so conceptually it's a good fit for Avalonia
• Add a ClassSetter which can be used to add extra state to other controls from a style
• Long term, eventually do a gentle deprecation of the /template/ selector outside control themes

To give some context: we're currently basically unable to change our templates between major releases because the template contents essentially become a public API due to /template/. So we have to balance the fact that 1) /template is a problem and 2) removing /template/ would break a lot of code if we did it now.

Given the above we felt that preventing meddling with implementation details of other controls in a new feature is a good start, but removing the feature as it already exists is probably a step too far right now.

We are actually open to removing the limitation on nested /template/ selectors in control themes if a problem arises that literally cannot be solved by any other means, but as you know it's far easier to add features than remove them! So for the moment I'm hoping that by disallowing nested template selectors we can understand what exactly they're needed for and try to come up with better solutions for these use-cases.

Does that make sense?

[grokys]

I've tweaked the title and some wording a bit to make it clear that we're talking about nested template selectors in ControlThemes, e.g.;

^:pointerover /template/ Button /template/ ContentPresenter

Where the selector is reaching into the template of a separate control. Single levels of /template/, e.g.

^:pointerover /template/ Button

Are absolutely fine, and expected.

[pr8x]

I really like the /part/ syntax from CSS (as mentioned above). IMO it would be fine to deprecate (and later remove) /template/ selector outside of the control's theme and introduce a well-defined parts contract for each control that can be styled through /part/. This would be an immense improvement over WPF's rigid styling system while still providing proper encapsulation and freedom for implementations to wrap/nest parts in whatever they want without breaking existing styles.
We could even think about optional parts that are not strictly necessary for the control to work. If an optional part does not exist the /part/ selector would simply not trigger.

[timunie]

Ahhrg okay so yeah for this scenario I don't have any usecase until now. This also looks not really readable to me.

[robloo]

Thanks for clarifying and apologies for my misunderstanding. Most of my concerns go away if this is only for nested templates. This case is rare enough it's tolerable to solve in a few different ways: re-templating is possible as well as adding new parts.

I still wonder if part should be disambiguated between ones used in code-behind and ones only for XAML though.

[almightyju]

I've just ran into this while trying to make a control that in simple form has a TextBox and a Button (think editable combobox), the issue I have is that I can't set the border of the inner TextBox when it is focused inside the ControlTheme, e.g.

<ControlTheme ...>
	<Style Selector="^:focus /template/ TextBox#Text /template/ Border#PART_BorderElement">
		<Setter Property="BorderThickness" Value="0" />
	</Style>
</ControlTheme>

Obviously this doesn't work, I tried all sorts but in the end the only way I found that works is overriding the resources (couldn't seem to get the resources to apply via a style so had to set it directly):

<ControlTheme ...>
	...
	<TextBox ...>
		<TextBox.Resources>
			<Thickness x:Key="TextControlBorderThemeThicknessFocused">0</Thickness>
		</TextBox.Resources>
	</TextBox>
	...
</ControlTheme>

I think this is similar to other cases listed here but it would be nice if in my case the TextBox BorderThickness property was also used for focused and pointerover states, or perhaps extra properties I could control directly.

[robloo]

I ran across another important use-case of this. I have a custom control that has a DropDownButton in the root of the control template. This works fine and is great to simplify building the control using the DropDownButton as a primitive. However, I need to be able to change the drop down glyph... which I can't do without nested template selectors like this:

        <!-- Switch to a Calendar Glyph -->
        <Style Selector="^ /template/ DropDownButton#LayoutRoot /template/ fac|FontIcon#DropDownGlyph">
            <Setter Property="Glyph" Value="&#xE787;" />
            <Setter Property="FontFamily" Value="{DynamicResource ControlSymbolFontFamily}" />
        </Style>

(note this uses FluentAvalonia's DropDownButton ControlTheme).