On Mon, Mar 24, 2025, 6:20 PM Alex Russell <slightly...@chromium.org> wrote:
> It seems like Jake's concern is well founded. Was this discussed at CSS > WG? Do we understand why this problematic design is going forward in other > engines? It was discussed multiple times with the CSSWG. They seem to believe that the ID-based approach is nice for simple cases. I personally agree with Jake's arguments, but since we had it in the draft and Apple refused the request to unship, I believe that having a non-interoperable support for this feature would be worse than shipping the same thing, while advising people to use the less footgunny match-element which we ship at the same time and Apple has implemented. I wanted to stress that addressing this issue of auto generating names was a repeated request from multiple early adopters of view transitions, and eg React rolled out their own solution to this problem. > Best, > > Alex > > On Monday, March 24, 2025 at 6:30:42 AM UTC-7 Mike Taylor wrote: > >> LGTM2 >> On 3/24/25 4:22 AM, Domenic Denicola wrote: >> >> Thanks for the quick responses! LGTM1. >> >> On Mon, Mar 24, 2025 at 4:37 PM Noam Rosenthal <nrosent...@chromium.org> >> wrote: >> >>> >>> >>> 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/CAM0wra_MKpO5%3DC%2B6O3C6v443Ywr8cjU-rHijm%2BvmZrLob5EW1w%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra_MKpO5%3DC%2B6O3C6v443Ywr8cjU-rHijm%2BvmZrLob5EW1w%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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJn%3DMYb_xqtyotWGQ1RvupmYz65DEG51igYe32qm-YSvBvy%2BTQ%40mail.gmail.com.
