-
-
Notifications
You must be signed in to change notification settings - Fork 32.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[SpeedDialAction] pass through button color props to speed dial action button #12986
[SpeedDialAction] pass through button color props to speed dial action button #12986
Conversation
@itskibo Rather than remove the default color, it would be good if you could update it to match the Material v2 spec: It also adds a backdrop, but that's a subject for another PR. You can still override the color with the button className prop. We could think about adding a |
@mbrookes I believe that overriding the color through the className props is counter-intuitive, if we can use the ButtonProps instead. Unless people plan on using custom colors outside of their primary and secondary color, which I highly doubt, I believe that allowing the color from the ButtonProps to pass through correctly is the way to go. Furthermore, I will quote what you said on the related issue: There is no need to add a separate Regarding the backdrop: |
Then you would need to disable the default color when this is supplied. I don't know, it feels kinda kludgy.
Yes, as in the screenshot. |
I believe the default color has been removed in my branch. Both the background color and the color are now based on the button component itself. |
|
The specs on the speed dial actions are not directly defined, therefore I believe that we can follow the specs of the mini fab component, as they look like one and the same. In doing so, we can allow the passing through of the color from the button props, and leaving the rest on whichever the developer pleases, whether it be from overriding the theme, or setting a className, or having it as the default of the button itself. I see no reason to not implement this change, as this is following the current specs of the (mini) fab, aside from the backdrop. |
The contrast with the background is low now (slightly more so with this PR), it will be worse with a backdrop. Let’s benchmark what others are doing. |
Decided to see if I could find some implementations of the speed dial actions in other projects, and so far I found a few that allow/have custom colors for the speed dial actions: kumar529/Ng2FabSpeedDial example - repo Since the official specs don't mention anything about what color the action buttons should be, I see no reason to not implement this for the time being. Sure, the contrast may become an issue for some, but they should be able to override the colors in the theme itself, right? |
One issue is that the FABs have the wrong color by default. It should not be some "arbitrary" faded color but whatever color variant is chosen. Depending on the expected background users should either choose So I think it is correct to not hard-code the color via css but let users pass it via |
That's always easy to say for me to say since I've never worked closely with v1 and I never found a comprehensive changelog for the specification. |
Vuetify FAB has colored action buttons, and I do agree with @eps1lon that the default colors should be changed to match the v2 spec, but that is not what this PR is for (or the issue related to this PR). This PR is solely for allowing colors from the button props to pass through correctly to the speed dial actions, not refactor it to the v2 specs. I believe that should be a separate issue, as it also adds a backdrop. |
Wouldn't that have been nice! As it is, we are left to discover what has changed through these sorts of conversations. The difficulty we will have in updating the FAB relates in part to your color prop proposal. It seems that we should support both grey on white and white on black in addition to primary and secondary, (and possibly even an Avatar FAB). But which (black or white) should be the default, and what should the value for the color prop be for the other? The other difficulty will be that changing the default color of the FAB is that it is a (visual) breaking change. I know @oliviertassinari has been okay with that in the past, but we have a more clearly defined strategy on breaking changes now, and this would be a less than subtle one. |
But in doing so removes the logic that is used to apply colors based on the color prop, which is a retrograde step. |
Okay I am legitimately confused right now. Before this change, it was impossible to specify whether the After this change, it is now possible to set the color to primary and secondary and have it actually pass through and apply the color (as you would expect). If the color is omitted, it defaults to the background color of the There is no "removing" logic in this PR, as far as I can see, so I am not sure what you are getting at right now. |
Huh, thought I replied this this way back when... anyway, yes, sorry, I "misspoke". I should have revisited the code before commenting. "Removes the default FAB color rather than adding the logic for selecting colors via a color prop." Either the default should be updated, or if that's a matter for another PR, it should be left as is in this one for the time being, which I believe dictates a different approach for this PR. Since this PR targets |
Resolves #12830.
Changes:
I do believe the description in the docs can be better, but currently lacking any inspiration, so feel free to change that if you wish! 😄