-
Notifications
You must be signed in to change notification settings - Fork 746
Description
In #5782, I discussed how we need ways to extract individual components so that authors can do truly custom things with colors.
While the Relative Color Syntax (RCS) offers maximum flexibility when it comes to a single color, we still don’t have a way to generate colors from color channels of more than one color. E.g. the hue and chroma of colorA and the lightness of colorB or the color of colorA and the alpha of colorB (didn't we have a CSS WG resolution that needed this?). The old syntax of color-mix()
could do some of that, but in a rather confusing and awkward way, so we had decided to axe it in favor of a future syntax to cover these use cases.
Early thoughts about this centered around having separate functions (e.g. lch-hue()
), possibly added on a use case basis.
However, I now think we should instead introduce a single color-extract()
(name TBB) function that extracts any color component, from any color space.
Potential syntax could be color-extract(<color-space> <component> from <color>)
. Return value is identical to the value of <component>
in the corresponding color function's RCS.
Reasoning:
- Return values, color space ids, and component names are all well defined already by existing syntax, so incremental implementation and spec effort would be relatively small
- The main argument against a generic function is its verbosity, but given that all common use cases are covered by RCS and
color-mix()
, this is reserved for the niche use cases, which could use more verbose syntax. - Since all components of this syntax refer to existing tokens, the syntax is automatically updated for new color spaces, or even custom ones.