(feature author hat) I'd like to highlight that view-transition-name: auto does have a need in MPA, where match-element cannot match anything across different documents. I agree that the versioning problem that Jake mentioned exists in that case, but it seems similar to any other versioning problem where view-transition-name: <ident> is used to identify paired elements: those may or may not work if the version of the current page matches the version of the next page.
The reason that we're advocating for shipping view-transition-name is in part, as Noam mentioned, interop. The other reason is that it does address a need to automatically match elements based on some criteria across document navigation. Because of this dependence of CSS on HTML, we likely do need documentation that highlights developer care required when changing IDs. However, I still think the value added by the feature exceeds the risks. Thanks, Vlad On Mon, Mar 24, 2025 at 2:31 PM Noam Rosenthal <nrosent...@chromium.org> wrote: > > > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJn%3DMYb_xqtyotWGQ1RvupmYz65DEG51igYe32qm-YSvBvy%2BTQ%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/CADsXd2NJq5G9PspB7EW4kQ3EbqB4PD4oF5uQ%3Du0WBRS2%2BuXVcQ%40mail.gmail.com.
