Microsoft-ui-xaml: Proposal: Easily target and customize the CornerRadius attribute(s) of controls

[kikisaints]

Proposal: Easily target and customize the CornerRadius attribute(s) of controls

Summary

This issue is linked/delivering for #524, and scoped from #279 respectively.

Enable a "template-free" way to target and customize/style the CornerRadius attribute on all controls receiving rounded corners by default. List (to be) covered in this proposal.

Rationale

If you need more information/background on these motivators, please see the Important Notes section

| Motive |
|:-|
| Hard-coding CornerRadius values will cause refinement asks from partners across releases thereafter
We saw this with both Acrylic and Reveal since their introduction |
|Many partners (📦) are on different release cycles or cannot spend cycles currently to contribute to the CornerRadius design changes discussion.
This means that when they do adopt it will mean it may not be right for them, and we'll fall into the scenario/motive case from above |
| Tedious Brand Maintenance
Introducing new visual updates like corner roundness without the ability to easily access them means we're giving a lot of tedious diff work to our internal and external partners who wish to stay up-to-date on the latest Fluent Design trend|
| Incurring more template debt
By hard-coding CornerRadius changes into our control templates we're forcing our developers to incur more template debt if they wish to update or revert these changes in their controls |
| Increased resistance to change from our partners as we make it harder for them to update
The more we make it difficult for app-authors to update to our latest and greatest visuals, the more likely they are to be resistant to it, and forcing us later down the road to "band aid" our CornerRadius changes with reversion resources - bloating generic.xaml and introducing more complexity into our styling system |
| Promote poor styling behavior/conduct
Continuing to make our own theme changes within the template - like hard-coding the CornerRadii on controls - encourages and promotes our developer community to do the same. This issue then ties into the template debt and the vicious circle continues |
| Not future-proof/scale-able for anyone but us
Choosing to update our controls by hard-coding CornerRadius changes means we continue to sink time (and customer time) into the symptom of a treatable cause |
| Accessing new attributes like this is a known customer pain point |

Scope

| # | Feature | Priority |
|:-:|:--|:-:|
| 1 | Allows targeting and customizing one or more CornerRadius attributes within a control outside of the control's template | Must |
| 2 | Leverage exisiting methods to target the CornerRadius attribute(s) | Must |
| 3 | The app-author can specify the scope at which the rounded corners of controls will take effect (control vs. page vs. app level) | Must |
| 4 | When the CornerRadius property is set on a control it does something appropriate for that control | Must |

Important Notes

Extra Rationale Information

There are many different concerns when considering a large-all up template/control visual changes like the CornerRadius default changes proposed here.

Tedious brand maintenance

Many apps, both internal and external, brand and theme their apps. So when we roll out large scale branding changes like CornerRadius, we're forcing our internal and external partners that want to move forward with us to take on an incredible amount of tedious work just to stay up-to-date.

:1234: Calculator and round corners

Recently the Calculator app went open source. Which means we now have a simple, clean app representative we can start from to get an understanding of the kind of work needed for them, an internal partner, would have to do in order to move forward with us in our rounded corners by default effort.

At first glance at the Calculator app, you would think that they are using or extending from our default set of controls. However, simply merging in a new generic.xaml with rounded corners actually doesn't do anything in their app.

So we won't break them - good? Not exactly. Since Calculator, among many others, is an internal app partner, they must stay up to date with our Fluent Design. That means we will be pushing them to adopt rounded corners.

So what would that work look like for them?

• They have 9 different button templates defined at the App.xaml level that would need to be diffed against our new rounded button templates to ensure alignment
• 2-3 Template definitions of ComboBox (rounding would need to be on input box and flyouts)
• Non calculation-related flyouts (think about page flyout)

Of those ~13 different templates, once updated there are still some visual inconsistencies:

Due to the sheer volume of templates, it's difficult to know where all the changes need to go.

On top of that, the Calculator team has incurred previous template and styling debt from an inability to access attributes this the CornerRadius in the past. So when rounding corners "successfully" on a template, they will still get issues like these:

Where edges are rounding but backgrounds are not.

Lastly, it's important to note that although extremely useful, the Calculator app is smaller in it's functionality in comparison to other apps like Photos, 3D Viewer and Calendar, for example. So inconveniences like these for the Calculator team only multiply as the app becomes more complex.

Forcing our developers to incur more template debt

• Often times when we make large visual updates/changes like this, and bake them into the system, we're then forcing our developers to re-template in order to alter, go back, or even work with, these new changes.

• Re-templating is expensive, both performance-wise and dev time-wise. Therefore many teams that I have spoken to both internally and externally through //Build conventions and private meetings have mentioned that they need to make re-templating worth it.
  To revert or improve on these CornerRadius changes, instead of just tweaking what they need to, often times they will change radii and then apply extra template changes just to counteract the fact that they had to re-template in the first place. To "justify" the template altering in the first place.

This re-templating forcing function will only increase as we roll out more attribute changes when we push our design system forward.

Not future-proof or forward thinking

Today we want rounded corners, but in the future may want square, or an odd number of corners rounded. By forcing not only our developers to tediously navigate all of generic.xaml and then their own resource dictionaries, we also must poor more and more dev time into making this fashion changes.

Due to our release cycle and the nature and speed of visual design updates, this isn't practical to maintain long-term.

Continue to represent bad styling behavior/conduct

We don't like it when people re-template. That's a fact. It means a high potential for High Contrast and Accessibility breaking, less chance for our developers to get the latest and greatest features, or receive bug fixes.

However, if we continue to make our own theme changes within the template - like hard-coding the CornerRadii on controls because that's the new design theme, we're encouraging and proving to our developer customers that this is the best and only way to style controls in XAML.

Customizing new attributes like this is a known customer pain point

Some cursory looks at what the community is talking about in terms of styling.

• StackOverflow - Styling in UWP Xaml
• Telerik's solution to targetting template attributes/properties
• Response to issue posted about improving our styling and template attribute targeting

Open Questions

[mdtauk]

CornerRadi on XAML elements would need to be reflected in things like ThemeShadow - and default templates can be updated in WinUI 3.0 to match closer to FabricWeb :)

[mdtauk]

Will the FocusVisuals also be able to identify the Corner Radius values?

HighVisibility.DottedLine
FocusVisualKind.HighVisibility
FocusVisualKind.Reveal

[kikisaints]

@mdtauk I don't believe so - but that's a concern for @chigy 😅 as her spec covers the functionality details of the corner radius application, and this issue is covering how we'll propagate it through the system.

[mdtauk]

@mdtauk I don't believe so - but that's a concern for @chigy 😅 as her spec covers the functionality details of the corner radius application, and this issue is covering how we'll propagate it through the system.

<ResourceDictionary.ThemeDictionaries>
      <ResourceDictionary x:Key="Dark">
            ...
            **<Thickness x:Key="CommonControlCornerRadius">2,2,2,2</Thickness>**
            <Thickness x:Key="CommonFlyoutCornerRadius">4,4,4,4</Thickness>
            ...
      </ResourceDictionary>
</ResourceDictionary.ThemeDictionaries>

<Style TargetType="Button">  
      ...   
      <Setter Property="CornerRadius" Value="**{ThemeResource CommonControlCornerRadius}**" />
      ...   
</Style>  

<Button Content="New Rounded Button"  />

<Button Content="Custom Rounded Button" **CornerRadius="4,4,0,0"** />

<Button Content="Current Square Button" **CornerRadius="0"** />

An initial thought is to bind the CornerRadius to those Template Parts which make up the various shapes and borders of each control and flyout container. These would be template bound to the control's CornerRadius property - and so can be changed in a Style or Control scope.

• But would that require adding defined values for the FocusVisual elements?
• Would the FocusVisual itself require a CornerRadius that the control can set?
• Would ThemeShadow and z-depth translation account for the CornerRadius and the shadow?

[chigy]

@mdtauk , there is no plan to adjust the focus visual with the corner radius change. See requirement number 7 in #524. The radius change we are proposing is so small that when we tested against with the existing focus rect, it works just fine. We also expect to see square focus rect around a very rounded UI as many of the web equivalent currently do.

[mdtauk]

@chigy That is fair enough then, not something that needs considering right now.

One day the fully rounded pill shaped control may arrive in Fluent, then it will look weird LOL

[chigy]

@mdtauk, I'm glad you understand that we do need to prioritize the work as well as doing a good job covering all sorts of cases. We want to be agile and deliver changes our customers want sooner while doing good job evaluating all possible scenarios. It is a balancing act as you can see... For this particular case, we did not see an immediate issue/need to do the work. That said, I agree that it might become an issue but we will handle it when it becomes.