Intent to Ship: view-transition-name: auto

[Vladimir Levin]

Contact emails

vmp...@chromium.org, nrose...@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

Blink component

Blink>ViewTransitions

TAG review

https://github.com/w3ctag/design-reviews/issues/1001

TAG review status

Issues open

Risks

Interoperability and Compatibility

None (if this is shipped)

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)

Web developers: Mixed signals (https://groups.google.com/a/chromium.org/g/blink-dev/c/5LfSXRBkeAY/m/W6n9uWoVBAAJ) This functionality aligns with match-element for MPA cases. However, there is resistance to this as it may generate confusion. Please see the referenced blink-dev discussion for further information. Since this intent is split off from above, the discussion there is relevant including concerns raised around view-transition-name: auto.

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)?

No

Is this feature fully tested by web-platform-tests?

Yes. https://wpt.fyi/results/css/css-view-transitions?label=master&label=experimental&aligned&q=css-view-transitions%2Fauto

Flag name on about://flags

None

Finch feature name

CSSViewTransitionAutoName

Requires code in //chrome?

False

Estimated milestones

Shipping on desktop	137
Shipping on Android	137
Shipping on WebView	137

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

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4850737974345728?gate=5408040196767744

This intent message was generated by Chrome Platform Status.

[Mike Taylor]

LGTM1, even if the name changes from `auto` to something else.

Adding or removing an ID to a dom element (or a class even) may always carry the risk of breaking behavior or styling in a page. Perhaps this is more likely in certain types of apps, perhaps not. I don't think we're treading new ground here.

--
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+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2PXwFZbGR-DqkZue%2BTiTgmWENoQqjN_3Dv-qLyUMEFDpQ%40mail.gmail.com.

[Yoav Weiss (@Shopify)]

I remain unconvinced that the benefits of this feature (the ability to "magically" get transitions across documents) outweigh its ecosystem costs (footgun around the use of IDs, partial application of transitions in the cross-document case).

At the very least, it seems like the name of the feature could have been more explicit than "auto".

On Tuesday, April 1, 2025 at 3:04:30 PM UTC+2 Mike Taylor wrote:

LGTM1, even if the name changes from `auto` to something else.

Adding or removing an ID to a dom element (or a class even) may always carry the risk of breaking behavior or styling in a page. Perhaps this is more likely in certain types of apps, perhaps not. I don't think we're treading new ground here.

On 3/31/25 3:43 PM, Vladimir Levin wrote:

Contact emails

vmp...@chromium.org, nrosenthal...@chromium.org

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Jake Archibald]

My concerns about this are summarised here, and subsequent comments on the thread.

I think this is different to the usual risks around IDs. Usually IDs are referenced directly by their full name, in HTML like <label for="other-element">, in links like #other-element, or in CSS like #other-element. In this case the ID isn't referenced elsewhere.

It is possible to match elements with an ID, such as [id], or partial matches such as [id^=other-], but this is rare.

This feature causes ID to have a behaviour no matter what the value is, and the value doesn't need to be referenced anywhere.

[Jake Archibald]

TAG have switched their resolution to "unsatisfied" when it comes to `auto`. They're happy with `match-element`. https://github.com/w3ctag/design-reviews/issues/1001#issuecomment-2803634513