On Mon, Mar 24, 2025 at 5:53 AM Domenic Denicola <dome...@chromium.org> wrote:
> Generally in good shape, but I have questions about potential open spec > issues. > > On Friday, March 21, 2025 at 4:09:17 AM UTC+9 Chromestatus wrote: > > Contact emails nrosent...@chromium.org, vmp...@chromium.org > > Explainer https://github.com/WICG/view-transitions/blob/main/auto- > name-explainer.md > > Specification https://drafts.csswg.org/css-view-transitions-2/#auto-vt- > name > > Summary > > This intent covers two new keywords for view-transition-name: - > 'match-element' generates a unique id based on the element's identity and > renames the same for this element. This is used in Single Page App cases > where the element is being moved around and the desire is to animate it > with a view transition - 'auto' generates a unique id based on the > element's id attribute. This value remains the same for the same ids > regardless of the element, but does not otherwise match the > view-transition-name named with the same ident as the id. This can be used > in both Single and Multi Page Apps to match elements based on their id > attributes. Allow the 'auto' keyword as a value for the > 'view-transition-name' CSS property. This generates a unique name for the > element, and reduces the burden of having to invent unique names for > participating elements. > > > Blink component Blink>CSS > <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ECSS%22> > > TAG review https://github.com/w3ctag/design-reviews/issues/1001 > > TAG review status Issues addressed > > Risks > > > Interoperability and Compatibility > > None > > > I guess there is some small compat risk in that people might have > previously named their view transitions "auto" or "match-element", but > we're hoping that's rare? > `auto` was an invalid value in view-transition-1 for this reason, so `@supports { view-transition-name: auto }` would discover this feature. `match-element` is a small enough compat risk. > > > > *Gecko*: No signal (https://github.com/mozilla/standards-positions/issues/ > 1198) > > *WebKit*: Shipped/Shipping (https://webkit.org/blog/ > 16301/webkit-features-in-safari-18-2) > > > Safari seems to have only shipped "auto" based on that blog post. Do you > know their thoughts on "match-element"? Maybe based on > https://wpt.fyi/results/css/css-view-transitions/match-element-name.html?label=master&label=experimental&aligned > they've also implemented match-element. > They've implemented it already. https://github.com/WebKit/WebKit/pull/35953 > > > *Web developers*: Positive This is a highly requested feature to prevent > the need to uniquely identify each participating view transition element. > > *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 > > None > > > 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-view-transitions/auto- > name-from-id.html?label=experimental&label=master&aligned > https://wpt.fyi/results/css/css-view-transitions/ > navigation/auto-name-from-id.html?label=experimental&label=master&aligned > > > I guess > https://wpt.fyi/results/css/css-view-transitions/match-element-name.html?label=master&label=experimental&aligned > is also relevant. > Right. > > > Flag name on about://flags > > Finch feature name CSSViewTransitionAutoName > > Requires code in //chrome? False > > Tracking bug https://issues.chromium.org/issues/399877975 > > Estimated milestones Shipping on desktop 136 Shipping on Android 136 Shipping > on WebView 136 > > 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). > None > > > Are any of these relevant? > They are, forgot to close some of them :) > > - https://github.com/w3c/csswg-drafts/issues/11614 > > Yes, this one is resolved and implemented. > > - https://github.com/w3c/csswg-drafts/issues/11112 > > A duplicate of the previous one. > > - https://github.com/w3c/csswg-drafts/issues/10995 > > This one is resolved and implemented. Jake Archibald expressed his reservations about the ID behavior after webkit had already shipped. We thought that he had some good points, but since this is already shipped in webkit, I believe that what the working group resolved here <https://github.com/w3c/csswg-drafts/issues/11614> is satisfactory. > > - https://github.com/w3c/csswg-drafts/issues/10978 > > Implemented, now closed. > > > > > Link to entry on the Chrome Platform Status https://chromestatus.com/ > feature/6575974796492800?gate=5170335230722048 > > Links to previous Intent discussions Intent to Prototype: > https://groups.google.com/a/chromium.org/d/msgid/blink- > dev/66fe6d9c.2b0a0220.d54b7.1136.GAE%40google.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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJn%3DMYY7NQmiyREy6%2B6qw6znyx39-DV0zb2xMNB3gU5S%2By1D-A%40mail.gmail.com.
