Re: [w3ctag/design-reviews] CSS calc-size() function (Issue #955)

@hober, @LeaVerou, @plinss, and I discussed this and we have some brief feedback, some of which is really questions.

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 / 2)` 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, modulo the above concern). 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](https://github.com/w3c/csswg-drafts/issues/626#issuecomment-2071016522), 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 /* what is wanted, not animatable */; height: calc(5em * ?) /* approximate the size, but animatable (?) */; height: calc-size(max-content) /* this proposal */;`)

- 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 to just `height: max-content`. The effect here of disabling the animation is not an obvious consequence of that change.


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/955#issuecomment-2121492620
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/955/2121492620@github.com>