Intent to Prototype: CSS color-mix function

487 views
Skip to first unread message

Kevin Babbitt

unread,
Jun 9, 2020, 6:44:37 PM6/9/20
to blink-dev

Contact emails

kbab...@microsoft.com

 

Explainer

https://www.w3.org/TR/css-color-5/#colormix

 

Design docs/spec

Specification: https://www.w3.org/TR/css-color-5/#colormix

https://docs.google.com/document/d/1ZU_-8U11lhCfGsqEEe4ayaKHjkgOyexAMh2ZVqTW8vM

 

TAG review

 

Summary

color-mix takes two <color> specifications and returns the result of mixing them, in a given colorspace, by a specified amount. For example, `color-mix(red yellow 40%)` produces a mixture of 40% red and 60% yellow.

 

Motivation

This new function will give designers greater flexibility when working with colors. One example is to create tinted variants of a single base color to form a design palette.

 

We also need this function to support a CSSWG resolution related to background-color in forced colors mode. The resolution calls for using color-mix to construct the used background-color from the rgb channels of the appropriate system color plus the alpha channel from the computed color.

 

Risks

Interoperability and Compatibility

- The syntax for color-mix is still evolving based on CSSWG discussion. Mitigation: The motivation for prototyping this feature now is an internal use case. We can defer shipping until syntax has stabilized.

- Blink does not yet support all color spaces recognized by color-mix. Mitigation: We will reject color-mix declarations for unsupported color spaces so that authors can feature-detect using @supports.

Firefox: No public signals

Edge: No public signals

Safari: No public signals

Web developers: No signals

 

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

 

Is this feature fully tested by web-platform-tests?

No Tests will be added as part of feature development.

 

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/5659115386830848

 

This intent message was generated by Chrome Platform Status.

 

j.j.

unread,
Jun 9, 2020, 7:35:00 PM6/9/20
to blink-dev


Am Mittwoch, 10. Juni 2020 00:44:37 UTC+2 schrieb Kevin Babbitt
 

- Blink does not yet support all color spaces recognized by color-mix. Mitigation: We will reject color-mix declarations for unsupported color spaces so that authors can feature-detect using @supports.


IMO there is no need for feature-detecting and @supports. A proper implementation should allow simple CSS fallback
color:red; color:color-mix(/*unsupported color space*/);
should be "red" or I'm missing something?

j.j.

Anders Hartvoll Ruud

unread,
Jun 10, 2020, 3:37:27 AM6/10/20
to j.j., blink-dev
 - Re. forced colors mode: I think on its own it's not enough to fix the background adjustment magic called for in the spec. But agree that it _might_ be a path towards it. E.g. if we also invent a keyword that resolves to the computed value of background-color, then maybe.
 - If I understand correctly, this will require that we store color-mix functions on ComputedStyle, similarly to calc() for <length-percentage> properties. If that's true, then:
 - I wonder if it makes sense to first make color keywords compute to themselves before attempting mix-color().
 - Is this useful without lab/lch? Honest question without any implication that it's not useful.
 - sgtm overall though, thanks for making a design doc up front.

 You're right, but then this means it would also work with @supports. :-) 

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/baa004f1-bcd9-41a1-92a9-6ed42b7fdccbo%40chromium.org.

Fredrik Söderquist

unread,
Jun 10, 2020, 5:44:27 AM6/10/20
to Kevin Babbitt, blink-dev
On Wed, Jun 10, 2020 at 12:44 AM 'Kevin Babbitt' via blink-dev <blin...@chromium.org> wrote:
The ED seems to be further along/better fleshed out here (and is what's referenced in the design doc): https://drafts.csswg.org/css-color-5/#colormix


/fs

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Rune Lillesveen

unread,
Jun 10, 2020, 7:46:05 AM6/10/20
to Anders Hartvoll Ruud, j.j., blink-dev
On Wed, Jun 10, 2020 at 9:37 AM Anders Hartvoll Ruud <and...@chromium.org> wrote:
 - Re. forced colors mode: I think on its own it's not enough to fix the background adjustment magic called for in the spec. But agree that it _might_ be a path towards it. E.g. if we also invent a keyword that resolves to the computed value of background-color, then maybe.
 - If I understand correctly, this will require that we store color-mix functions on ComputedStyle, similarly to calc() for <length-percentage> properties. If that's true, then:

I think that currently follows from the fact that this function takes <color> values and some <color> values are not resolved until used value time.
 
 - I wonder if it makes sense to first make color keywords compute to themselves before attempting mix-color().

Yes, I think the first step is to make all color representations in ComputedStyle be a StyleColor (current situation is that it's sometimes a Color with an extra bit for currentColor and sometimes a StyleColor) and extend StyleColor to be able to represent system colors (which should per spec compute to themselves) and more complex representations like color-mix().

ra...@microsoft.com

unread,
Jun 11, 2020, 8:12:57 PM6/11/20
to blink-dev, and...@chromium.org, fri...@jeka.info


On Wednesday, June 10, 2020 at 4:46:05 AM UTC-7, Rune Lillesveen wrote:
I think that currently follows from the fact that this function takes <color> values and some <color> values are not resolved until used value time.

That's right. In particular, we need to be able to mix the alpha channel of background colors in order to make the value of forced-colors available as computed value.  

Yoav Weiss

unread,
Jun 15, 2020, 9:15:27 AM6/15/20
to Kevin Babbitt, blink-dev
On Wed, Jun 10, 2020 at 12:44 AM 'Kevin Babbitt' via blink-dev <blin...@chromium.org> wrote:
TAG review? Or will this go through wide review elsewhere?

 

Summary

color-mix takes two <color> specifications and returns the result of mixing them, in a given colorspace, by a specified amount. For example, `color-mix(red yellow 40%)` produces a mixture of 40% red and 60% yellow.

 

Motivation

This new function will give designers greater flexibility when working with colors. One example is to create tinted variants of a single base color to form a design palette.

 

We also need this function to support a CSSWG resolution related to background-color in forced colors mode. The resolution calls for using color-mix to construct the used background-color from the rgb channels of the appropriate system color plus the alpha channel from the computed color.

 

Risks

Interoperability and Compatibility

- The syntax for color-mix is still evolving based on CSSWG discussion. Mitigation: The motivation for prototyping this feature now is an internal use case. We can defer shipping until syntax has stabilized.

- Blink does not yet support all color spaces recognized by color-mix. Mitigation: We will reject color-mix declarations for unsupported color spaces so that authors can feature-detect using @supports.

Firefox: No public signals

Edge: No public signals

Safari: No public signals

Web developers: No signals

 

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

 

Is this feature fully tested by web-platform-tests?

No Tests will be added as part of feature development.


Why?
 

 

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/5659115386830848

 

This intent message was generated by Chrome Platform Status.

 

--

leav...@gmail.com

unread,
Jun 16, 2020, 12:03:29 PM6/16/20
to blink-dev
Co-editor of CSS Color 5 here. 👋

First off, really exciting to see this intent to prototype! (as long as you folks realize that the syntax is extremely in flux and could be completely revamped, and are cool with that).
See some comments below.


On Tuesday, June 9, 2020 at 6:44:37 PM UTC-4, Kevin Babbitt wrote:


- Blink does not yet support all color spaces recognized by color-mix. Mitigation: We will reject color-mix declarations for unsupported color spaces so that authors can feature-detect using @supports.


Please note that color-mix() uses the LCH color space for interpolation by default. You cannot implement color-mix() per spec until you also implement at the very least, the LCH color space, unless you make the colorspace argument mandatory in your prototype (which will result in very clumsy syntax). This is done because interpolation in gamma corrected sRGB space produces terrible results (and that is the only colorspace Blink supports right now). It was a mistake in other parts of CSS, one that we do not wish to repeat. Linear RGB would have been ok, but then the intermediate values would not be expressible in CSS. Furthermore, LCH tends to maintain consistent chroma, which is desirable more often than not. 

You may find the TAG review of Lab & LCH useful: https://github.com/w3ctag/design-reviews/issues/488
Several Google engineers have weighed in too.
 
 

Web developers: No signals


I would argue that the very extensive use of similar functions in every CSS preprocessor is a pretty strong signal! 

Mathias Bynens

unread,
Jun 16, 2020, 12:44:30 PM6/16/20
to leav...@gmail.com, blink-dev, Anders Hartvoll Ruud, Rune Lillesveen, Chris Harrelson
Sounds like this might be blocked on 16-bit color support, then :(

The i2p for lch() and lab() got stuck for the same reason: https://groups.google.com/a/chromium.org/d/msg/blink-dev/iwsT-jkCQcI/Rpt_hBFUBQAJ

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/cea8c599-1c6c-4115-90a7-880238b32f54o%40chromium.org.

Kevin Babbitt

unread,
Jun 17, 2020, 2:20:47 PM6/17/20
to blink-dev, kbab...@microsoft.com


On Monday, June 15, 2020 at 6:15:27 AM UTC-7, Yoav Weiss wrote:


TAG review


TAG review? Or will this go through wide review elsewhere?

 

Is this feature fully tested by web-platform-tests?

No Tests will be added as part of feature development.


Why?

This was unclear, sorry - I do intend to add tests as part of feature development.
There's a checkbox on chromestatus.com for "Is this feature fully tested by web-platform-tests?" which I left unchecked because no tests exist yet. I think the template generated a "No" because that box was unchecked.

Kevin Babbitt

unread,
Jun 17, 2020, 2:43:19 PM6/17/20
to blink-dev, leav...@gmail.com


On Tuesday, June 16, 2020 at 9:03:29 AM UTC-7, leav...@gmail.com wrote:
Co-editor of CSS Color 5 here. 👋

First off, really exciting to see this intent to prototype! (as long as you folks realize that the syntax is extremely in flux and could be completely revamped, and are cool with that).

Thanks! I'm aware the syntax is still under discussion and happy to roll with changes as they come.
 
See some comments below.

On Tuesday, June 9, 2020 at 6:44:37 PM UTC-4, Kevin Babbitt wrote:


- Blink does not yet support all color spaces recognized by color-mix. Mitigation: We will reject color-mix declarations for unsupported color spaces so that authors can feature-detect using @supports.


Please note that color-mix() uses the LCH color space for interpolation by default. You cannot implement color-mix() per spec until you also implement at the very least, the LCH color space, unless you make the colorspace argument mandatory in your prototype (which will result in very clumsy syntax). This is done because interpolation in gamma corrected sRGB space produces terrible results (and that is the only colorspace Blink supports right now). It was a mistake in other parts of CSS, one that we do not wish to repeat. Linear RGB would have been ok, but then the intermediate values would not be expressible in CSS. Furthermore, LCH tends to maintain consistent chroma, which is desirable more often than not. 

This is true, and for the prototype implementation I do plan to make the colorspace argument mandatory since Blink doesn't support LCH yet.
 

Web developers: No signals


I would argue that the very extensive use of similar functions in every CSS preprocessor is a pretty strong signal! 

Great point, I've updated the chromestatus entry accordingly.

Yoav Weiss

unread,
Jun 18, 2020, 8:55:04 AM6/18/20
to Kevin Babbitt, blink-dev, jrob...@google.com
On Wed, Jun 17, 2020 at 8:20 PM 'Kevin Babbitt' via blink-dev <blin...@chromium.org> wrote:


On Monday, June 15, 2020 at 6:15:27 AM UTC-7, Yoav Weiss wrote:


TAG review


TAG review? Or will this go through wide review elsewhere?


Thanks! :)
 
 

Is this feature fully tested by web-platform-tests?

No Tests will be added as part of feature development.


Why?

This was unclear, sorry - I do intend to add tests as part of feature development.
There's a checkbox on chromestatus.com for "Is this feature fully tested by web-platform-tests?" which I left unchecked because no tests exist yet. I think the template generated a "No" because that box was unchecked.

Hmm, that's unfortunate. +Jason Robbins - FYI 

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
Reply all
Reply to author
Forward
0 new messages