Proposal: Form Control Styles - Consistent to Fluent UI and FastDNA (Xbox too?)
See original GitHub issueProposal: Form Control Styles - Consistent to Fluent UI and FastDNA
Summary
As requested by @chigy this is a proposal to introduce some kind of FormControlStyle property to relevant controls, which enables the developer to set the visual look of their Form Controls from a set of known and approved designs which align to Fluent UI and FastDNA concepts of button types - without manually overriding or setting Xaml Styles - which would lead to inconsistent variations,
image is an example of how the controls would look in these initial 4 styles
Rationale
- Microsoft’s other UI platforms have not agreed and aligned to a single pure spec for these control designs, and some offer various button types, where only the visual design is different, but functionally identical - this would allow different design expressions, without duplication.
- It would address some of the concerns that have been expressed about the new direction the controls have moved towards with Windows 10X, and trying to make the controls align closer to other design systems for other platforms - these alternative designs are currently in use with other UI frameworks influenced by the Fluent Design System.
- It could potentially allow for easy style replacements by device type for Xbox styled controls, or for apps running as a GameBar widget - without having to dynamically load in ResourceDictionaries which could be a performance hit.
Scope
Capability | Priority |
---|---|
The alternative styles would meet accessibility concerns and be approved by Microsoft Design teams | Must |
Windows 10X Shell and Inbox apps which currently roll their own styles should move to setting this API as best practice | Should |
Whilst not in the forefront of my mind, there could be some kind of extensibility so a developer could create their own styles (Xamarin with Material Design perhaps) | Could |
The addition of this property or enum should not break existing apps | Won’t |
Important Notes
An initial thought would be some kind of enum which when set, will apply the alternative style to the control, and this could possibly be done at the App level, or inherited from a containing panel or page, as well as on an individual control. If that container panel also contains controls where this property does not apply, those controls should appear as normal.
public enum FormControlStyle
{
Accent,
Filled,
Outlined,
Ghost,
// TenFoot
}
<Button Content="Button text"
FormControlStyle="Outlined"
Width="240" Height="32" />
Open Questions
The easier it is to set this style, the better it will be for developers who would rather not re-template controls just to make a slight change based on preferences - but this could also be done with ResourceDictionaries. If that approach is taken, then ensuring those can be created by Microsoft and distributed in some way, with plenty of exposure - is the only way I can think of to try to maintain consistency.
Also I am not sure about using the word Style in the property name, as it could be confusing with the existing Style property. So deciding on what these “alternatives” should be referred to would need to be decided on.
The idea is the key thing, the implementation is up to the community and the WinUI team.
Related Issues
- #1054 Proposal: Define and implement distinct button styles, outline, fill, and ghost
- #82 Feature Proposal: Form Control
- #2233 Discussion: More default and consistent button styles?
- #2092 Inconsistent design with native controls
- #1258 New standard styles for system controls is a step back
- #930 Proposal: Default button concept
- #698 Discussion: Xbox Next: Will it use XAML, should WinUI 3.0 have built in support for templates and styles?
Issue Analytics
- State:
- Created 3 years ago
- Reactions:11
- Comments:10 (7 by maintainers)
Top GitHub Comments
I’d go for the latter, so that the controls are still recognizable as a CheckBox/RadioButton.
Thanks for the writing up the proposal! My only concern is with the ghost variants of the radiobutton and checkbox: removing the borders are a pretty big usability flaw IMO. I think those need to stay because the controls are now pretty much unrecognizable.