Experimental CSS color-mix

[siriwatknp]

Motivation

• To let consumer control their preferred color space
• Open to more color customization with CSS color-mix
• Improve performance by removing the JS runtime overhead
• Reduce JS (to be removed in the future) by adopting new CSS features
• To have a better debugging experience, see how the color is calculated from another color

Problems

1. The supported color customization is limited to #nnn, #nnnnnn, rgb(), rgba(), hsl(), hsla(), color()
2. The calculation of alpha, lighten, and darken causes the runtime performance on every render

Potential fixes

• Add support for CSS color-mix() in theme palette #40104
• [link] Links using color="inherit" don't use the proper color for the text decoration #36007
• [colorManipulator] Defining a css theme variable with rgb() and var() not working  #37901
• button css wrong when i use css varibles #43540

Proposal

The values created by alpha, darken, lighten functions in the theme and components will be replaced by CSS color-mix , e.g.

- background: #ff2435
+ background: color-mix(in srgb, #4430d, #fff 50%)

The consumer can enable the feature from the theme by providing a new field experimentalColorMix (it works with/without CSS theme variables feature)

createTheme({
  experimentalColorMix: 'srgb' | 'hsl' | '...supported color space for CSS color-mix',
})

POC

Preview (open the Devtool): https://deploy-preview-43942--material-ui.netlify.app/experiments/material-ui/color-mix/
PR: #43942

Warning

The result of color-mix() will be slightly different from the darken and lighten color manipulator functions.
Also, using different experimentalColorMix values could produce different result too.

Side effect

Because color-mix cannot generate a contrast text, the usage of palette.getContrastText() will have to be replaced with plain value (could be from the contrastText token or the var(--mui-palette-text-primary))

Implementation

The feature must be an experimental API because v6 supports iOS 15.4 which does not work with color-mix yet.

Based on the prior POC, the color-mix is used when CSS theme variables feature is enabled but it should not limited to CSS variables. I propose to be independent of CSS variables.

Theme tokens

For the palette creation, when the flag is enabled, the light and dark (if not provided) will be generated using color-mix

createTheme({
  experimentalColorMix: 'srgb',
  palette: {
    primary: { main: 'var(--external-primary)',
  }
})

console.log(theme.palette.primary.light) // color-mix(in srgb, var(--external-primary), #fff 20%)
console.log(theme.palette.primary.dark) // color-mix(in srgb, var(--external-primary), #000 30%)

Components

The basic approach is to add ternary condition like this:

// IconButton.js
backgroundColor: theme.experimentalColorMix ?
  `color-mix(in ${theme.experimentalColorMix}, (theme.vars || theme).palette.action.active ${theme.palette.action.hoverOpacity * 100}%, transparent)
  : theme.vars
	  ? `rgba(${theme.vars.palette.action.activeChannel} / ${theme.vars.palette.action.hoverOpacity})`
	  : alpha(theme.palette.action.active, theme.palette.action.hoverOpacity),

But I think it will be hard to maintain and increase a lot of lines in the codebase.

A better approach is to create new functions to the theme to abstract the logic from the components:

backgroundColor: theme.alpha(
	(theme.vars || theme).palette.action.active),
	(theme.vars || theme).palette.action.hoverOpacity),
)

The theme.alpha will take care of the result based on CSS theme variables and Color mix features.

Codemod

A codemod will be created to transform the codebase and also published for the consumers (e.g. MUI X and Toolpad) to reuse the same patterns.