[css-color-5] How should negative percentages behave in color-mix()?

[weinig]

In CSS Color 5's color-mix() function, https://drafts.csswg.org/css-color-5/#color-mix, what should happen if a negative percentage is passed either as lone percentage or to an adjuster. For example, what should the behavior of the following two examples be:

color-mix(lch, red -10%, blue);
color-mix(lch, red hue -10%, blue);

In the investigative implementation in WebKit, I have implemented it as clamping to 0% in this case, but would like further clarity. Another, perhaps better, interpretation would be to keep it -10%, and use 110% of the hue of blue?

In general, being specific about values less than 0 and greater than 100 would be useful.

[LeaVerou]

Agree we need to define this. Not sure what's the best way about it, but I'm not a huge fan of clipping, as it throws information away.

It would probably be more useful to extrapolate (i.e. -10% and 110%) in that case, but that is not always possible, e.g. when we hit the color space bounds. But clipping at the colorspace bounds is probably no worse than clipping regardless.

[svgeesus]

Its simple to define negative percentages - 10% of a color means you multiply the components by +10/100, while -10% means you multiply them by -10/100. Same for values greater than 100%

Whether that is a particularly useful thing to do, though, is not clear.

The language about mix percentages would also need to be updated, probably with an example

color-mix(lch, red -10%, blue);
color-mix(lch, red -10%, blue 110%); // same

[una]

Why do we need to define negative values here? I think this would just add confusion. When mixing paint colors, for example, there is no construct of negative mixing. I think of color-mix() in the same way.

color-mix(lch, red -10%, blue 110%);

What would this look like? What is 110% blue? Would it just look the same as color-mix(lch, red, blue 100%); and get clipped to blue?

I just don't think it makes sense to have negative values here. In the spec as its written, you would only have one percentage (for the first color) which prevents the percentages from not adding up to 100%, and anything over 100% would clip to one of the input values in the color-mix() function.

[svgeesus]

What is 110% blue?

1.1 times the color components for that color, in the colorspace being used for mixing.

Would it just look the same as color-mix(lch, red, blue 100%); and get clipped to blue?

No (I think you are being led astray by the example mixing colors here, happening to be primary colors).

Why do we need to define negative values here?

A fair question. It needs to be defined, if someone does that. Clipping to [0 .. 100] is a reasonable option.

[LeaVerou]

Interpolating is not mixing paints. Sometimes that mental model works, but not always. There is a well-defined meaning of values out of range when interpolating, so there is something reasonable we could do here. Whether that's also useful is another question and I have no strong opinions on that.

If we don't allow percentages outside 0-100%, I wonder if we can make them invalid at parse time. Silently clipping them means there is zero feedback for authors to realize that something is off so I don't think it's a good idea.

[una]

I think this is not unreasonable to expect (0-100%) as valid inputs. This seems like a documentation/education issue, and a place where Dev Tools can interject a warning signal for clipping, as with other CSS that is invalid (if we don't want negative values to cause this to fail and ignore the line).

[LeaVerou]

Any design flaw can and has been addressed via documentation/education, but that's usually a bandaid when it's too late to change the design. It's one of the basic usability antipatterns to avoid designing UIs that require documentation/education to make sense, since most people will not read much documentation, and you can never reach everyone to educate. UIs (including APIs) need to be designed to be understandable and usable even in the absence of documentation/education.

The more I think about this, the more I think that the most reasonable thing is for percentages out of range to extrapolate along the same line. Even if there are no use cases, it provides useful feedback which aids debugging, it is no harder to implement than regular interpolation (if anything, not doing this is probably extra implementation work), and doesn't get in the way of regular usage in any way. Note that there is precedent of extrapolation in CSS, with transitions with certain timing functions that make the interpolated value go beyond 100% (demo).

[tabatkins]

Going outside of the 0-100% range violates the mental model that this is mixing colors and makes this function behave differently than the other mixing functions (cross-fade() in particular). The behavior y'all are describing isn't interpolation, either, it's arbitrary scaling and addition of the colors.

That has further odd implications - it implies that if the %s sum to >100%, that doesn't get rebalanced, you just get a super vivid/light/etc color. Similarly, %s summing to <100% just makes a very achromatic/dark/etc color. That's all pretty weird, and nothing like the concept of "mixing" we're trying to evoke here! Without a fairly compelling use-case for this, I'm strongly against trying to generalize past the "mixing" concept.

Like the other mixing functions, %s outside of 0-100% should just be invalid at parse time.

[tabatkins]

transitions with certain timing functions that make the interpolated value go beyond 100%

Ah wait, I see, your mental model could be interpolation given the older syntax that we just resolved to change away from. If there's a single %, and you interpret it as an interpolation %age between the two colors, then a <0% or >100% value is indeed just further interpolation in the same manner.

But since we resolved to instead stick closer to the other mixing functions and allow %s on both values, this analogy no longer holds.

[LeaVerou]

Tab, cross-fade() does compositing, not interpolation. color-mix() is currently defined in terms of interpolation, and that affects a lot of the design decisions around it. If you think it should be performing compositing instead, we could discuss that change in a separate issue (and potentially change the default color space to a linear light one that is more appropriate for compositing). However, until such a change is made, the underlying model is interpolation, with everything that comes with it, good and bad.

The percentages on both values are merely syntactic sugar to avoid authors having to manually subtract from 100%. It's still only one percentage really.

[tabatkins]

cross-fade() does compositing, not interpolation

I'm very confused - cross-fade() is literally the way that images interpolate. Implementation hasn't caught up, but when you transition background-image/etc, cross-fade() is just how you write the intermediate state. I'm not sure what distinction you're trying to draw here.

Regardless, tho, my argument is at a different level - both of these functions are mixing two (or more) things. The fact that we can implement "mixing" as "scaling and adding" doesn't mean that "scaling and adding" is the correct mental model we should be exposing to authors; that's a leaky abstraction. Like cross-fade() does, the interface we should be exposing to authors is mixing-focused, and that implies certain things about how we interpret overconstrained % situations.

Unless there's a very good reason otherwise, the various value-mixing operations should look as identical as possible to authors; giving authors bespoke mechanisms for what are, to them, identical operations with different value types is bad design on our part. If you think there's a very good reason why color-mix() should act like this, then presumably it applies to cross-fade() as well, and we should harmonize the specs. If you think there's a very good reason why color-mix() should act like this that doesn't apply to mixing images, I'd love to hear it, so I can be convinced that these mixing functions should indeed act differently from each other.

But right now I see absolutely no difference between the two. cross-fade()'s definition of "linear weighted average of each pixel's colors, in premultiplied sRGB space" is mathematically the same as "scale and add (in a particular colorspace)", so any argument you can give for why colors should act in a certain way due to the underlying math would apply to images exactly as well.

(Also, the

The percentages on both values are merely syntactic sugar to avoid authors having to manually subtract from 100%. It's still only one percentage really.

I don't understand what you mean by this, either. Could you elaborate? Unless I'm misunderstanding, it's omitting a % that allows authors to avoid manually subtracting from 100%.

---

Tangentially, you had said in the call that there were reasons to limit color-mix() to only two colors, and I thought that I remembered you or Chris explaining why in one of the issues, but I can't find it now. Can you point me to it, or restate it? If the math of color-mix() is literally just "interpolate the components, via scaling and adding", then I'm not sure why three colors are problematic.

[tabatkins]

The minutes-bot wasn't told the issue number for this discussion, but here are the minutes from yesterday's call:

How should negative percentages behave in color-mix()?

github: #6047

chris: Sam Weinig who is implementing pointed out that can't do
negative percentages
chris: una said why don't we clip it 0-100%
chris: nobody wants this
chris: I can define it
fantasai: Can you make it invalid?
TabAtkins: Invalid matches behavior in other mixing functions
TabAtkins: We intend for it to be meaningless, so should be invalid

RESOLVED: negative percentages are invalid in color-mix()

@LeaVerou, are you saying that we should re-open the issue and change the resolution? Because the minutes are quite clear on what we decided - negative %s are invalid (and the intention of the resolution is that >100% individual percentages are invalid, too, it just didn't get caught by the resolution text). And the preceding discussion, similarly, said that when both colors give a % and they sum to >100%, we'll rebalance the %s to add to 100%, not just literally scale each as specified then add them together.

The only remaining open question was about what to do when they both specified a % and they sum to <100%, because I thought there might be an argument to match cross-fade() and "fill in the remaining %" with transparent, you said there were problems with this, and I didn't want to take up more call time with just me being educated so I suggested we discuss it in the issue so we could decide next week.