[RFC] Color prop for components where it can target multiple areas (content, background)

[bmdalex]

[RFC] Color prop for components where it can target multiple areas (content, background)

Problem description

Let's take the example of Label component. The color prop for a label can have at least 2 targets:

• the color of the text
• the color of the label's background

How should we create props for this type of components?

Solution 1

Always pick an area that color goes to and change other colors using variables.

e.g.:
for Label component, the color prop changes the background color, and we're using color variable to change the text color:

API:

<Label color='red' variables={{ color: '#fff' }} />

will create a label with white text on red background.

Note: We should rename color variable to textColor to avoid confusion.

+:

• simple solution

-:

• color variable receives a CSS color and does not go through our color palette mechanism (we'd need to implement that)
• confusing that we use a prop and a variable to set colors for areas of the same component

Solution 2

color prop receives an object as value in order to identify the area of the component it sets color for:

e.g.:
for Label component, the color prop changes the text and background colors, so we'd have something like this for the color prop:

type LabelColorProp = {
  text: string
  background: string
} | string

API:

<Label color={{ text: 'red', background: 'green' }} />

will create a label with red text on green background.

<Label color='red' />

will create a label with red text on background with default color.

+:

• more intuitive than Solution 1
• leverages the color palette mechanism to get correct hex codes for colors

-:

• complex API
• complex solution

Solution 3

• always pick an area that color goes to
• change other area colors automatically or using a color scheme: refactor(Divider): remove type prop #558 (comment)
• accept overrides using variables

e.g.:
for Label component:

• the color prop changes the background color and determines what text color complements the text color (same as SUIR) based on a tool / predefined color scheme (see: refactor(Divider): remove type prop #558 (comment))
• we're using color variable to override the text color set by color prop automatically when setting background color

API

<Label color='red' />

will create a label with light colored text that fits best on a red background color.

<Label color='white' />

will create a label with dark colored text that fits best on a white background.

<Label color='white' variables={{ color: 'yellow' }} />

will create a label with yellow text on white background.

+:

• leverages the color palette mechanism to get correct hex codes for colors
• simple API

-:

• complex solution
• error prone (wrong colors in scheme) and hard to maintain
• can get confusing since variables would override props, we can consider other override mechanisms

[bmdalex]

@levithomason
@kuzhelov
@mnajdova
@layershifter
@miroslavstastny

can you guys express your thoughts?

[miroslavstastny]

From consumer's point of view I vote for Solution 3 - it's theme's responsibility to match correct foreground to the background.
More importantly, it's also up to the theme to decide what the color prop means - for one theme, it can mean to set background, for other theme to set border color...

[bmdalex]

Agreed, thanks @miroslavstastny

How would you handle overriders?

Let's say a user really wants to set a different color for foreground than the one set by color prop, while maintaining the background color set by color prop. How would that work?

Solution 1

One idea is to make color related variables higher priority than color prop and retain the existing variables as some default values;

e.g.

<Label  />

creates a label with grey text on light grey background (default)

<Label color='red'  />

creates a label with very light text on red background

<Label color='red' variables={{ color: 'yellow' }} />

creates a label with yellow text (override) on red background.

Solution 2

Another idea is not to handle this at all and the user can just use color variables for this case and omit color prop entirely:

<Label color='red' variables={{ color: 'yellow', backgroundColor: 'red' }} />

creates a label with yellow text (override) on red background.

Note:

For this to work we need to introduce the color palette mechanism for color variables values as well, what do you think? @layershifter

[layershifter]

What does Bootstrap?

https://getbootstrap.com/docs/4.1/components/alerts/#examples

What does SUI?

https://semantic-ui.com/collections/message.html

What does Bulma?

https://bulma.io/documentation/elements/notification/

[layershifter]

I will vote for Solution 1. We need to create a color schema and allow define its parts via variables, this looks like nearest Starbucks 😺

[bmdalex]

@layershifter - thanks for the input

How would you see this color schema work for a Label let's say where the color prop needs to color both background and textColor / foreground (whatever we want to refer to it as)?

According to your comment about what other libraries do (#636 (comment)) we might want:

<Label color="red" />

to create one of these (or whatever the theme wants for the exact shades):

a Label with light textColor on darker red background (SUI)	a Label with darker textColor on lighter red background (Bootstrap)

As I see it we might want to reuse our mapping for color variants and do something similar to what I did here:

https://github.com/stardust-ui/react/pull/647/files#r243257825

colors: mapColorsToScheme(siteVars, colorVariants => ({
  color: colorVariants[50],
  backgroundColor: colorVariants[500],
})),

and use it to set styles.

However, it looks like this simple variant <-> color mapping is not generic enough for all colors; some of the variants for background (post orange, yellow) are too light to use the matching variant for foreground as you can see in the screenshot below:

My question is:

Does this mean we need to define this color schema for every color or choose better variants? Any ideas to unblock this?

[layershifter]

Does this mean we need to define this color schema for every color or choose better variants?

My opinion: some colors should be manually mapped (if your palette is not great :) ), in development mode we can throw warning about unaccessible colors in scheme.

Can you capture a screenshot with a palette from default theme?

[bmdalex]

Here's the screenshot (still not great for orange and yellow):

some colors should be manually mapped (if your palette is not great :) )

1. Do we really want to do all this manually?
2. Would it be at component level?

What about defining a foreground and background colors that works for any of the variants for each color? At least it's less work... Something like:

export const naturalColors = {
  // ...,
  postOrange: {
    50: '#FDF6F7',
    100: '#FBF2F3',
    200: '#FAEEEF',
    300: '#F9ECED',
    400: '#F8E9EA',
    500: '#F7E5E6',
    600: '#F7E2E4',
    700: '#F5DEE0',
    800: '#F5DBDD',
    900: '#F3D6D8',
    foreground: '#???', // some hex code that works as foreground for any variant
    background: '#???', // some hex code that works as background for any variant
  },
}