Repository navigation
[Proposal] Add filled buttons as per material 3 guidelines #104357
Description
Activity
- changed the title
[-][Proposal] Add filled buttons as per m3 guidelines[/-][+][Proposal] Add filled buttons as per material 3 guidelines[/+]on May 23, 2022 These were originally considered, but as they were just a minor variation of the
TextButtonit seemed prudent to be conservative on adding new API when they may not be needed. Two options for an API for Filled and FilledTonal buttons would be:- Create
FilledButtonandFilledTonalButtonsubclasses ofButtonStyledButton. - Create
TextButton.filledandTextButton.filledTonalfactory constructors.
The first would also require new
FilledButtonTheme/DataandFilledTonalButtonTheme/Dataclasses to be consistent with the existing button classes. This seems like a lot of new API for such simple variants.The factory constructors would certainly be a smaller API addition, but are not as discoverable (although I guess more so than the examples we have in the docs 😄).
If people feel strongly about this, we will certainly consider it. We are just trying to keep the API as small as possible for maintenance. Especially in areas that the Material Design spec tends to change frequently.
- Create
I understand the need for keeping the api small, especially since there are other variation (like error, tertiary,..), which I'm in favor of supporting too (but I don't have to maintain the buttons 😊). If the main color scheme was handled with factories, it would be easier on the user that respect the m3 specs.
I do not think the factories should be added to textbutton though, as this would prevent other variations:
FilledButton,FilledButton.error,FilledButton.secondary,...The factory constructors would certainly be a smaller API addition, but are not as discoverable
If you need a "error" button, is it the errorContainer or error color that should be used for background ? The user should not have to think, with flutter furnishing the right stylings that would be m3 compliant. The factories lets you do that.
Any css library / component library worth its salt has its own system to quickly change button colors based on their meaning too. Here I find it's a manual step that could be eliminated.
Don't get me wrong, I don't want this to be added if you think it's a bad decision, you know best, I'm just furnishing my outsider view.
Reacted by Rydmike and Max YablochkinI agree with @cedvdb it would be beneficial to have these buttons in the framework.
Rationale:
- They are in the M3 spec.
- Since they are, presumably devs/designers will want to use these button designs in M3 designed apps, very frequently.
- But now all devs will be forced to create their own small custom widgets to do so, just to replicate these M3 designs. It would be globally more productive and beneficial for the SDK to provide them out of the box.
Sure, somebody (many) will make small simple packages to provide these missing buttons, but many of us are cautious about adding small widget packages that can as well be replicated with a few lines of code via custom widgets, so most will probably do that instead, make their own versions. End result, lots of custom variants of these buttons will exist in code bases, some might not even implement their design correctly, even if that was their ambition.
Even if they are simple enough to do yourself, I would not rule out the value of providing them out of the box to provide a smooth and easy M3 design experience with Flutter. All UI widgets do not have to be complicated, some can imo be simple to make it easy fulfil the M3 design and make it even more joyful to build lovely M3 apps.
The same btw applies to the Outlined Card. It is in the M3 spec, but at least last I looked you have to make it manually with tedious Shape when you want to use one. I would consider adding a convenience constructor for it as well.
This is a tough call. The lifetime of the design idea (consider the "mini" FAB or the Stepper) is often much shorter than that of the API. On the other hand, it would certainly be nicest if we provided widgets for each distinct M3 component.
We talked about providing example widgets, like TonalButton, that could be just pasted into apps. That might cut down on the number of variants out there, but it would not be quite as "smooth and easy" and including the widget directly.
Thanks @HansMuller, yes I saw in the M3 sample/demo app how the missing M3 tonal button, as well as outlined and filled card styles were made as well.
When I first found that app I thought, oh have these M3 components now been added to the framework, but nope they were just custom designs using the base one to achieve the M3 design from the base version.
It takes a bit away from the convenience of being able to just define the theme and get components that use it and you can produce M3 widgets with dedicated constructors for the distinctly presented M3 components in the guide.
It's not that they are particularly difficult to make from their base version, just that since they are so prominently used and presented in the M3 guide, it does feel like Flutter is "missing" them.
Sure I can understand the maintenance rationale for not having them included too and just giving examples of how to make them. Still this leads to everybody then copying that and adding them as small custom widgets to their code base. This works too, but imo it feels like it would be more globally efficient to offer out of the box constructors for them and offer a nicer dev experience too, especially to newcomers to Flutter and perhaps to old ones too that have not had time study and dissect the M3 design guide.
Sidenote
BTW concerning the FAB, last I looked you cannot recreate its M3 behaviour with its component theme. With that I mean, suppose you want to make themed FAB versions that have slightly different border radius than the M3 style, but still so that the mini has less border radius than the normal sized one, that has even less border radius than the super big one. Last I looked, if you make component theme for it with border radius, you can only have one Shape and border radius that is then then same for all its different constructors, this does not look good, so you have to stick the M3 border radius or go back to circular.
It is quite frustrating when you cannot replicate via themes what some components have and do as built in default behavior when their component theme props are null. Could it be considered to no make theming limitations like that? I will double check in master that this is still the case with the FAB and open a separate issue for this if it is.
SnackBaris another component with this theming problem that come to mind directly. It should have different shape styles based onSnackBarBehaviorfixed/floating, if you want to modify its defaults styles for fixed/floating via a theme you can, but then they both use the same themed shape. You would need a different themed shape for the two styles, like you need different border radius (Shapes) theme styles for the different FAB styles.This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.- locked as resolved and limited conversation to collaborators
on Sep 8, 2022
Proposal
Add factories on ElevatedButton for FilledButton and FilledTonalButton or add factories to an existing button to respect m3 guidelines. I understand those were not added because then what about when the background needs to be an error background ? tertiary ? etc. I believe however that a few factories could help here.
relevant: #99022
use case
Going from a design using the material 3 kit on Figma to flutter should be seamless.