Button component associated colors are inconsistent. about primitives HOT 2 CLOSED

Yeah, the button colors went through many iterations recently:

1. Component refresh (pre color modes)
2. Color modes V1
3. Color modes V2

So it might be a good idea to take a closer look at the button colors to see if they can be improved or aligned to the system more.

With this issue, I wonder if it possible to either

• Get rid of the btn component colors and directly use functional color variables. OR
• Make the btn component colors robust and work for all scenarios.

Maybe it needs to be a combination of both. Especially for the btn.primary it was hard to use functional/global variables because these "green" buttons became somewhat iconic and almost part of the GitHub brand. And at the same time they need to be accessible which is harder to do with green. /cc @auareyou

Another tricky part is that for things like hover/active/selected states, the difference should be minimal compared to the default state. And using functional/global variables might not work for these cases because the difference is too big. I think @mperrotti brought up a similar issue when working on the states for ActionList?

So currently color functions like darken() are used to get a new color that is just a tiny bit different. Using alpha() would be another alternative.

So yeah, we could see if any of the functional/global variables would work, but my guess is that we still need a few colors specific to buttons and all their different states.

from primitives.

This came up in primer/view_components#1712. A nested Counter in dark_high_contrast has low contrast:

Possible options for dark_high_contrast:

• Either add a new --color-btn-counter-fg variable that is light
• Or updating --color-btn-counter-bg to be light

from primitives.