Light/dark color variants

[gadenbuie]

In implementing Shiny's brand.yml theme adapter, I've found a few places where allowing light/dark for a color would open the door to improving the light and dark mode choices.

color:
  foreground:
    light: "#111111" # (black-ish color when in light mode)
    dark: "#fafafa" # (white-ish color when in dark mode)
  background:
    light: "#FFFFFF" # (bright white in light mode)
    dark: "#222222" # (slightly brighter black in dark mode)

Similarly, all color and background-color fields in typography. For example, it's useful to have different colors for inline monospace or links in dark mode than in light mode.

Background from Bootstrap

The way that dark mode works in Bootstrap is that the theme colors – primary, secondary, info, success, warning, danger, light, dark, white, black – are all stable across light and dark mode.

In light mode, Bootstrap uses $gray-900 (foreground, one step up from $black) and $white (background) and in dark mode it uses $gray-100 (foreground, one step down from $white) and $gray-900 (background).

Note that they do not map $foreground: $white and $background: $black and then just flip them in dark mode. In both cases, that end up with contrast that's a bit too harsh. brand.yml doesn't directly do this mapping either, but it's easy to do when you put white and black into color.palette. In Shiny, we do map color.foreground to $body-color and $body-bg-dark and color.background to $body-bg and $body-color-dark (i.e. flipping foreground and background in dark mode).

This works okay but it'd be nice to be able to customize these two colors.

Placement of light/dark fork

In general light means "when in light mode" and dark means "when in dark mode". I'd prefer to have light and dark be properties of individual fields, i.e. it's easier use when brand.typography.link.color is possibly a BrandLightDark class than it is if you have to account for the split higher up.

It's also easier to specify a color for both modes when light/dark is closer to the field. For example, if we decided to make the entire color palette support light/dark modes, you could still write this

color:
  palette: {...}
  foreground:
    light: "#111111"
    dark: "#fafafa"
  background:
    light: "#FFFFFF"
    dark: "#222222"
  primary: "#6F42C1" # always purple

instead of this

color:
  palette: {...}
  light:
    foreground: "#111111"
    background: "#FFFFFF"
    primary: "#6F42C1"
  dark:
    foreground: "#fafafa"
    background: "#222222"
    primary: "#6F42C1"

On the other hand, in the above YAML, where light and dark could take an entire color theme, it's easier to think about what each color means. color.light.foreground is clearly the foreground color in light mode, whereas color.foreground.light is easily confused with "a light foreground color", which is the opposite of what you'd want to put there.

That said, I still prefer the localized light/dark variants, which we can support with documentation, i.e. "foreground color in light mode, typically close to black".