Microsoft-ui-xaml: Proposal: Easily target and customize the BorderThickness property on controls

Created on 11 Jul 2019  路  4Comments  路  Source: microsoft/microsoft-ui-xaml

Proposal: Easily target and customize the BorderThickness property on controls

Summary

This issue is linked/delivering for #835

Support easy customization of the BorderThickness property on all controls that have a defined border of 2px in the system today.

Rationale

  • Ensuring that properties like BorderThickness are easily customize-able at any scope dramatically reduces the refinement requests from consuming partners, as well as speeds up design iteration time
  • Many partners are on difference release cycles and cannot afford to be involved in the decision making process immediately. Giving them quick and broader access to properties we change from release to release provides them with the ability to quickly update and stay cohesive with the latest.
  • The more access to properties/attributes outside of the template we give, like BorderThicknesses, CornerRadius' etc. the less template debt we're forcing our partners to incurr, thus making it easier for them to adopt to the latest Fluent Design principals.

Scope

| # | Feature | Priority |
|:-:|:--|:-:|
| 1 | Allow easy targeting and customizing of the default BorderThickness of controls which have 2px borders today | Must |
| 2 | Leverage existing methods to target the BorderThickness attribute(s) | Must |
| 3 | The implicit and explicit BorderThickness property sets the thickness value appropriately for the targeted control | Must |

area-Styling area-UIDesign feature proposal team-Controls

Most helpful comment

If ThemeResources are made for the default border thicknesses, individual resources for specific controls would make sense also.

@mdtauk the way we're approaching this is to ensure that the BorderThickness property on the UIElement itself responds to the correct/appropriate control part(s) when set implicitly or explicitly. Then, we'll probably introduce individual thickness resources for each control as needed moving forward (release to release).

Staggering the work like that means a higher likelihood of it getting done, and our customers and partners have something to work with sooner - however, it may mean we don't have all the thickness resources for every individual control available right out of the gate.

Makes total sense.

Update the controls so border thickness will function properly, make resources for global values, resources for each control, then fix the templates to use them.

The Calendar flyout example wouldn't strictly use a border thickness value in this scenario, but would use margins, widths, or padding to control the spacing between the Day buttons.

I know this comes at the Template/Resources stage - but I thought I should mention it because there may be other controls which would need adjusting to the new global thickness resources being implemented.

All 4 comments

If ThemeResources are made for the default border thicknesses, individual resources for specific controls would make sense also.

The TextField and Form controls, should have a 2px thick border when focused/active - As should the GridView Selected border.

Other borders should be 1px.

Relevant issues #898 #895 #835

I have made an issue to discuss Text and Form controls, and that involves use of borders to clearly show behaviours and touch targets. #899

Comparing Similar Controls

There could also be some scope for looking at the Button design, as Fabric and FastDNA buttons offer Outlined button styles, and these along with SplitButton would need consideration with ThemeResources.

Buttons

Also more complex controls like the CalendarFlyout, which uses 2px spacing between items.

image
_A mockup I made of an adjusted Calendar Flyout_

If ThemeResources are made for the default border thicknesses, individual resources for specific controls would make sense also.

@mdtauk the way we're approaching this is to ensure that the BorderThickness property on the UIElement itself responds to the correct/appropriate control part(s) when set implicitly or explicitly. Then, we'll probably introduce individual thickness resources for each control as needed moving forward (release to release).

Staggering the work like that means a higher likelihood of it getting done, and our customers and partners have something to work with sooner - however, it may mean we don't have all the thickness resources for every individual control available right out of the gate.

If ThemeResources are made for the default border thicknesses, individual resources for specific controls would make sense also.

@mdtauk the way we're approaching this is to ensure that the BorderThickness property on the UIElement itself responds to the correct/appropriate control part(s) when set implicitly or explicitly. Then, we'll probably introduce individual thickness resources for each control as needed moving forward (release to release).

Staggering the work like that means a higher likelihood of it getting done, and our customers and partners have something to work with sooner - however, it may mean we don't have all the thickness resources for every individual control available right out of the gate.

Makes total sense.

Update the controls so border thickness will function properly, make resources for global values, resources for each control, then fix the templates to use them.

The Calendar flyout example wouldn't strictly use a border thickness value in this scenario, but would use margins, widths, or padding to control the spacing between the Day buttons.

I know this comes at the Template/Resources stage - but I thought I should mention it because there may be other controls which would need adjusting to the new global thickness resources being implemented.

@kikisaints , have you created a doc for the new property?

Was this page helpful?
0 / 5 - 0 ratings