Re: [csswg-drafts] [css-images-4] Consider allowing gradients to include a color space for interpolation to take place in (#5833)

Previous discussion on this: https://github.com/w3c/csswg-drafts/issues/4647

I'm all for this, of course, and have been mulling it over as we implemented it.
* agree with @Artoria2e5 that we certainly need some sort of general interpolation property (inheritable), and that - to allow people to use different interpolation strategies on the same element - we should probably add an optional argument to each gradient too. In particular, `mask-image: radial-gradient(...)` needs the option of using `linearRGB` even if the other parts of the element use another strategy.
* there are likely existing gradients with colors defined in HSL; these have to continue to interpolate in sRGB by default.

So I'm broadly in agreement with the above proposal, and in particular think we should definitely extend the existing `color-interpolation` property to make it apply universally, not just to SVG. I would suggest adding two new values to that property:

`color-interpolation: auto | srgb | linearrgb | match | lch`
* "auto" is currently defined as _"the user agent can choose either the sRGB or linearRGB spaces for color interpolation. This option indicates that the author doesn't require that color interpolation occur in a particular color space"_. I'd propose changing this to be be "Choose "srgb" for colors specified as sRGB or HSL, and otherwise act as "match".
* "match" means use the color-space of the colors being interpolated. So two sRGB colors interpolate in sRGB, two HSL colors in HSL, two LCH colors in LCH. If the colors have different spaces, the interpolation is in LCH.
* "lch", "srgb", "linearrgb" - interpolation always happens in that space.

The "match if we can, lch if we can't" approach was roughly where we got to in https://github.com/w3c/csswg-drafts/issues/4647, but that's obviously subject to revision. And I'd keep the list of options to a bare minimum - there's no need to blend Lab colors in display-p3.

My only worry is that the default value is currently "sRGB" not "auto". I'm not really sure why auto exists, actually - it doesn't seem to do anything except introduce ambiguity. As it currently gives the user agent the option of choosing between srgb and linearrgb, making it the default and redefining it to mean "always choose srgb for colors defined prior to color-4" doesn't seem to be a breaking change to me.

The "shorter, longer" hue issue was discussed here: https://github.com/w3c/csswg-drafts/issues/4735.

-- 
GitHub Notification of comment by faceless2
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5833#issuecomment-786535903 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 26 February 2021 09:48:35 UTC