[css-color] `color-interpolation` inherited property to set default interpolation space

[LeaVerou]

So we're busy adding interpolation syntax through <color-interpolation-method> tokens to all CSS features that need interpolation. So far we have it in color-mix() and gradients. There is still no syntax to set interpolation color space for transitions & animations yet. We could add transition-interpolation: [ auto | <color-interpolation-method> ]# and animation-interpolation: [ auto | <color-interpolation-method> ]# properties (and corresponding tokens in shorthands), but I was wondering: what if we have an (inherited) property to set default interpolation space across an entire subtree?

Something like

color-interpolation: auto | <color-interpolation-method>

This would allow authors to set this at the root of a subtree and get their preferred interpolation method as a default across gradients, color-mix(), transitions, animations, even SVG.
This would also allow us to remove the mandatory <color-interpolation-method> token from color-mix().

Caveat: There is this old SVG color-interpolation property but I believe it's not really used/implemented. If it turns out that it is, we can include the existing sRGB and linearRGB as legacy aliases of in srgb and in srgb-linear.

[svgeesus]

The one problem that I see with this is that there is no one right interpolation color space that is good for everything. This will be particularly noticeable when we update Compositing to allow a linear-light colorspace like xyz-d65 in addition to the current only (and wildly incorrect) option, gamma-encoded srgb.

This is why we had color-interpolation filters as well as color-interpolation, as they have different initial values and filters needed to operate in alpha-premultiplied srgb-linear.

[svgeesus]

We could add transition-interpolation: [ auto | <color-interpolation-method> ]# and animation-interpolation: [ auto | <color-interpolation-method> ]# properties

To be clear, those would be added in CSS Transitions and to the keyframe syntax in CSS Animations respectively, right?

[svgeesus]

So this would look like

.foo {
  background-color: #0000FF;
  transition: background-color 2s in oklab;
}
.foo:hover {
  background-color: color(display-p3 0.1 0.9 0.4);
}

or, with this new proposal:

body {
  color-interpolation: in oklab;
}
.foo {
  background-color: #0000FF;
  transition: background-color 2s;
}
.foo:hover {
  background-color: color(display-p3 0.1 0.9 0.4);
}

[svgeesus]

The interaction of color-interpolation with color-interpolation-filters would also need to be defined, because the filters spec currently assumes all operations are in a (non-extended, 8-bit) RGB space, either sRGB or linear-rgb (== srgb or srgb-linear). Currently those two SVG properties are disjoint, applying to different elements.

[fantasai]

Why do we need the in keyword here? Doesn't seem like we need it, and we don't have such keywords in property values generally.

[svgeesus]

Because that is how <color-interpolation-method> already works, for color-mix() and gradients

Edit: Oh I see, you mean for color-interpolation not for transition-interpolation or animation-interpolation?

[css-meeting-bot]

The CSS Working Group just discussed [css-color] color-interpolation inherited property to set default interpolation space.

The full IRC log of that discussion

<emeyer> Topic: [css-color] color-interpolation inherited property to set default interpolation space
<emeyer> Github: https://github.com//issues/7035
<emeyer> Lea: We’re been going through spec and adding interpolation space in gradients, other things. Don’t have a way to add to adnimations or mixing yet.
<emeyer> …When it comes to augmenting gradients, this will make them invalid in older browsers. Authors would need @supports or variables. It’s kind of tedious.
<chris> comparison of this proposal with the other one: https://github.com//issues/7035#issuecomment-1041850688
<chris> q+
<emeyer> …It also means any new spec with interpolation lacks control until we add this.
<JakeA> q
<emeyer> …There is no quick easy way for authors to say they want interpolation without dealing with browser issues. So maybe a color-interpolation property would help here.
<JakeA> q+
<emeyer> …That way it can be set and inherited and overridden. You can set it at root and all your gradients become better.
<emeyer> …Chris pointed out you probably want different interpolation spaces for different use cases.
<Rossen_> q?
<emeyer> chris: You may want different interpolations for different operations. I can imagine you’d want different interpolations on different transitions.
<emeyer> …The question is, is it useful to set a default for an entire document or subtree.
<Rossen_> ack chris
<emeyer> …SVG has two properties that deal with this sort of thing.
<smfr> css filters are in sRGB
<emeyer> …I don’t think it adds enough value to justify the complexities.
<Rossen_> ack JakeA
<emeyer> JakeA: I have similar concerns. You could set this property and it makes all the gradients look great, but then later we add it to mix-blend-mode or whatever and they all look ugly.
<Rossen_> ack fantasai
<emeyer> fantasai: If different interpolations for different operations are expected, it would make sense to have focused properties (color-interpolation-gradient, etc.).
<faceless> q+
<lea> +1 to almost everything fantasai just said (except re: in keyword)
<emeyer> …I also don’t think we should have an end keyword.
<fantasai> s/end/in/
<Rossen_> ack dbaron
<emeyer> dbaron: I was wondering about a global property: is it possible to have two global properties? Is it the case that there’s a set of things that make sense to interpolate in linear light and another set of things that need gamma correction?
<fantasai> s/focused properties/focused longhand properties/
<emeyer> …Does it make more sense to have those two rather than seven or eight properties?
<emeyer> chris: I think that’s correct; some want to be linear and some want to be perceptual.
<Rossen_> ack faceless
<emeyer> faceless: I think this would be confusing if it didn’t include the SVG properties as legacy syntax. I don’t see a reason we couldn’t do that.
<TabAtkins> +1 to Chris and Jake's concern about a single global default
<emeyer> Rossen: Sounds like there’s an interest in exploring this in terms of focused properties like color-interpolation-gradient, which is safer. Is that the path we want to take?
<emeyer> chris: I think there’s interest in further exploration.
<TabAtkins> But I'm fine with longhands like fantasias mentioned
<lea> s/fantasias/fantasai/
<emeyer> Rossen: Let’s take the conversation back into the issue.

[svgeesus]

Realization I came to is that this proposal is for setting a default, so if you want a non-default value then we need the transition-interpolation or animation-interpolation anyway. So I will raise a new pair of issues for those.