Implement basic color-mix() functionality, and expose it to chrome code and to content behind a pref.
Categories
(Core :: CSS Parsing and Computation, task)
Tracking
()
Tracking | Status | |
---|---|---|
firefox88 | --- | fixed |
People
(Reporter: emilio, Assigned: emilio)
References
Details
Attachments
(1 file)
Assignee | ||
Comment 1•3 years ago
|
||
This is straight-forward and builds on the color animation code. This
implements only the <percentage> syntax, not the whole <color-adjuster>
syntax, which seems fairly more complex.
Of course, this only uses sRGB because that's all the colors we support,
but it should be feasible to extend to lab() / lch() colors once we
support those.
I believe this subset of syntax is useful and worth implementing, so
people can play with it and say if it's useful.
Depends on D106690
Assignee | ||
Comment 2•3 years ago
|
||
Curious about how stable this syntax is Chris?
I've implemented basic sRGB color mixing (basically, the same mix we do on CSS animations), only with percentages (or 50% when omitted).
I haven't looked into the color-space-dependent bits yet, because implementing lab()
/ lch()
is a much bigger project, but as I understand this conforms to the colors specs since the interpolation section of colors-4 explicitly says "legacy" colors, (which is actually all the colors we support), should use sRGB. Let me know if I misunderstood though.
I plan to enable it in Nightly for now so people can play with it, report bugs, and confirm it's useful. The Firefox front-end devs were the ones who requested it so they get it unconditionally ;-)
This particular syntax doesn't seem likely to change, but let me know if it does so that I can tell the frontend folks not to abuse it :P
The syntax so far is stable, but there is talk of maybe simplifying it to just allow mixing all the components, rather than individual components. Depends on whether people find the extra functionality useful or not, so feedback is welcome.
Remember that, since lch() is the default, you will need to always specify srgb() explicitly. Otherwise content will change when you implement the rest of the specification.
Lets unpack what the Color 4 interpolation spec says about the colorspace for interpolation:
Colors are first converted to Lab and then interpolated as Lab colors.
(That is in general, but see the next sentence)
Host syntax can override the interpolation color space and specify which color space is used for interpolation.
Which it does. Color 5 says that
When no colorspace is specified, the mixing is done in the lch colorspace.
which means that to get sRGB you need to specify srgb() in color-mix.
Moving back to Color 4:
The exception is that if all the <color>s to be interpolated are sRGB values, and they are all expressed in a legacy syntax such as hex colors, named colors, rgb(), hsl() or hwb() (and the equivalent alpha-including forms) then they are interpolated in gamma-encoded sRGB space.
Hmm. It is ambiguous whether this is part of the "host syntax can override" clause or not. I had intended that it was. I'm going to open a separate issue on that so we can clarify one way or the other.
Assignee | ||
Comment 4•3 years ago
|
||
(In reply to chris from comment #3)
Hmm. It is ambiguous whether this is part of the "host syntax can override" clause or not. I had intended that it was. I'm going to open a separate issue on that so we can clarify one way or the other.
Could you CC me in that issue? I honestly would find it weird that color-mix(a, b)
would behave differently than e.g. CSS transitions, but I guess I could live with that and require our front-end to spell out color-mix(srgb, a, b)
or something... Could you paste the issue link here or cc me on it?
Thanks Chris.
I honestly would find it weird that color-mix(a, b) would behave differently than e.g. CSS transitions
CSS Transitions, CSS Animations, and CSS Gradients are all currently sRGB-only and will need a opt-in syntax to allow wider gamut colorspaces. They are that way because of their age. For gradients, see https://github.com/w3c/csswg-drafts/issues/5833
So it won't behave differently, once we are done upgrading the other features; and more importantly we don't want to have a poor default.
The stuff in Color 5 does not assume sRGB-only, which is why it a) has explicit colorspace specifiers and b) can pick a good default, LCH in this case.
Could you CC me in that issue?
Of course. Let me do that now .... here it is
https://github.com/w3c/csswg-drafts/issues/6059
Assignee | ||
Comment 6•3 years ago
|
||
In the interest of getting something landed for folks to experiment I'll push it with the syntax I proposed here, with the wpt renamed to .tentative
of course.
I'll of course revise this as the spec discussions get sorted out though.
Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/cc24224fecd0 Implement basic color-mix() functionality, behind a pref, but exposed to chrome code. r=boris
Comment 8•3 years ago
|
||
bugherder |
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/27995 for changes under testing/web-platform/tests
Upstream PR merged by moz-wptsync-bot
Comment 11•3 years ago
|
||
For testing, what is the pref to set in Nightly and what version of Nightly will it be available?
Comment 12•3 years ago
|
||
(In reply to chris from comment #11)
For testing, what is the pref to set in Nightly and what version of Nightly will it be available?
layout.css.color-mix.enabled
it is enabled by default in Nightly.
Comment 13•3 years ago
|
||
Ongoing discussion at https://github.com/w3c/csswg-drafts/issues/6206
Specification clarified to define serialization, see https://github.com/w3c/csswg-drafts/commit/de3dab70d605344f6c7e21ad2885b52aec905792
and (once it builds in a hour or so) https://drafts.csswg.org/css-color-5/#serial
Description
•