[css-color-hdr] How should checking for percentages summing to 0 work in `dynamic-range-limit-mix()` and `color-mix()` when calc() is used?

[weinig]

The text for dynamic-range-color-mix() contains this statement:

If the sum of all percentages is 0%, then the function is invalid.

If the intent is that this is checked at parse time, which is when things are usually marked invalid, what should happen for calc() values that aren't resolvable until style building?

[weinig]

cc (@svgeesus, @ccameron-chromium)

[ccameron-chromium]

This should be the same as with color-mix. I vaguely remember there being some words like "if it can be determined to be 0% then it is invalid". But maybe we should change both of those to say "if it sums to 0% then distribute all parameters evenly". That would keep things simpler.

[weinig]

Ah! Looks like I had the same concern with color-mix when implementing that, https://github.com/WebKit/WebKit/blob/main/Source/WebCore/css/parser/CSSPropertyParserConsumer%2BColor.cpp#L617.

I think your suggestion makes sense.

[svgeesus]

I see that we only have two WPT tests (14 subtests in total), none of which tests

If the percentages sum to zero, the function is invalid.

[ccameron-chromium]

For dynamic-range-limit, this test is testing the behavior. But I'm totally fine with changing it.

[squelart]

I think there could be some ambiguity and/or inconsistency with accepting a sum of 0%:
The proposed solution would compute:

• mix(a 0%, b 0%) to be mix(a 50%, b 50%)
• mix(a 0%, b 0%, c 0%) to be mix(a 33%, b 33%, c 33%)

However, since we have the other kind of equivalence mix(a 50%, b 50%) == mix(a 50%, b 50%, c 0%), it would be consistent that mix(a 0%, b 0%) == mix(a 0%, b 0%, c 0%), and now we have a conflict as they result in something different!
(Or did I miss some detail?)

[css-meeting-bot]

The CSS Working Group just discussed [css-color-hdr] How should checking for percentages summing to 0 work in dynamic-range-limit-mix() when calc() is used?, and agreed to the following:

• RESOLVED: remove the sentence in spec that says if sum is zero, treat as invalid; possibly add new prose about splitting the percentage, and update tests

The full IRC log of that discussion

<jcraig> weinig: issue is that the spec for dynamic color mix has rules applied at parse time that check if value is zero
<jcraig> if all percentages add up to zero, they are invalid, but calc() may not know if it's invalid yet
<jcraig> options: either define at calc time what do in that scenario, mark as invalid at computed style time, or have it behave as if all percentages are the same; evenly divided
<jcraig> someone brought up the a concern with 50 high 50 low example, nothing constrained, you'd get 33/33/33 (not sure if I scribed that correctly)
<jcraig> currently we even split it, but worth considering when animating the ramps to zero
<jcraig> ChrisL: people will ramp it for animation so we should ensure it's not jarring
<jcraig> weinig: no current test for that.... but yes, should fix that
<jcraig> propose if all zero, treat as all at 33%
<jcraig> ChrisL: sounds reasonable
<jcraig> proposal: remove the sentence in spec that says if sum is zero, treat as invalid
<jcraig> weining: i can take on an item to work up the correct prose for that change to splitting the percentage
<jcraig> s/treat as invalid/treat as invalid; possibly add new prose about splitting the percentage, and update tests/
<jcraig> astearns: no objections resolved...
<jcraig> rrsagent, make minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2025/02/26-css-minutes.html jcraig
<jcraig> RESOLVED: remove the sentence in spec that says if sum is zero, treat as invalid; possibly add new prose about splitting the percentage, and update tests