Feature request: Automatically set button state colors

[ethanroday]

EDIT: I should clarify that these screenshots are from the Fluent UI experiment, but the overall question still stands.

---

Sometimes you need a one-off button that has a color outside of your main theme.
It would be great if there was an easy way to set the color for the default button state and have all of the other colors set automatically. As such, if I have the following code, here's what I see:

<DefaultButton className={[ColorClassNames.redBackground, ColorClassNames.white].join(" ")}>
  Don't Click This!
</DefaultButton>

Default:

Hover:

Pressed:

---

I can partially solve this by using some additional members from ColorClassNames, but the pressed state is still a little weird, and it would be great not to have to have this much boilerplate:

<DefaultButton
  className={[
    ColorClassNames.redBackground,
    ColorClassNames.redBorder,
    ColorClassNames.redDarkBackgroundHover,
    ColorClassNames.redDarkBorderHover,
    ColorClassNames.white,
    ColorClassNames.whiteHover
  ].join(" ")}
>
  Don't Click This!
</DefaultButton>

Default:

Hover:

Pressed:

[Vitalius1]

@JasonGore I believe this scenario will be supported by the Slots work you are doing. Correct me if I am wrong.

@ethanroday Fluent UI experiment? I am confused where is that? Also, I am more confused on how passing these strings as classNames you get different states. Isn't ColorClassNames just a bunch of hex color codes?

[ethanroday]

Fluent UI as in: https://fluentfabric.azurewebsites.net/#/overview
ColorClassNames is a set of class names that I found sort of by accident. The classes define text color, background color, and border color on both default and hover states.

[JasonGore]

I'm seeing a couple of different asks here:

1. Components should be able to take in one color and derive the others.
   • For example, hover should be equal to a slightly darker shade of default. (At least that's how I interpret this request.)
   • This doesn't have anything to do with Slots. It's basically saying components should develop a relation between colors that isn't in place now. However, I'm not sure if it will always hold as you can't easily say that hover is a slightly darker version of default, because then what do we do for inverted scenarios?
2. Easy access to button tokens and state to determine coloring from a consumer level.
   • My Tokens PR (Tokens: New Experimental Feature #7552) shows how Tokens can be used to affect button coloring based on tokens and state. See TeamsCustomizations.ts to see how this could be done using tokens and button state.

[Vitalius1]

@ethanroday I completely forgot about the @uifabric/styling package you are using in this example. I believe it is meant to port in TS everything Fabric Core is having in SASS.

As Jason said, it's somewhat incorrect to expect from specifying redBackground for the default state to automatically set a color for the hover state. What if someone decides to have for the hover state redDarkBackgroundHover (how you did above) and someone else decides to go nuts with greenBackgroundHover. I think these colors are meant to give you somewhat semantic meaning to a color and it's each consumer's choice on how to combine them.

As for the pressed state (and also focused), it's something that I think should be discussed with designers and added to the properties of ColorClassNames for each color. Today we only have these states for each color:
https://github.com/OfficeDev/office-ui-fabric-react/blob/04558fe11e54e6c0f1db85e14c32f65cfb1d502f/packages/styling/src/classNames/ColorClassNames.ts#L192-L197

But these should be added along with updating Fabric Core also. @mikewheaton do you know why we only have color classNames for background and border in default and hover states only. Where there any plans to add similar colors for focus and active states?

[mikewheaton]

@mikewheaton do you know why we only have color classNames for background and border in default and hover states only. Where there any plans to add similar colors for focus and active states?

I believe these were added to be equivalent to Fabric Core's color classes, which target only color and background-color (with a hover variant for each).

[Vitalius1]

Were there any plans or discussions on whether add or not add other states (focus/active)? It also has covered the border-color.

[mikewheaton]

No, there weren't any plans for focus/active classes.

[Vitalius1]

@dzearing @phkuo as package owners... is this something we would want to add? (meaning some additional states (focus and active) for each ColorClassName). I think this can quickly get out of control if taking into consideration how many variations should be added. At the same time, this is the equivalent of the ones we have in Fabric Core and it would be expected to add them there too for making them available in SASS.