[css-transitions] Define interpolation of the currentcolor keyword

[SimonSapin]

Interpolation happens on computed values:

https://drafts.csswg.org/css-transitions/#transitions

The computed value of a property transitions over time from the old value to the new value.

The computed value for <color> is either a RGBA color or currentcolor:

https://drafts.csswg.org/css-color/#currentcolor-color

The keyword currentcolor takes its value from the value of the color property on the same element. This happens at used-value time,

When defining how to interpolate <color>, css-transitions seems to assume it can only be an RGBA color:

https://drafts.csswg.org/css-transitions/#interpolated-types

color: interpolated via red, green, blue and alpha components (treating each as a number, see below). The interpolation is done between premultiplied colors (that is, colors for which the red, green, and blue components specified have been multiplied by the alpha).

The section in this last quote should define how currentcolor interpolates. Is it not interpolate, or should it be substituted by the value of color (which itself might be animated or transitioning) for the purpose of interpolation?

CC @Manishearth, @upsuper

[upsuper]

Note there was some discussion in the mailing list in this thread: https://lists.w3.org/Archives/Public/www-style/2016Apr/0281.html

cc @dbaron @tabatkins

[upsuper]

Currently, different engines have different behavior for different properties.

In Gecko, on some properties like -webkit-text-fill-color, text-emphasis-color, currentcolor and numeric color are not interpolatible; for some properties we interpolate currentcolor as the static value of color property; for other properties we haven't handled currentcolor as a keyword yet.

In Blink, as far as I can see, background-color property uses the ideal way which interpolate the numeric color and currentcolor in a ratio, while for -webkit-text-fill-color, currentcolor is not interpolatible.

I'm trying to implement the ideal interpolation way (the way how Blink handles background-color) for all properties in Gecko so that we can unify the handling of currentcolor in our codebase.

[upsuper]

FWIW, the way we are implementing does not match how blenda() function is defined in the current draft of CSS Color 4.

The issue with blenda() function is that, CSS Transitions spec currently specifies linear interpolation for color values, while blenda()'s formula is different from that, which means we would have inconsistent behavior for some cases.

[svgeesus]

Linear interpolation is a reasonable assumption for all transitions, including for color. The issue is what color space to perform the linear interpolation in. We have talked about adding a document-wide working colorspace property. The initial value would be sRGB. That property seems like the best candidate here, so currently any wide-gamut colors would be converted to sRGB before being interpolated. Other values of working colorspace would avoid that initial color change from gamut mapping.

[upsuper]

FWIW, Gecko has implemented interpolation between "currentcolor" and numeric color for majority of CSS color properties (if not all). It does so via interpolating colors linearly in a way like "x% of rgba + (1-x%) of currentcolor". As far as I can see, this also matches how Blink interpolates them.

[frivoal]

Given the approximative interop we already have, this could probably be solved by adding the following sentence to the definition of color interpolation.

Interpolating to or from currentcolor is possible. The numerical value used for this purpose is the used value.

[fantasai]

@frivoal That wouldn't be sufficient to handle, e.g.

div { text-emphasis: circle; transition: all 2s; }
div:hover { text-emphasis-color: lime; }
em { color: red; }

We need to handle currentColor as a separate component, so that e.g. you have some percentage of currentColor plus an rgba component. (We could serialize this out using an interpolate() function so there's no new syntax to add, but the computed value needs to be defined to make this work.)

[upsuper]

Note that gCS returns used value for color properties, so syntax wouldn't be a problem for that case. But if we want to take Typed OM into account, maybe we need to resolve on a syntax.

[svgeesus]

this could probably be solved by adding the following sentence to the definition of color interpolation.

That link has gone cold; it looks like neither Transitions 1 nor Transitions 2 defines color interpolation. Where did it get moved to?

[birtles]

this could probably be solved by adding the following sentence to the definition of color interpolation.

That link has gone cold; it looks like neither Transitions 1 nor Transitions 2 defines color interpolation. Where did it get moved to?

Values and Units: https://drafts.csswg.org/css-values-4/#combine-colors

[svgeesus]

Depends on https://github.com/w3c/csswg-drafts/issues/5392

[svgeesus]

Well, for now, I added the text suggested by @frivoal to the Interpolation section in CSS Color 5. Unlike the antique text in V&U it doesn't assume all colors are sRGB. Also, color interpolation is better being in a color spec.

Is there anything useful from V&U combine colors that should be salvaged?

[svgeesus]

@fantasai I do understand the issue you raise about keeping the currentColor contribution separate so that it can be re-evaluated. But that isn't what is currently implemented, so for now at least documenting what we have is one step closed.

[svgeesus]

The Interpolation section in CSS Color 5 now also includes interpolation with alpha; but still assumes that currentColor resolves to a used value rather than a percentage of real color and percentage of currentColor.

Unlike what is in V&U, there is no assumption of sRGB. display-p3, lab, lch are all handled.

If there is only one special keyword, handling it isn't too bad. If we also need to consider the percentage of system colors, or add new functionality like currentBackground then this becomes rather more complex.

[svgeesus]

(Removing css-color4 tag, therefore)