[css-values-5] issues with interpolation rules for calc-size()

[dbaron]

The rules for interpolating calc-size() (see #626) currently say:

As well, a calc-size() can be interpolated with a <length-percentage> or an <intrinsic-size-keyword>, behaving as if the second value were calc-size(value).

I see a few issues with this sentence.

First, the expression calc-size(value) at the end doesn't make sense, because calc-size() takes two arguments. I think it might be that what this meant to say is "behaving as if the non-calc-size() value value were calc-size( value , size). But there are other possible options here (although I think they have problems and this one is probably correct).

Second, this sentence seems to imply that all such combinations can be interpolated. It seems to me, particularly if the above interpretation is correct (rather than instead being calc-size(any, value ) for <length-percentage> values), that many such combinations cannot be interpolated, given the rules at the start of the section saying when two calc-size() values can be interpolated.

[tabatkins]

First, the expression calc-size(value) at the end doesn't make sense, because calc-size() takes two arguments.

Nope, it takes one as well:

If only one argument is given, and it’s a <calc-sum>, then the provided argument is the calc-size calculation, and the calc-size basis defaults to any. Otherwise, the provided argument is the calc-size basis, and the calc-size calculation defaults to size.

---

Second, this sentence seems to imply that all such combinations can be interpolated. It seems to me, particularly if the above interpretation is correct (rather than instead being calc-size(any, value ) for values), that many such combinations cannot be interpolated, given the rules at the start of the section saying when two calc-size() values can be interpolated.

Right, it's meant to defer to that preceding section, which gives the behavior when you have two calc-size()s. That might indeed mean that they end up not being interpolable. How could I make this more clear?

[dbaron]

Ah, ok. This is what happens when the spec gets written halfway through the implementation and I don't carefully reread all the bits I've already implemented before the spec existed.

That said, the behavior specified here behaves weirdly for percentages -- an animation between 100% and calc-size(fit-content) possibly (though not clearly!) has percentageness at one endpoint of the animation, but doesn't have percentage-ness at any intermediate point nor at the other endpoint. (Chromium code has a DCHECK() asserting that this doesn't happen, which is what led me to this issue in the first place.)

As to clarifying the sentence to be clearer, how about (ignoring any of the other issues):

Some calc-size() values can also be interpolated with a <length-percentage> or an <intrinsic-size-keyword>. To determine whether the values can interpolate and what the interpolation behavior is, treat the non-calc-size() value value as calc-size( value ) and apply the rules above.

[tabatkins]

That said, the behavior specified here behaves weirdly for percentages -- an animation between 100% and calc-size(fit-content) possibly (though not clearly!) has percentageness at one endpoint of the animation, but doesn't have percentage-ness at any intermediate point nor at the other endpoint.

Right, but the alternative is that that value pair doesn't interpolate at all, because it's two different intrinsic behaviors. I decided it was more useful to allow it to work in the case where the % is resolving against a definite size, than to strictly preserve percent-ness when auto-upgrading percentages into calc-size() (which would usually just fail to transition at all).

As to clarifying the sentence to be clearer, how about (ignoring any of the other issues):

Yeah, that suggested text sounds good, thanks!

[dbaron]

One other issue with the rules is that they have frequent references to "the result’s calc-size basis". However, it's not clear to me whether this is intended to recursively extract the basis. For example, can you interpolate between calc-size(calc-size(min-content, size * 0.5), size * 0.5) and calc-size(min-content, size)?

My understanding is the intent of allowing calc-size() values as the basis was to allow this sort of thing. However, I think a literal reading of the spec currently doesn't allow it.

Then the question is: if it is allowed, is the correct interpolation behavior to un-nest the calc-size() expression by substituting for the size in the outer expression's calculation, or is it to separately interpolate the calculation and the basis? (The resulting behavior is different for the interpolation above: with substitution the midpoint of the interpolation would be calc-size(min-content, size * 0.625) whereas with separate interpolation the midpoint would be calc-size(calc-size(min-content, size * 0.75), size * 0.75) which is equivalent to calc-size(min-content, size * 0.5625).)

(I suppose one could ask the same question about the rules for interpolation when the basis is a <calc-sum>.)

[tabatkins]

My understanding is the intent of allowing calc-size() values as the basis was to allow this sort of thing. However, I think a literal reading of the spec currently doesn't allow it.

Ooh, you're right, it looks like I lost the text for this when moving it from the issue to the spec. I'll fix; the intent is indeed that the basis is recursive.

if it is allowed, is the correct interpolation behavior to un-nest the calc-size() expression by substituting for the size in the outer expression's calculation, or is it to separately interpolate the calculation and the basis?

The behavior I want to preserve is that the obvious "simplification" one can theoretically do (ignoring, for the moment, billion laughs) results in identical behavior. In other words, calc-size(calc-size(min-content, size+20px), size * .5) and calc-size(min-content, (size + 20px) * .5) should act exactly the same. (Actually un-nesting subjects you to expansion attacks, but a stacked set of equations, each resolving to provide the size value for the next, works.)

The other behavior I want to preserve is that calc-size() interpolation is always linear - whatever size the endpoints resolve to, the interpolation acts as if you're just going between those two sizes. The above condition preserves this, tho I suddenly realize my interpolation rules for a len-per basis violate it - going from calc-size(100%, size) to calc-size(0px, 0px) will interpolate quadratically.

This is fixable, tho. I think what I want to do is, effectively, to pretend that a calc-size() with a len-per basis is already a "nested" calc-size, so I can move the actual len-per calculation into the sum argument. In other words, calc-size(10% + 20px, size * .5) should be equivalent to calc-size(calc-size(hundred-percent, (size * .1 + 20px)), size * .5), where hundred-percent is a pretend keyword that means "whatever 100% would resolve to". Very possibly I should actually define that keyword, in fact, so I can make the equivalency easier to talk about.

Does this sound reasonable? Both the "sequence of calculations" un-nesting concept, and the application of that to a len-per basis? Thoughts on actually defining a keyword for a percentage basis?

[tabatkins]

Very possibly I should actually define that keyword, in fact, so I can make the equivalency easier to talk about.

I know I thought of doing this early in the design, actually, I just thought it was awkward to have to write calc-size(percent, size * .1 + 20px) vs just being able to do calc-size(10% + 20px, size). Don't know why I didn't think of just treating the one as the other, tho.

It's possible I might be able to combine the approaches, tho, and say that calc-size(percent, 10% + 20px) resolves the 10% against the percent size even when it's indefinite (as opposed to the standard behavior, where an indefinite % resolves against 0). I'd have to be a little careful to not accidentally imply that calc-size(calc-size(percent, 10%), 20%) resolves both %s against the indefinite percentage size, tho; that seems tricky to write since the basis is recursive. :/ Probably I just shouldn't do that.

[tabatkins]

Wait, damn, I actually still lose linear interpolation in this model; the spec specifies that you interpolate the basises. And I can't just naively expand the nested function into the outer one, even if I made "sequence of calculations" actually valid in the grammar, because both sides of the interpolation might have this.

Example:
Imagine you're interpolating from calc-size(calc-size(auto, size * .5), size * .5) to calc-size(calc-size(auto, size + 100px), size * 2), and the auto size is 200px.

The first will result in a final size of 50px (200px * .5 * .5). The second will result in 600px (200px + 100px * 2). Ideally we want the halfway point of the interpolation to be halfway between these two, at 325px. But how do we represent that?

We don't get that result in the current spec text; current spec tells us to interpolate the basis and the calculation, resulting in (after simplification) calc(calc-size(auto, size * .75 + 50px), size), or 200px.

What we want is to produce some form where only the final calculation is what's interpolated, so we don't get the double-interpolation quadratic behavior.

A failed attempt I made just now was to allow "sequence of calculations" to be expressed directly in the syntax, but that still runs us into issues - simplifying into calc-size(auto, size * .5, size * .5) and calc-size(auto, size + 100px, size * 2) still doesn't give us a way to represent the intermediate value.

I think what we actually need is the ability to represent a calculation sequence as a first-class concept. Let's pretend that calc-seq(<calc-sum>#) exists, representing the result of resolving each item in order, and making the previous result available to the next calculation via a result keyword.

Then we can instead simplify the functions to calc-size(auto, calc-seq(size * .5, result * .5)) and calc-size(auto, calc-seq(size + 100px, result * 2)). The interpolated value would then be calc-size(auto, calc-seq(size * .5, result * .5) * .5 + calc-seq(size + 100px, result * 2) * .5).

That final calculation, then (again assuming the auto size is 200px) would be 50px * .5 + 600 * .5, exactly the 325px we needed.

We don't necessarily need to make this a generic functionality; we could specialize it to calc-size() if we wanted, since we don't need it anywhere else so far. But if we eat the complexity of a calc sequence here, seems like we might as well do it generally anyway.

[tabatkins]

All right, sorry, let's restate the important parts from these stream-of-consciousness posts.

1. A calc-size() with a nested calc-size() as its basis needs to use the nested function's basis, recursively.
2. When interpolating, we want the final result of the calc-size() functions to be what's interpolated, so you get linear behavior. If we interpolate the basis and the calculation, you get quadratic behavior instead, which is very undesirable.
3. Given current syntax abilities, the only way to achieve (2) is to effectively push any basis calculations into the calculation argument; aka simplifying calc-size(calc-size(min-content, size * .5), size * .2) into calc-size(min-content, size * .1).
4. But that opens us up to expansion attacks (see Oriol's comment), so we actually need to preserve the calculations separately and just evaluate them in sequence, feeding each result to the next.
5. So we actually need to reify the concept of "calculation sequences", so we can safely define the simplification from (3), and then actually interpolate that.
6. And also, using a length-percentage as the basis has the same interpolation issues as a nested calc-size().

Proposal:

1. Introduce the concept of "calculation sequences", either as a new function (calc-seq()?) or just by allowing calc() to take a comma-separated list of calculations. In a sequence, all the calculations past the first have access to a result variable, which represents the result of the preceding calculation. The function ultimately represents the result of the last calculation.
2. Specify that nested calc-size() is simplified by un-nesting, using the nested basis as the outer basis and combining the nesting calculation with the outer calculation using a sequence. So calc-size(calc-size(min-content, size * .5), size * .2) simplifies to calc-size(min-content, calc(size * .5, result * .2)).
3. Specify that a length-percentage basis simplifies in a similar way, using a new percent keyword to represent a 100% size (which might be indefinite). So calc-size(75%, size + 20px) "simplifies" to calc-size(percent, calc(size * .75, result + 20px)).
4. Change interpolation to solely interpolate the calculation, after ensuring the basises match (or one of them is none).

This gives us linear interpolation in all cases, and slightly simplifies the spec text around nested calc-size() or percentage basises.

[dbaron]

I expect to have more thoughts on this later... but a first thought:

What was the use case for allowing an innercalc-size() to be the basis of an outer calc-size() expression? Is it a strong enough use case to justify all of this?

[tabatkins]

The use-case is calc-size(var(--foo), size). It would be somewhat unfortunate if that worked unless you happened to store a calc-size() in that variable, when there's a perfectly reasonable interpretation of what that would mean.

I also suspect that "stacked calculations" is probably something that might end up being useful in the future. At least, the concept of "store a sub-calculation in a local variable so you can use it repeatedly" has already been brought up in other issues (like calc(--pi 3.14159, 2 * --pi) or something); this would just be doing that in an unnamed/implicit fashion.

[tabatkins]

Alternate proposal: instead of doing the stacked computations to avoid blowout, just substitute directly and allow UAs to fail if the substitution gets too large. That's what we already do with variables, after all. If it gets "too large" just treat the property as IACVT. That way we don't have to invent anything new.

In other words, calc-size(calc-size(min-content, size + 50px), size + size) would canonicalize to calc-size(min-content, (size + 50px) + (size + 50px)).

[dbaron]

Yeah, I think that sounds fine, at least for now.

[dbaron]

So I've mostly implemented that in Chromium in this CL, with the exception of the expansion failure cases. I didn't see a clean way to make them IACVT. Instead, they result in a 0 length. That's probably not ideal. With not too much more work I think I could make them instead fail to interpolate, though. But it's not clear to me if there's a good way to make the animation system say that an interpolation result is IACVT in a case where we have said that the values can be interpolated.

[tabatkins]

I think that's fine; this is already an extreme corner case. I'm happy to spec whatever is reasonable to fall out of that case. I'll open a more general issue for IACVT-in-animations, just in case.

[tabatkins]

Okay, I added simplification rules:

• if your basis is a calc-size(), we sub the nested calculation into the outer one
• if your basis is a length-percentage, we sub it directly into the calculation argument, replacing the percentages with (size * N)
• If substitution would make a too-long value (billion-laughs attack), the property is IACVT.

The interpolation rules have been slightly simplified, as a result, since now the basis is always a keyword by computed-value time.

Notably, this now means that interpolation is properly linear at all times (there's a details in the spec with an example of how it's non-linear if you don't substitute).

And per #10369, Brian also agrees that if the interpolated value would be IACVT, it should fall back to a discrete transition.

[dbaron]

If substitution would make a too-long value (billion-laughs attack), the property is IACVT.

Are there cases where substitution is needed other than interpolation? In other words, why does anything ever need to be IACVT here if we decide that values where interpolation would lead to too long a value can't be interpolated?

[tabatkins]

No, there's not; the substitution behavior is necessary solely to produce linear interpolation behavior. So we could limit it solely to interpolation. I'm just generally inclined to do these sorts of canonicalization more eagerly.