LGTM3 On Fri, Jul 26, 2024 at 6:10 AM David Baron <dba...@chromium.org> wrote:
> The anticipated spec change is now merged > <https://github.com/w3c/csswg-drafts/commit/aa94f650329b2f3096cbeddc6820100b30280baf>, > and the tentative-named WPT tests have been renamed (CL > <https://chromium-review.googlesource.com/c/chromium/src/+/5740910>, WPT > PR <https://github.com/web-platform-tests/wpt/pull/47297>). > > -David > > On Mon, Jul 22, 2024 at 8:19 PM Domenic Denicola <dome...@chromium.org> > wrote: > >> >> >> On Tue, Jul 16, 2024 at 12:23 AM David Baron <dba...@chromium.org> wrote: >> >>> Contact emailsdba...@chromium.org >>> >>> Explainer >>> https://github.com/w3c/csswg-drafts/blob/main/css-values-5/calc-size-explainer.md >>> >>> Specificationhttps://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 componentBlink>Layout >>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ELayout> >>> >>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/955 >>> >>> TAG review statusIssues 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): >>> https://twitter.com/yisibl/status/1791452140663345300 >>> https://twitter.com/Una/status/1791531167558090920 >>> https://front-end.social/@chriscoyier/112575832546969221 >>> https://www.youtube.com/watch?v=1VsMKz4Zweg >>> https://front-end.social/@kizu/112537660977381136 >>> 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 >>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>> ?Yes >>> >>> https://wpt.fyi/results/css/css-values/calc-size >>> >>> >>> Flag name on chrome://flagsNone >>> >>> Finch feature namekCSSCalcSizeFunction >>> >>> Requires code in //chrome?False >>> >>> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=313072 >>> >>> Estimated 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. >>> >> >> Any updates on this anticipated spec change to share? >> >> >>> >>> >>> Link to entry on the Chrome Platform Status >>> https://chromestatus.com/feature/5196713071738880?gate=5074705734434816 >>> >>> Links to previous Intent discussionsIntent 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 >>> <https://chromestatus.com/>. >>> >>> -- >>> 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+unsubscr...@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 >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAG0MU3jD2mFCzFTJ560acs%3DzFQZEDc8%3Dpos%2B%3DUVZitJ27vfFmg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- 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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra9pfQDK7gOW2g%3D7rLJqWArR6ueSouaA1OoaSNfNsMxYbQ%40mail.gmail.com.
