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/CAG0MU3jp-AZOTG1%2BRFQBD_qA7o-2zdd2NY-RmqYZh_e2bTfPsA%40mail.gmail.com.

Reply via email to