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

My current thinking is that I'd like to do the following:
* support both `interpolate-size` (as resolved last week in https://github.com/w3c/csswg-drafts/issues/10294) and `calc-size()` syntax
* when describing and documenting the animation use cases, recommend `interpolate-size` (and use `interpolate-size` as the primary name of the feature, e.g., updating the explainer, updating the chromestatus entry, using it primarily blog posts)
* document that `calc-size()` is used to represent the intermediate values in animations with keyword endpoints.

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()`.)

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

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