We have several concerns with the design of this function:

• If calc-size() returns a <length>, what prevents authors from doing something like calc( ( calc-size(min-content) + calc-size(max-content) ) / 2 ) which seems to be the very thing it was designed to prevent? If that is invalid, it seems like a footgun, since these lengths are often passed around in variables, so the error will not be immediately obvious. And if it’s invalid, it begs the question, how is this better than making calc(min-content + max-content / 2) invalid while calc(min-content) or calc(max-content / 2) are individually valid.

• We are concerned with adding a parallel function to CSS that is identical to calc() with the only exception being that it supports an intrinsic sizing keyword. We think that simply allowing keywords in calc() would have been a better design, even if only one keyword type is supported and it becomes invalid when more than one are used (going from 0 to 1 is still an improvement!). This leaves the door open for supporting more keywords in the future, it means all other math functions that support <calc-sum> (such as clamp()) also support intrinsic sizing keywords, and does not increase the API surface authors need to learn (especially since we suspect it’s unlikely they would ever hit that restriction).

• Looking at the (great) compat analysis, it seems unclear whether this would be a net negative. As @dbaron points out, in most of these cases the result is either an improvement, or a very slight glitch. We are not sure that the reduction in ergonomics that something like calc-size() causes is clearly warranted from this data. But even it were, is introducing a new calc() function the best way to address it? E.g. there are other cases where transitions need to customize the interpolation on a value type-specific basis, e.g. color space for <color> transitions, perhaps some kind of per-transition/animation opt-in would be more palatable?

• We have concerns about backward compatability. E.g. if an author specifies height: calc-size(max-content) (or height: calc(max-content)) then a UA that doesn't support the new behavior loses the height property, requiring the author to specify height twice (or more: height: max-content; height: calc(5em * ?) /*approximate*/; height: calc-size(max-content);)

• Using a calc a function to opt-in to animation behavior doesn't seem readable. A different author seeing height: calc-size(max-content) will not necessarily understand the purpose of the function and may want to remove it (resulting in just height: max-content), disabling the animation.

Response:

We think that calc-size() is simply unreadable as a signal of intent. The purpose of the signal and how it is spelled don't align. That's a problem when it is a singular opt-in. Adding alternative opt-in mechanisms is - as you say - poor. If we were to add something to transition-behavior, then that's extra noise. Adding redundant opt-in mechanisms (when this is already redundant) is probably worse.

We note that people have explicitly requested animation/transitions in the bustage cases you found. Your assertion is that it is too disruptive to deliver those animations, despite them being requested explicitly. We have to accept that there are cases where transitions were specified and JS was used to cover for it not working, so that the result ends up being terrible.

So really what we're talking about is how we're managing this compatibility problem. We'd like to see the opt-in being disconnected from the functionality so that there is some flexibility in how implementers approach the problem, rather than having it an intrinsic property that is therefore impossible to disengage. Maybe some browser would prefer to YOLO this one, which we might find to be OK. Though poor, a separate keyword (on transition-behavior and friends) might be better, despite how ugly it is.

Answered David's question, will see how things play out.

Invited Tab et al to a breakout