[css-transitions][css-animations][web-animations] Add control of colorspace used for transitioning colors

[svgeesus]

( Spun out from #7035 )(similar to #7062)

Currently, all color transitions happen in gamma-encoded sRGB space. There is a need to preserve this as a default, for Web compat. However, CSS Color 4 defines a bunch of other color models, which exceed the very limited gamut of sRGB, and there is a need to add control of the color space used for interpolation which is currently unspecified:

• to avoid needless conversion to sRGB, dropping the more saturated colors
• because interpolating in gamma-encoded space gives overly dark midpoint colors
• because some color spaces give better results than others, which kind of varies depending what the start and end colors are, so stylesheet authors need the flexibility to choose.

As this is a common requirement, CSS Color 4 defines a <color-interpolation-method> token and associated color interpolation math; this has already been used in the grammar for `color-mix() in CSS Color 5 and in linear, radial and conic gradients in CSS Images 4.

So this issue proposes to add a new property, initial value auto:

transition-interpolation: [ auto | <color-interpolation-method> ]#

and also to add this to the <single-transition> shorthand. There is no ambiguity (unlike time) so it can go in any order in the shorthand.

[dbaron]

I think we should be looking at css-transitions-1 as feature complete, and looking at this for css-transitions-2.

[svgeesus]

Thanks, David. Is there agreement that this is the correct approach?

If so, would you like a PR to review, or should I just add it?

[dbaron]

I think it probably requires some amount of discussion, though I haven't thought about the issue. My comment above was part of triaging css-transitions-1 issues in the hope of getting that spec to advance.

[LeaVerou]

Agreed this should be in css-transitions-2.

[svgeesus]

There was related discussion in another issue where I said:

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?

If so, I think you'd also need to define how they end up getting represented in Web Animations KeyframeEffect objects (possibly be adding another global keyframe attribute like offset etc. as in the last part of the informative note here).

[svgeesus]

Agenda+ to get CSSWG resolution on this.

[css-meeting-bot]

The CSS Working Group just discussed [css-transitions] Add control of colorspace used for transitioning colors.

The full IRC log of that discussion

<bramus> chris: css color-4 add something that others spec can reference: color interpolation method
<bramus> chris: already used for gradients
<bramus> chris: proposeal to add same token to animations, transitions, and web animations
<bramus> chris: proposal since March without no comments
<bramus> chris: cant think of other way to do it
<emilio> q+
<bramus> emilio: the idea is to add a transition-interpolation property?
<flackr> q+
<bramus> chris: yes
<bramus> chris: same for animation-interpolation
<bramus> emilio: so it needs to be a list?
<bramus> chris: yes
<bramus> emilio: dont know, maybe this should be in keyframes?
<bramus> chris: that is part of the proposal
<bramus> emilio: feels weird that this is color specific but property name does not give hint
<bramus> chris: can put color in there
<bramus> emilio: could be confused otherwise
<bramus> +1
<bramus> emilio: other than that seems reasonable
<Rossen_> ack emilio
<bramus> chris: brian also added proposal for web animations in the issue
<bramus> emilio: do we expect a lot of ppl setting this to anything other than oklab?
<bramus> chris: that gets us in the whole webcompat issue
<flackr> q-
<bramus> chris: talking about an opt in
<bramus> chris: oklab and oklch will be obvious choices
<fserb> I think adding color to the name makes sense. (nit: Is it a problem to add "auto" on the shorthand?)
<bramus> emilio: if you do color-mix with two oklab colors, they mix in oklab right?
<bramus> chris: yes
<bramus> emilio: (???)>
<bramus> chris: doesnt matter how you specify the orig colors. you can mix in other spaces
<bramus> emilio: maybe default should be oklab?
<bramus> chris: would be nice, but people have existing content
<bramus> emilio: maybe auto can do the right thing based on the defined colors?
<bramus> chris: auto means that legacy srgb mix in srgb. non-legacy colors mix in oklab.
<fserb> I think auto already does what emilio wants.
<bramus> Rossen_: in terms of feature itself, do you agree emilio? then can sweat details.
<flackr> q+
<bramus> emilio: seems reasonable, other than prop name
<bramus> chris: agree
<bramus> emilio: do we want to allow interpolationg different properties differently?
<bramus> emilio: eg background-color and color
<bramus> chris: i understand the requirement
<bramus> chris: if its about the keyframes, it means it applies to all color interpolations. a separate vlaue for each one, would need a ton of new properties
<Rossen_> ack flackr
<bramus> flackr: could we specify this as part of the color?
<flackr> q-
<bramus> chris: we are not going to solve this in 5 minutes
<bramus> Rossen_: good suggestion
<bramus> fantasai: so proposal is to add both transition-interpolation and animation-interpolation, where you can put the last one in a keyframe too?
<bramus> chris: yes
<bramus> fantasai: we also hav esuggestion from emilio to do it per property
<bramus> fantasai: this could be an addition?
<bramus> flackr: would affect the syntax
<bramus> emilio: need to know if we want this in the future
<bramus> fantasai: two possible ways to go about it, is to incorporate it in the color (cfr. flackr) and another option is to do sth similar as we do with transition
<bramus> chris: the latter seems like a better solution
<bramus> chris: would like to see it written out
<bramus> Rossen_: looks like this is expanding beyond orig proposal
<bramus> Rossen_: lets take back to issue
<bramus> chris: yes
<fantasai> s/with transition/with transition, and list out the properties named e.g. animation-color-interpolation: oklab color background-color sRGB outline-color, ...; /
<bramus> Rossen_: dont see issue we can tackle in 2 minutes …

[LeaVerou]

Assuming this property is list-valued, like all other transition/animation properties then it's already possible to use different color interpolation methods per property, at least for transitions. For animations it would be a little more involved, but still possible. Also, I think that's a bit of an edge case, not something to center the design around. As long as it's possible, it's fine.

Agree with renaming to *-color-interpolation, though a generic *-interpolation property may allow for more future expansion. OTOH I cannot envision what such future expansion could look like: for any other value, when you want to control how it interpolates you use *-timing-function. However, we could use *-interpolation-color instead of *-color-interpolation so that if such cases emerge we can define a *-interpolation shorthand with longhands.

[milasudril]

Well, this is not only related to transitions. It is also related to all sorts of compositing. Thus, an idea is to have a CSS color-rendering-mode property that affects compositing, transitions, gradient and all color related attributes.

color-rendering-mode

Supported values:

• legacy: This value is default. Ihen using this mode alpha blending and gradients are broken as required by old specification.
• linear: Color are blended and specified in linear RGB space, unless otherwise specified. Enabling this mode is a recommended best practice. If you specify #808080, the color will be slightly brighter than in legacy mode. It is possible to specify a color values using the legacy definition as such

• color-rendering-mode: linear; color: sRGB(#808080)

Notice that this only affects the interpretation of #808080, which will enter the rendering pipeline as roughly #404040. Blending and gradient rendering is still performed in linear space.'

You would typically use color-rendering-mode as you use the border-box property:

{box-sizing: border-box;width: 100%;border: solid #5B6DCD 10px;padding: 5px;}

Which I also highly recommend using.