Closed Bug 1695376 Opened 3 years ago Closed 3 years ago

Implement basic color-mix() functionality, and expose it to chrome code and to content behind a pref.

Categories

(Core :: CSS Parsing and Computation, task)

task

Tracking

()

RESOLVED FIXED
88 Branch
Tracking Status
firefox88 --- fixed

People

(Reporter: emilio, Assigned: emilio)

References

Details

Attachments

(1 file)

No description provided.

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

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

Flags: needinfo?(chris)
Blocks: 1695382

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.

Flags: needinfo?(chris)

(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

See Also: → 1696202

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
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 88 Branch
Blocks: 1696434
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

For testing, what is the pref to set in Nightly and what version of Nightly will it be available?

(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.

Regressions: 1778899
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: