The example I gave isn't a versioning issue, it results from overloading the id attribute.
The example I gave wouldn't be broken if view-transition-name was given an ident. And it's less likely to happen if the name was pulled from a dedicated attribute eg data-vtn via attr(), since that wouldn't also be used for things like landmark links. My advice to developers would be to avoid `auto`. `match-element` is good for particular SPA (or later, scoped) cases. I'm sad that Apple have forced a wart into this API. On Mon, 24 Mar 2025, 20:04 Vladimir Levin, <vmp...@chromium.org> wrote: > (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 a topic in the > Google Groups "blink-dev" group. > To unsubscribe from this topic, visit > https://groups.google.com/a/chromium.org/d/topic/blink-dev/5LfSXRBkeAY/unsubscribe > . > To unsubscribe from this group and all its topics, 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2NJq5G9PspB7EW4kQ3EbqB4PD4oF5uQ%3Du0WBRS2%2BuXVcQ%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/CAJ5xic-nfvxj_igPSgEb8OXLxSW-Uw1k3Gqvp8ehzhSehXY0xg%40mail.gmail.com.
