Styling controls can be a pain and time consuming. In my opinion it would be great if WinUI would include more default styles for common button types (the FluentUI (a.k.a. FabricUI) toolkit contains more default styles that are quite common in apps). Default styles that are included in this project are:
For some button control styles (like the SplitButton) the AccentButtonStyle does not work. Would be great to have consistent styles for all button types (where possible).
It would be great to have also the following types:
A style that only shows the content of the button. On hover would change the color of the content.
Text only:
Icon only:
A style that turns every button in a perfect ellipse. FontFamily set to Segoe MDL2 Assets by default since it works best for icons?
A style for creating secondary buttons. The background show represent the background with only a border.
The Fluent UI toolkit contains great examples of different button types.
https://fluentsite.z22.web.core.windows.net/components/button/definition
This is kind of related to a proposal made, based on comments by @chigy and work done by the Shell team for more button visual styles. #1054
Maybe this can all be wrapped into it, for the Accent | Filled/Default | Outlined | Ghost button styles.
and this could probably extend to most other form controls, which could handle the concerns in #1258
@mdtauk Oh, missed that one. Yes, they are very similar in terms of ask :)! I think there's room for improvement here without too much work!
Circle Button style and Icon Only buttons feel like they could be a combined ask. The icon only square button is pretty much an AppBar Button without the label.
The Circle Button could also come in Accent | Filled | Outlined | Ghost styles - rather than making them different button types.
For some button control styles (like the SplitButton) the AccentButtonStyle does not work. Would be great to have consistent styles for all button types (where possible).
The problem is that for the style to work on a control, the types have to "line up", that's why AccentButtonStyle does not work for SplitButtons.
@ranjeshj Should we add a AccentSplitButtonStyle to fill that gap or was there a reason that was not added?
@niels9001 Are there any other styles missing beside AccentSplitButtonStyle? 馃槉
Now here my 2 cents on the proposed button (styles):
Love it! This is currently to "hard" to achieve and seems something people often need.
Why couldn't you set the CornerRadius of the default button to the appropriate values?
I see multiple problems here:
None the less great idea @niels9001 ! And as always great mock ups @mdtauk !
For some button control styles (like the SplitButton) the AccentButtonStyle does not work. Would be great to have consistent styles for all button types (where possible).
The problem is that for the style to work on a control, the types have to "line up", that's why AccentButtonStyle does not work for SplitButtons.
@ranjeshj Should we add a AccentSplitButtonStyle to fill that gap or was there a reason that was not added?
@niels9001 Are there any other styles missing beside AccentSplitButtonStyle? 馃槉Now here my 2 cents on the proposed button (styles):
QuietButtonStyle
Love it! This is currently to "hard" to achieve and seems something people often need.
CircleButtonStyle
Why couldn't you set the CornerRadius of the default button to the appropriate values?
TextButtonStyle
I see multiple problems here:
- Filling an Icon on hover is nothing that can purely be done using a single icon provided
Accessibility wise we are problem running into issues here:
- Where are the bounds for hit testing?
- What differs the button from a normal link?
- "Where is the button on the page?" meaning it's hard for people to find the button in some scenarios
None the less great idea @niels9001 ! And as always great mock ups @mdtauk !
@chingucoding I think in general, all button styles should be available for all button types. For example: AccentButtonStyle should be available for Button, SplitButton, DropDownButton, RepeatButton, SplitButton. This would bring consistency and easy of use :)!
RadioButton, ToggleButton and ToggleSplitButton can probably be excluded..
I see your point, and yes - maybe it is redunant due to the CornerRadius capabilities. On the other hand, it would make it easier to use and only applying a style would make it more effortless.
There is a difference between a HyperLinkButton: those are generally accepted as URLs that would launch the browser or different application (hence the underline). It's commonly used as a tertiary action (like dialogs where you have an OK (Primary / AccentButtonStyle), Cancel (Secondary / DefaultButtonStyle) and Settings (Tertiary / TextButtonStyle). For reference, the Microsoft Store and Settings app are using them all over the place:
Regarding your (accessibility) concerns:
I think these styles should be applied to all the form controls, so buttons, split buttons, checkbox etc
@chingucoding I think in general, all button styles should be available for all button types. For example: AccentButtonStyle should be available for Button, SplitButton, DropDownButton, RepeatButton, SplitButton. This would bring consistency and easy of use :)!
RadioButton, ToggleButton and ToggleSplitButton can probably be excluded..
Maybe this is something that should be discussed in it's own issue. Would you like to create that issue or should I do that?
CircleButtonStyle
I see your point, and yes - maybe it is redunant due to the CornerRadius capabilities. On the other hand, it would make it easier to use and only applying a style would make it more effortless.
I think we are talking about a few characters difference in definition (Style="{..}" compared to CornerRadius="...") so it's not really less effort in my opinion.
TextButtonStyle
There is a difference between a HyperLinkButton: those are generally accepted as URLs that would launch the browser or different application (hence the underline). It's commonly used as a tertiary action (like dialogs where you have an OK (Primary / AccentButtonStyle), Cancel (Secondary / DefaultButtonStyle) and Settings (Tertiary / TextButtonStyle). For reference, the Microsoft Store and Settings app are using them all over the place:
I think the control you probably should use in that case is the HyperlinkButton instead of styled button. In the XCG, we use that to link to different pages:
Filling an Icon on hover is nothing that can purely be done using a single icon provided => Yes, you are right (bad example :)). I think changing the MouseOver Foreground brush would suffice.
Where are the bounds for hit testing => Bounds for hit testing can be the same as the HyperLinkButton (or default button?)
Problem is that the user doesn't really know. If you use the hitbox of Hyperlinks, it feels like a link. If you use the hitbox of a regular button, users are unsure where the hitbox really is.
What differs the button from a normal link? => No underline, removing the expectation to the user that it would launch the browser or different app
You could remove it or add it, but fair point that would be difference when using normal styles.
"Where is the button on the page?" Maybe the default color could be the AccentColor?
That sounds reasonable. And on hover become lighter or darker then? Would that meet all contrast requirements, after all there is not much room compared to white/black.
@chingucoding I think in general, all button styles should be available for all button types. For example: AccentButtonStyle should be available for Button, SplitButton, DropDownButton, RepeatButton, SplitButton. This would bring consistency and easy of use :)!
RadioButton, ToggleButton and ToggleSplitButton can probably be excluded..
Maybe this is something that should be discussed in it's own issue. Would you like to create that issue or should I do that?
@chigy Had an issue discussing this, so I am not sure if making a new issue is likely to get consideration, but you are welcome to try to raise awareness if you think it is a worthwhile notion.
The Shell team asked for these "ghost" styles, and many inbox apps use them - so I guess its about formalising them, and expanding the idea in the controls themselves - instead of using app.xaml styles.
@chingucoding Good point, maybe it should just be a HyperlinkButton with a 'no underline' style. In terms of behavior it can be very similar.
I think this is a perfect example where a text only button makes sense. Here it is achieved by setting a TextBlock as content of the HyperlinkButton.
@chingucoding Good point, maybe it should just be a HyperlinkButton with a 'no underline' style. In terms of behavior it can be very similar.
I think this is a perfect example where a text only button makes sense. Here it is achieved by setting a TextBlock as content of the HyperlinkButton.
@niels9001 , FYI, this is already supported by HyperlinkButton
https://docs.microsoft.com/en-us/windows/uwp/design/controls-and-patterns/hyperlinks#hyperlink-underlines
@chingucoding I think in general, all button styles should be available for all button types. For example: AccentButtonStyle should be available for Button, SplitButton, DropDownButton, RepeatButton, SplitButton. This would bring consistency and easy of use :)!
RadioButton, ToggleButton and ToggleSplitButton can probably be excluded..
Maybe this is something that should be discussed in it's own issue. Would you like to create that issue or should I do that?
@chigy Had an issue discussing this, so I am not sure if making a new issue is likely to get consideration, but you are welcome to try to raise awareness if you think it is a worthwhile notion.
The Shell team asked for these "ghost" styles, and many inbox apps use them - so I guess its about formalising them, and expanding the idea in the controls themselves - instead of using app.xaml styles.
1054 Maybe @chigy could weigh in and provide some guidance?
@mdtauk , it might be good to have that as a separate issue to track introducing these styles for c controls other than buttons because there's discussion about RadioButton style that maybe resolved if we do this.
@chigy I'll write one up a little later "consistent alternative form control styles"
@chigy @chingucoding