[css-color-5] [css-values-4] Interpolation and mixing of colors

[kbabbitt]

TL;DR: Colors are specified to interpolate using premultiplied alpha. The color-mix() spec doesn't mention premultiplying, which I took to mean "straight" alpha. I think they should be consistent, but I'm not sure what to align them to.

---

#3847 resolved to make system color keywords compute to themselves. This creates complications for animations and transitions, which operate on computed values. Presently an author can specify a transition from, say, MenuText to CanvasText and the RGB values will be interpolated. Absent other changes, retaining these keywords at computed-value time would yield a "discrete" animation.

In that discussion, @upsuper wrote:

It sounds this would make color animation more complicated. You may need to be able to express a computed color like 10% currentcolor + 20% Canvas + 30% Text + ... + 5% red, which... doesn't sound fun.

We now have a (proposed) tool to do that: the color-mix() function. I was going to suggest the following: Just like we use calc() to interpolate between length and percentage values, we use color-mix() to interpolate between colors which can be resolved to channel values at computed-value time and colors which cannot.

Then, I read https://www.w3.org/TR/css-values-4/#combine-colors, which states:

Interpolation of is defined as the independent interpolation of each component (red, green, blue, alpha) as a . Interpolation is done between premultiplied colors (that is, colors for which the red, green, and blue components specified have been multiplied by the alpha).

Right now the draft for color-mix() doesn't say anything about premultiplying alpha. Without that, I would naively expect mixing to be "straight" channel-by-channel. But that would mean we couldn't use color-mix() to interpolate without potentially breaking existing content.

Intuitively, I would expect "interpolate" and "mix" to be consistent with each other. I'm leaning towards having color-mix() use premultiplied values, but there might be consequences to that I haven't thought of.

[upsuper]

Just like we use calc() to interpolate between length and percentage values,

calc() between length and percentage values only involve two components, and color already has two components, i.e. fixed color value and currentcolor. The proposal adding unbounded number of interpolation components to color is exactly what I am concerned about.

[svgeesus]

Interpolation of is defined as the independent interpolation of each component (red, green, blue, alpha)

Wow, that RGB-centric text badly needs to be updated. Premultiplying in a gamma-corrected RGB space is also inherently incorrect.

In general, interpolation needs an overhaul. There is a start on that with the Interpolation section in Color 5.

Compositing also needs an overhaul (actually, a whole new level, which adds XYZ compositing in addition to the existing, badly broken, Photoshop-compatible sRGB gamma corrected compositing).

CSSOM mentions of color, which assume RGB, need an overhaul.

Values and Units, which assumes RGB, needs an overhaul.

[svgeesus]

in V&U 8.1. Colors: the <color> type it says

The <color> data type is defined in [CSS3COLOR]. UAs that support CSS Color Level 3 or its successor must interpret <color> as defined therein.

This is starting to cause problems, because specifications which want to reference all the types added to <color> in CSS Color 4 instead end up linking to CSS Color 3.

I know we aren't at CR yet but given active implementor interest I would like to start a discussion on the timing of changing that quoted sentence to say CSS Color 4 instead.

[svgeesus]

In V&U 8.1.1. Combination of <color>

Interpolation of <color> is defined as the independent interpolation of each component (red, green, blue, alpha) as a <number>. Interpolation is done between premultiplied colors (that is, colors for which the red, green, and blue components specified have been multiplied by the alpha).

This has a number of problems:

1. It assumes additivity, but operations are performed on a non-additive (gamma corrected) component. As is well known, this gives substantial error. But it is also how the Web currently works, so any better solution needs to be opt-in.
2. It assumes an orthogonal, rectangular coordinate system - which RGB is, but some coordinates in polar forms such as HSL HWB LCH are not. Clearly you don't multiply an alpha of 50% with a hue angle of 120deg to get 60deg, for example.
3. It assumes sRGB only. The section on Color interpolation does not.

So I'm looking for improved wording for the alpha premultiplication step which is color-space agnostic, ideally has an opt-in to linear-light computation (un-gamma-corrected RGB, or equivalently CIE XYZ to handle multiple spaces) which can be added to CSS Color 5 Interpolation section.

[svgeesus]

improved wording now in the "Interpolating alpha" section of Color 5