[css-values] when should values inside `mix()` be clamped?

[graouts]

CSS Values and Units Level 4 introduces the mix() function. It's not clear to me reading the spec at what point clamping should be applied for this example:

<div style="font-size: 40px; line-height: mix(0.5, 40px, calc(40px - 3em))"></div>

The spec has this to say in the Range Checking section for calc():

Parse-time range-checking of values is not performed within math functions, and therefore out-of-range values do not cause the declaration to become invalid. However, the value resulting from an expression must be clamped to the range allowed in the target context.

I'm not sure what "resulting from an expression" means here. I think the above mix() value could resolve to either:

1. 20px where we clamp the output of the calc() expression and mix between 40px and 0px,
2. 0px where we only clamp the output of the entire mix() expression and mix between 40px and -80px, clamping the result -20px to 0px

Assuming that "resulting from an expression" refers to any math function then it would clearly be the first result since mix() is not a math function.

This is somewhat related to #8157 where I raised the issue of what would happen when interpolating between the same two values in the context of an animation.

[Loirooriol]

I would say (1). mix() uses the grammar of the property to interpolate the expressions, e.g.

order: mix(50%; 1; 9); /* (1+9)/2 = 5 */
aspect-ratio: mix(50%; 1; 9); /* sqrt(1*9) = 3 */

so interpolating a negative length if the property doesn't understand negative lengths kinda seems wrong.

But an interp() function from #6697 that would basically be syntax sugar for calc() then would behave as (2).

[tabatkins]

Yes, it's (1) in this case: each of mix()'s arguments are clamped to allowed range of the context (non-negative). By "expression" I really mean "top-level calculation" and should use that term (and linkify it) instead.

But an interp() function from #6697 that would basically be syntax sugar for calc() then would behave as (2).

Right, if we stayed purely within math functions the clamping wouldn't happen until the end.