Intent to Ship: CSS interpolate-size property and calc-size() function

3,235 views
Skip to first unread message

David Baron

unread,
Jul 15, 2024, 11:23:08 AMJul 15
to blink-dev

Contact emails

dba...@chromium.org

Explainer

https://github.com/w3c/csswg-drafts/blob/main/css-values-5/calc-size-explainer.md

Specification

https://drafts.csswg.org/css-values-5/#calc-size

Summary

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>Layout

TAG review

https://github.com/w3ctag/design-reviews/issues/955

TAG 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/626https://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):
https://blog.kizu.dev/weekly-bookmarks-010/

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)?

Yes

Is this feature fully tested by web-platform-tests?

Yes

https://wpt.fyi/results/css/css-values/calc-size



Flag name on chrome://flags

None

Finch feature name

kCSSCalcSizeFunction

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=313072

Estimated milestones

Shipping on desktop128
DevTrial on desktop123
Shipping on Android128
DevTrial on Android123
Shipping on WebView128

   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.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5196713071738880?gate=5074705734434816

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAG0MU3hBtXebfpW3JSoO-RF43aCCsNK-vZ0uvqoVaBoJbfAT6g%40mail.gmail.com

This intent message was generated by Chrome Platform Status.

Chris Harrelson

unread,
Jul 16, 2024, 2:28:19 PMJul 16
to David Baron, blink-dev
LGTM1!

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAG0MU3jD2mFCzFTJ560acs%3DzFQZEDc8%3Dpos%2B%3DUVZitJ27vfFmg%40mail.gmail.com.

Mike Taylor

unread,
Jul 16, 2024, 2:41:05 PMJul 16
to David Baron, blink-dev, Chris Harrelson

On 7/16/24 2:27 PM, Chris Harrelson wrote:

LGTM1!
I see that most of these tests are marked as tentative - is that intentional, or just needs to be updated?

David Baron

unread,
Jul 16, 2024, 4:11:26 PMJul 16
to Mike Taylor, blink-dev, Chris Harrelson
I suppose mostly the test naming as "tentative" just needs to be updated, but I was planning to do it along with landing the one line changes to the property value definitions (which I mentioned in the "Anticipated spec changes" section of the intent), since technically it's testing stuff that isn't formally required without that.

-David

Mike Taylor

unread,
Jul 22, 2024, 2:34:51 PMJul 22
to David Baron, blink-dev, Chris Harrelson

Got it - thanks.

LGTM2

Domenic Denicola

unread,
Jul 22, 2024, 8:19:18 PMJul 22
to David Baron, blink-dev
Any updates on this anticipated spec change to share?
 
--

David Baron

unread,
Jul 25, 2024, 5:10:38 PMJul 25
to Domenic Denicola, blink-dev
The anticipated spec change is now merged, and the tentative-named WPT tests have been renamed (CL, WPT PR).

-David

Domenic Denicola

unread,
Jul 25, 2024, 8:58:23 PMJul 25
to David Baron, Domenic Denicola, blink-dev
LGTM3
Reply all
Reply to author
Forward
0 new messages