Intent to Ship: CSS interpolate-size property and calc-size() function
David Baron
Contact emails
dba...@chromium.orgExplainer
https://github.com/w3c/csswg-drafts/blob/main/css-values-5/calc-size-explainer.mdSpecification
https://drafts.csswg.org/css-values-5/#calc-sizeSummary
The CSS interpolate-size property allows a page to opt in to animations and transitions of CSS intrinsic sizing keywords such as auto, min-content, fit-content, etc., in the cases where we can animate those keywords. The CSS calc-size() function is a CSS function similar to calc(), but that also supports operations on exactly one of the values auto, min-content, max-content, fit-content, stretch, or contain. This function is used to represent the values in the middle of the animations allowed by the interpolate-size property.
Blink component
Blink>LayoutTAG review
https://github.com/w3ctag/design-reviews/issues/955TAG review status
Issues open.I think there were two substantive issues that came out of the TAG review, one of which is addressed and one of which we disagree with and is not addressed.
One issue was that the use of the calc-size() function as the recommended opt-in mechanism for animation of sizing keywords was not ideal. This is because of behavior in browsers that don't yet support the feature. Changing the way that the endpoints of the animation are specified breaks not only the animation but also the static behavior before or after the animation, unless authors are careful to use additional fallback declarations with supported values. This was addressed with the somewhat late-breaking addition of a separate opt-in, the interpolate-size property, which was already being discussed for other reasons. This will be the recommended way to opt in to animation of keywords. Some (but probably not all) documentation has been updated to reflect this change. The calc-size() syntax is kept for three reasons: first, that developers have found other useful ways to use it that aren't about animations; second (related to the first) that the extensible web manifesto argues that we should bias towards exposing internal mechanisms unless there's a good reason not to; and third, that it would be difficult architecturally to support CSS animations where the computed value in the middle can't be represented in CSS syntax.
The second issue, where we disagree (see the discussion in the TAG review) is that the TAG thinks that this syntax should be part of the calc() function (with complex limitations on when the sizing keywords can be used) rather than a separate calc-size() function that more clearly presents those limitations.
Risks
Interoperability and Compatibility
No concrete risks. There may be some risk due to the amount of discussion that the feature has had so far, though it has been discussed multiple times in the CSS Working Group, and has had a TAG review. I haven't yet heard back on the standards-positions requests from other vendors, though they've been on file for a few months.
Gecko: No signal (https://github.com/mozilla/standards-positions/issues/1022)
WebKit: No signal (https://github.com/WebKit/standards-positions/issues/348)
Web developers: Positive Animation to/from auto height is a very commonly requested feature by developers. See citations and comments in https://github.com/w3c/csswg-drafts/issues/626, https://issues.chromium.org/40339056, and https://bugzilla.mozilla.org/show_bug.cgi?id=571344.
Also see the following excitement about the feature since prototyping has started (also see boosts and responses):
Other signals:
WebView application risks
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
None
Debuggability
Expected to be similar to existing CSS calc() function.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?
YesIs this feature fully tested by web-platform-tests?
Yeshttps://wpt.fyi/results/css/css-values/calc-size
Flag name on chrome://flags
NoneFinch feature name
kCSSCalcSizeFunctionRequires code in //chrome?
FalseTracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=313072Estimated milestones
| Shipping on desktop | 128 |
| DevTrial on desktop | 123 |
| Shipping on Android | 128 |
| DevTrial on Android | 123 |
| Shipping on WebView | 128 |
Note that the 128 estimate is moderately ambitious, and slipping to 129 may be needed.
Anticipated spec changes
Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).
I still need to land the spec changes formally defining which properties this works on (i.e., the one line change to the value definition of the relevant properties linking to the substantive spec). I hope to do this in the next week or two.