Page MenuHomePhabricator

Use text color instead of opacity to style icons
Closed, ResolvedPublic

Description

In wikimedia-ui-base, we have:

@opacity-icon-base:               0.87; // = `#222` on `background-color: #fff`, closest to `#202122`
@opacity-icon-base--hover:        0.74; // = `#424242` on `background-color: #fff`, closest to `#404244`
@opacity-icon-base--selected:     1;
@opacity-icon-accessory:          0.67; // = `#555`, closest to `#54595d` on background-color `#fff`.

According to the comments, these opacities are meant to mimic colors from the color palette when applied to pure black (#000) icons. However, WVUI uses SVG icons with configurable colors, so it would be relatively easy to use actual colors here instead.

I propose we:

  • Remove the iconColor prop from the Icon component
  • Always use currentColor in the SVG output by the Icon component
  • Have callers control the icon color using CSS (by setting the text color) instead
  • Replace existing opacity rules applied to icons with color rules
  • Define @color-icon-base etc analogous to @opacity-icon-base etc

My main open question is how we should handle the default icon color (#202122, AKA @wmui-color-base10). We could:

  1. Leave it up to callers to apply the correct text color to their icons
    • It would be easy to forget to do this, and accidentally end up with pure black icons
    • Components that use standalone icons would have to include color: @color-icon-base; rules for their icons, duplicating this rule all over the place
    • In places where icons are used as part of text, their color wouldn't need to be styled separately, because the text will already have a color applied to it (which is typically also #202122)
  2. Set color: @color-icon-base; as a default CSS rule in the Icon component
    • Callers wouldn't need to do anything to get the default icon color
    • In places where icons are used as part of text, their color would need to be styled separately, because the icons wouldn't inherit the text color
    • Components that change the text color in their slots (e.g. progressive/destructive buttons) would have to be aware of icons, and write CSS that targets any icons that may be put in their slots to separately override their colors, because the text color rule wouldn't inherit

Event Timeline

Change 682197 had a related patch set uploaded (by Catrope; author: Catrope):

[wvui@master] [icon] Remove iconColor prop, control color with CSS instead

https://gerrit.wikimedia.org/r/682197

The attached patch proposes an implementation using approach #2 from the list above. I'm not 100% confident that this is the right approach, but it seemed like the one with the fewest downsides to me. Eager to get feedback on this.

Hmm, quick skimming feedback: I'm not fully convinced that currentColor is covering all the use cases (necessary). We still have quite a number of exceptions, both on interactive element mixes of labels and connected icons and purely informative icons.
Will look into the patch next week to better understand what and where you propose to go.

The patch already supports overriding and sane defaults.

image.png (620×1 px, 92 KB)
comes to my mind as most prominent component with most obvious differentiation of surrounding text to icon.

I think 2. makes most sense. Provide the correct default and relief callers to considerate this detail. Themes could then use a different variable value to get another starting color.

Change 682197 merged by jenkins-bot:

[wvui@master] [icon] Remove iconColor prop, control color with CSS instead

https://gerrit.wikimedia.org/r/682197

After comparing current OOUI component icon coloring logic, it seems feasible to go (and try) this path as sane default with simple ability to override in CSS.
That allows to satisfy needs as in Message component shared above.

Was shortly thinking if a combination of an iconColor prop overruling currentColor would make sense, but SVG's color (as long as it's single color icons) should be the same value setting place like text color and that's CSS.
Moreover that would open up better theming abilities like dark mode, as all modifications would live in CSS.

Volker_E claimed this task.

Change 697700 had a related patch set uploaded (by Catrope; author: Catrope):

[mediawiki/core@master] Update wvui to 0.2.0

https://gerrit.wikimedia.org/r/697700

Change 697700 merged by jenkins-bot:

[mediawiki/core@master] Update wvui to 0.2.0

https://gerrit.wikimedia.org/r/697700