Closed LeaVerou closed 1 year ago
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
.
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?
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);
}
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.
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.
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
?
The CSS Working Group just discussed [css-color] color-interpolation inherited property to set default interpolation space
.
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.
So we're busy adding interpolation syntax through
<color-interpolation-method>
tokens to all CSS features that need interpolation. So far we have it incolor-mix()
and gradients. There is still no syntax to set interpolation color space for transitions & animations yet. We could addtransition-interpolation: [ auto | <color-interpolation-method> ]#
andanimation-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
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 fromcolor-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 existingsRGB
andlinearRGB
as legacy aliases ofin srgb
andin srgb-linear
.