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

_(Writing this comment on my own, but from what I recall about our consensus last time this was brought up)_

> I think there are two reasons to want to keep `calc-size()`:
> 
> 1. it's architecturally not really possible (at least cleanly) to have CSS animations that produce intermediate values that aren't representable in CSS.  ([`mix()`](https://drafts.csswg.org/css-values-5/#mix) provides a future mechanism that makes this at least more palatable than it is today albeit still not ideal, but it's not yet implemented anywhere as far as I know.)
> 2. The [extensible web manifesto](https://extensiblewebmanifesto.org/) gives a number of reasons that we should bias towards exposing the mechanisms underlying things unless we have reasons not to do so; I don't think there's sufficient reason not to expose `calc-size()` here (even if there is good reason to suggest an alternative for a key set of use cases).  (Along these lines, at the CSS face-to-face last week @kizu mentioned having non-animation use cases for `calc-size()`.)

Both of these arguments make the point that intermediate values should be representable in CSS. However, no-one proposed they should not be! Our concern was about introducing a new function to do this whose only purpose seems to be implementation convenience. There does not seem to be _any_ author-facing reason that justifies introducing a distinct `calc-size()` syntax over simply using `calc()`. We listed several issues earlier that make the DX `calc-size()` quite confusing for authors. None of these issues are present when simply reusing `calc()` for this.

We think that reusing `calc()` even with constraints about the number of distinct intrinsic size keywords that can be valid within it would be a far better path forwards for authors: No new function to learn, and they would likely never even hit the limitation. The current state is that no intrinsic size keywords are allowed in `calc()`, so allowing one but no more than that seems like a direct improvement, and leaves the path open for supporting more in the future. 

From our perspective, it seems that the only argument against reusing `calc()` with a limit of one intrinsic keyword max is theoretical purity (that the limitation should be clear from the syntax), which as you know, is at the bottom of the [priority of constituencies](https://www.w3.org/TR/design-principles/#priority-of-constituencies).

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

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