Intent to Ship: Auto-generated view transition names

[Chromestatus]

Contact emails

nrose...@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

TAG review

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

TAG review status

Issues addressed

Risks

Interoperability and Compatibility

None

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

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

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

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.

[Domenic Denicola]

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 nrose...@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

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?

 

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.

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

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?

• https://github.com/w3c/csswg-drafts/issues/11614
• https://github.com/w3c/csswg-drafts/issues/11112
• https://github.com/w3c/csswg-drafts/issues/10995
• https://github.com/w3c/csswg-drafts/issues/10978

[Noam Rosenthal]

On Mon, Mar 24, 2025 at 5:53 AM Domenic Denicola <dom...@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 nrose...@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

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? 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 is satisfactory.

 

• https://github.com/w3c/csswg-drafts/issues/10978

Implemented, now closed.

[Domenic Denicola]

Thanks for the quick responses! LGTM1.

[Jake Archibald]

I think `view-transition-name: auto` is poorly designed. It's an invitingly-named value that comes with footguns, and introduces unnecessary behavioural differences between cross-document and same-document transitions.

`view-transition-name: auto` is basically `view-transition-name: match-element` with an added behaviour where it takes the 'name' from the element's ID if it's available.

Imagine a case where there's a list of items, where the first is the main one (bigger in size). The developer wants to create a transition where the items reorder. They use the inviting `auto` keyword, and everything seems to work (it's only using the match-element part of the feature)! Then later, another developer comes along and, in the process of added skip-links, makes sure that the first element in the list has a particular ID. This takes priority over the match-element behaviour, and the transition is broken.

With larger SPAs, it's common to use an MPA navigation rather than SPA if you know there's a newer version of the site available. View transitions were designed with this in mind, as view-transition-name names work just as well across documents as same document. However, if folks use the inviting `auto` keyword, they'll get a cross-document transition that seems to half-work (depending on what IDs are coincidently there), and is likely to be broken in future (developers add and remove IDs to cater for unrelated features, such as ARIA, links, commandFor etc etc).

Safari shipped this while these concerns were being raised in the CSSWG. It's sad to see Chrome joining in shipping such obvious footguns. I hope at the very least that documentation alerts developers to these gotchas.

`view-transition-name: match-element` is fine, as its name more clearly expresses what it does, and documentation can be clear that it doesn't work for cross-document transitions. Dev tools can even warn when match-element is used during a cross-document transition.

Jake.

[Mike Taylor]

LGTM2

--
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/CAM0wra_MKpO5%3DC%2B6O3C6v443Ywr8cjU-rHijm%2BvmZrLob5EW1w%40mail.gmail.com.

[Alex Russell]

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?

Best,

Alex

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

[Noam Rosenthal]

On Mon, Mar 24, 2025, 6:20 PM Alex Russell <sligh...@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

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

[Vladimir Levin]

(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

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJn%3DMYb_xqtyotWGQ1RvupmYz65DEG51igYe32qm-YSvBvy%2BTQ%40mail.gmail.com.

[Jake Archibald]

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.

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

[Jake Archibald]

Let me try and explain the breaking case again. I'll describe it in terms of a React component for brevity, but the same issue exists with regular DOM.

Here's a basic list of items, with a button that randomises the order of the list. This is one of the main use-cases given for this feature.

export const ListOfStuff = () => {
  const [items, setItems] = useState([
    { imgSrc: '…', alt: '…' },
    // …
  ]);

  const onButtonClick = () => {
    document.startViewTransition(() => {
      flushSync(() => {
        const newItems = items.slice();
        randomSortArray(newItems);
        setItems(newItems);
      });
    });
  };

  return (
    <div>
      <ul class="list-of-stuff">
        {items.map(({ imgSrc, alt }) => (
          <li key={imgSrc}>
            <img src={imgSrc} alt={alt} />
          </li>
        ))}
      </ul>
      <button onClick={onButtonClick}>Randomise!</button>
    </div>
  );
};

And let's make this all work with this new enticing feature:

.list-of-stuff > li {
  view-transition-name: auto;
}

It works! Each item moves from its old position to its new position.

But then, sometime later, another developer on the project wants to be able to link folks to the first item of the list (it's displayed bigger, as if it was the main item). That's a small and easy change!

export const ListOfStuff = () => {
  // …as before…

  return (
    <div>
      <ul class="list-of-stuff">
        {items.map(({ imgSrc, alt }, i) => (
          <li key={imgSrc} id={i === 0 ? 'first-stuff-item' : undefined}>
            <img src={imgSrc} alt={alt} />
          </li>
        ))}
      </ul>
      <button onClick={onButtonClick}>Randomise!</button>
    </div>
  );
};

The developer is smart and careful, so they check that `first-stuff-item` isn't used elsewhere on the page, or even in the codebase, which it isn't.

But, they just broke the transition. It isn't totally broken, parts of it still kinda work, but it doesn't look right. Specifically, three of the items no longer move, they just fade.

This isn't anything to do with the old version of the page being different to the new version. This is an SPA so it's all the same version.

The problem is that, with view-transition-name: auto, adding an ID has a behavioural side effect. It now tells the view transition that the first item in the list is the same either side of the transition. It overrides element equality.

Until this feature (correct me if I'm wrong), adding a unique ID to an element was safe. With this feature, that's no longer the case. This is a pretty big change for the platform, and I don't see the benefit.

This issue wouldn't happen if any of the following was done instead:

• Each element was assigned a unique view-transition-name ident
• view-transition-name: match-element was used. It doesn't do anything with the ID attribute.
• Each element was given a unique data-vtn attribute, and view-transition-name: attr(data-vtn type(<custom-ident>)) - this is ok because it isn't overloading an existing attribute with new behaviours, and developers can easily search the codebase for data-vtn to see how it's used.

This is in addition to the issues around the API behaving differently between same-document and cross-document transitions. This is fine with match-element, as it simply doesn't work cross-document, and the browser could warn developers if they try to use it. Whereas view-transition-name: auto is intended to sort-of work cross-document, but will not give the same results as a same-document transition.

I'm sad that the reasoning given for shipping this is "well, Apple just went ahead and shipped it so I suppose we should too".

[Jake Archibald]

On Tue, 25 Mar 2025 at 10:31, Yoav Weiss <yoav....@shopify.com> wrote:

On Tuesday, March 25, 2025 at 5:12:17 AM UTC-4 Jake Archibald wrote:

This issue wouldn't happen if any of the following was done instead:

• Each element was assigned a unique view-transition-name ident
• view-transition-name: match-element was used. It doesn't do anything with the ID attribute.
• Each element was given a unique data-vtn attribute, and view-transition-name: attr(data-vtn type(<custom-ident>)) - this is ok because it isn't overloading an existing attribute with new behaviours, and developers can easily search the codebase for data-vtn to see how it's used.

Were any of these alternatives considered?

To be clear, all of those are already possible. Developers just have to use one of those options rather than `view-transition-name: auto`. The existence of `view-transition-name: auto` misdirects them to a solution that will give them tricky problems later.

[Noam Rosenthal]

Until this feature (correct me if I'm wrong), adding a unique ID to an element was safe. With this feature, that's no longer the case. 

This seems like a worthwhile question to bring back to the TAG and/or the CSSWG. Looking at the TAG review, it doesn't seem like it was discussed.

Happy to take this back to TAG, but would defer to Vlad for next steps.

Not counting on this leading to anything actionable though as Apple were very adamant about keeping things as is in the last few discussions about this,

following the CSSWG process that things can stay in the spec unless there is a consensus to remove them.

This should 100% not be the reasoning for shipping a feature we think is bad.

If API owners think that this is "bad" then we definitely shouldn't ship it, or ship only match-element which everyone seems to agree on.

I would describe this as "not ideal" and that keeping interop on this is the lesser evil.

 

Are we seeing real-life interop pressure? How many sites are already using `auto`? What's the user experience in Chromium for ones that do?

It's not an existing backwards compat issue. But we'd be introducing a slight inconsistency from the get go which IMO is arguably worse than shipping the whole thing.

As a web developer I'd probably end up being confused by this whole thing if Webkit and chromium end up shipping something slightly different with a lack of consensus attached to it.

 

[Jake Archibald]

I've summarised the issues with this proposal in the TAG thread.

[Vladimir Levin]

I'm not convinced this is a huge footgun. Yes, it's a convenience value that allows auto matching in MPA where there is no other way to automatically match without changes to the dom (for a custom attribute). Doing these modification is not far from just giving unique names to view-transition-name, albeit with less typing.

Is it perfect? No. I suspect that the dynamic id case that Jake gave in conjunction with auto naming is the only problematic case in that the transition won't match to what the author may want (although it's also wrong to say it isn't what they want -- it's something of which they have to be cognizant). 

I agree with Noam that the discrepancy in Interop is likely cause more confusion in these cases. I'm not using Interop as justification for shipping this, but only pointing out that IMHO the problem with auto is not as severe as described in this thread.

As for the next steps, I'm fine with continuing the discussion with TAG. With respect to CSSWG, my sense is that the discussion in this thread won't sway the decision.

I'd like to understand what decision we would make here if TAG agrees with Jake's concern. Again to reiterate, the concern is valid, but is the risk of this developer confusion great enough to prevent us from adding this feature?

Thanks,

Vlad

[Yoav Weiss]

On Tuesday, March 25, 2025 at 5:12:17 AM UTC-4 Jake Archibald wrote:

This seems like a worthwhile question to bring back to the TAG and/or the CSSWG. Looking at the TAG review, it doesn't seem like it was discussed.

I agree with Jake that this is a huge footgun.

 

This is a pretty big change for the platform, and I don't see the benefit.

This issue wouldn't happen if any of the following was done instead:

• Each element was assigned a unique view-transition-name ident
• view-transition-name: match-element was used. It doesn't do anything with the ID attribute.
• Each element was given a unique data-vtn attribute, and view-transition-name: attr(data-vtn type(<custom-ident>)) - this is ok because it isn't overloading an existing attribute with new behaviours, and developers can easily search the codebase for data-vtn to see how it's used.

Were any of these alternatives considered?

 

This is in addition to the issues around the API behaving differently between same-document and cross-document transitions. This is fine with match-element, as it simply doesn't work cross-document, and the browser could warn developers if they try to use it. Whereas view-transition-name: auto is intended to sort-of work cross-document, but will not give the same results as a same-document transition.

I'm sad that the reasoning given for shipping this is "well, Apple just went ahead and shipped it so I suppose we should too".

This should 100% not be the reasoning for shipping a feature we think is bad.

Are we seeing real-life interop pressure? How many sites are already using `auto`? What's the user experience in Chromium for ones that do?

[Yoav Weiss (@Shopify)]

On Tue, Mar 25, 2025 at 10:37 AM Vladimir Levin <vmp...@chromium.org> wrote:

I'm not convinced this is a huge footgun. Yes, it's a convenience value that allows auto matching in MPA where there is no other way to automatically match without changes to the dom (for a custom attribute). Doing these modification is not far from just giving unique names to view-transition-name, albeit with less typing.

Is it perfect? No. I suspect that the dynamic id case that Jake gave in conjunction with auto naming is the only problematic case in that the transition won't match to what the author may want (although it's also wrong to say it isn't what they want -- it's something of which they have to be cognizant). 

I agree with Noam that the discrepancy in Interop is likely cause more confusion in these cases. I'm not using Interop as justification for shipping this, but only pointing out that IMHO the problem with auto is not as severe as described in this thread.

As for the next steps, I'm fine with continuing the discussion with TAG. With respect to CSSWG, my sense is that the discussion in this thread won't sway the decision.

I'd like to understand what decision we would make here if TAG agrees with Jake's concern. Again to reiterate, the concern is valid, but is the risk of this developer confusion great enough to prevent us from adding this feature?

I don't think the risk here is developer confusion. The risk is that adding a unique ID attribute becomes an unsafe operation.

That would mean that e.g. CMSes that have multiple actors contributing code to the page (e.g. the developer, the theme and plugins) would now need to police/prevent all actors from using `view-transition-name: auto` because some combinations of code would result in weird and hard to figure-out bugs.

That seems like a fundamental shift, which I'd argue we need to make only if we have very good reasons to go that path.

On the front of interop risk of not shipping this - what happens today if developers are using `auto`? Do we expect them to feature detect it? And if so, what do we expect them to do in the fallback case? 

 

Thanks,

Vlad

On Tue, Mar 25, 2025, 7:37 a.m. Jake Archibald <jaffat...@gmail.com> wrote:

I've summarised the issues with this proposal in the TAG thread.

On Tue, 25 Mar 2025 at 10:44, Noam Rosenthal <nrose...@chromium.org> wrote:

Until this feature (correct me if I'm wrong), adding a unique ID to an element was safe. With this feature, that's no longer the case. 

This seems like a worthwhile question to bring back to the TAG and/or the CSSWG. Looking at the TAG review, it doesn't seem like it was discussed.

Happy to take this back to TAG, but would defer to Vlad for next steps.

Not counting on this leading to anything actionable though as Apple were very adamant about keeping things as is in the last few discussions about this,

following the CSSWG process that things can stay in the spec unless there is a consensus to remove them.

This should 100% not be the reasoning for shipping a feature we think is bad.

If API owners think that this is "bad" then we definitely shouldn't ship it, or ship only match-element which everyone seems to agree on.

I would describe this as "not ideal" and that keeping interop on this is the lesser evil.

 

Are we seeing real-life interop pressure? How many sites are already using `auto`? What's the user experience in Chromium for ones that do?

It's not an existing backwards compat issue. But we'd be introducing a slight inconsistency from the get go which IMO is arguably worse than shipping the whole thing.

As a web developer I'd probably end up being confused by this whole thing if Webkit and chromium end up shipping something slightly different with a lack of consensus attached to it.

 

--

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/CADsXd2NQKc%2Bh_JK4sDxYKN0YDLJbff8qL1facbxZipvsYw0v2Q%40mail.gmail.com.

[Mike Taylor]

On 3/25/25 1:39 PM, Yoav Weiss (@Shopify) wrote:

On Tue, Mar 25, 2025 at 10:37 AM Vladimir Levin <vmp...@chromium.org> wrote:

I'm not convinced this is a huge footgun. Yes, it's a convenience value that allows auto matching in MPA where there is no other way to automatically match without changes to the dom (for a custom attribute). Doing these modification is not far from just giving unique names to view-transition-name, albeit with less typing.

Is it perfect? No. I suspect that the dynamic id case that Jake gave in conjunction with auto naming is the only problematic case in that the transition won't match to what the author may want (although it's also wrong to say it isn't what they want -- it's something of which they have to be cognizant). 

I agree with Noam that the discrepancy in Interop is likely cause more confusion in these cases. I'm not using Interop as justification for shipping this, but only pointing out that IMHO the problem with auto is not as severe as described in this thread.

As for the next steps, I'm fine with continuing the discussion with TAG. With respect to CSSWG, my sense is that the discussion in this thread won't sway the decision.

I'd like to understand what decision we would make here if TAG agrees with Jake's concern. Again to reiterate, the concern is valid, but is the risk of this developer confusion great enough to prevent us from adding this feature?

I don't think the risk here is developer confusion. The risk is that adding a unique ID attribute becomes an unsafe operation.

In my experience, there's always a non-zero specificity foot gun risk for non-trivial sites, depending on how your CSS is written (or more likely, legacy of CSS you inherited). It sucks when you run into it, but I don't think this change is novel in that sense.

[Vladimir Levin]

On Tue, Mar 25, 2025 at 1:52 PM Mike Taylor <mike...@chromium.org> wrote:

On 3/25/25 1:39 PM, Yoav Weiss (@Shopify) wrote:

On Tue, Mar 25, 2025 at 10:37 AM Vladimir Levin <vmp...@chromium.org> wrote:

I'm not convinced this is a huge footgun. Yes, it's a convenience value that allows auto matching in MPA where there is no other way to automatically match without changes to the dom (for a custom attribute). Doing these modification is not far from just giving unique names to view-transition-name, albeit with less typing.

Is it perfect? No. I suspect that the dynamic id case that Jake gave in conjunction with auto naming is the only problematic case in that the transition won't match to what the author may want (although it's also wrong to say it isn't what they want -- it's something of which they have to be cognizant). 

I agree with Noam that the discrepancy in Interop is likely cause more confusion in these cases. I'm not using Interop as justification for shipping this, but only pointing out that IMHO the problem with auto is not as severe as described in this thread.

As for the next steps, I'm fine with continuing the discussion with TAG. With respect to CSSWG, my sense is that the discussion in this thread won't sway the decision.

I'd like to understand what decision we would make here if TAG agrees with Jake's concern. Again to reiterate, the concern is valid, but is the risk of this developer confusion great enough to prevent us from adding this feature?

I don't think the risk here is developer confusion. The risk is that adding a unique ID attribute becomes an unsafe operation.

In my experience, there's always a non-zero specificity foot gun risk for non-trivial sites, depending on how your CSS is written (or more likely, legacy of CSS you inherited). It sucks when you run into it, but I don't think this change is novel in that sense.

That would mean that e.g. CMSes that have multiple actors contributing code to the page (e.g. the developer, the theme and plugins) would now need to police/prevent all actors from using `view-transition-name: auto` because some combinations of code would result in weird and hard to figure-out bugs.

That seems like a fundamental shift, which I'd argue we need to make only if we have very good reasons to go that path.

On the front of interop risk of not shipping this - what happens today if developers are using `auto`? Do we expect them to feature detect it? And if so, what do we expect them to do in the fallback case? 

Currently in Blink, use of auto would have no effect as it is a reserved keyword (in `view-transition-name`) and would not act as a custom ident.

With respect to fallbacks: 

In the MPA cases, `view-transition-name` matching, without `auto`, can only happen by idents. To avoid the need to code unique names in CSS, the developer can write something along the lines of `view-transition-name: attr(id type(<custom-ident>))` or `view-transition-name: attr(data-vtn type(<custom-ident>))` as Jake suggested. Of course, if they choose `id` as the attribute to mirror, it would be exactly the same as saying `auto` with all the same concerns for multiple developers stepping on each others' toes.

 

In SPA cases, I imagine `match-element` suffices, unless the author explicitly wants the `auto` behaviour of prioritizing `id` and falling back to `match-element`, in which case they can write something like `view-transition-name: attr(id type(<custom-ident>), match-element)`. The latter may be a valid case for situations in which DOM is recycled

Thanks,

Vlad

 

Thanks,

Vlad

On Tue, Mar 25, 2025, 7:37 a.m. Jake Archibald <jaffat...@gmail.com> wrote:

I've summarised the issues with this proposal in the TAG thread.

On Tue, 25 Mar 2025 at 10:44, Noam Rosenthal <nrose...@chromium.org> wrote:

Until this feature (correct me if I'm wrong), adding a unique ID to an element was safe. With this feature, that's no longer the case. 

This seems like a worthwhile question to bring back to the TAG and/or the CSSWG. Looking at the TAG review, it doesn't seem like it was discussed.

Happy to take this back to TAG, but would defer to Vlad for next steps.

Not counting on this leading to anything actionable though as Apple were very adamant about keeping things as is in the last few discussions about this,

following the CSSWG process that things can stay in the spec unless there is a consensus to remove them.

This should 100% not be the reasoning for shipping a feature we think is bad.

If API owners think that this is "bad" then we definitely shouldn't ship it, or ship only match-element which everyone seems to agree on.

I would describe this as "not ideal" and that keeping interop on this is the lesser evil.

 

Are we seeing real-life interop pressure? How many sites are already using `auto`? What's the user experience in Chromium for ones that do?

It's not an existing backwards compat issue. But we'd be introducing a slight inconsistency from the get go which IMO is arguably worse than shipping the whole thing.

As a web developer I'd probably end up being confused by this whole thing if Webkit and chromium end up shipping something slightly different with a lack of consensus attached to it.

 

--
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/CADsXd2NQKc%2Bh_JK4sDxYKN0YDLJbff8qL1facbxZipvsYw0v2Q%40mail.gmail.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+...@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/54fc599d-3e1a-4d0b-88c5-4a2db9f93410%40chromium.org.

[Alex Russell]

It's unconvincing re: deprecation risk that Apple has decided in the short run that they don't want to unship to deliver a better feature (without the benefits of developer-oriented quality protections that our process provides). We should always be trying to answer the question "does this solve an important problem well?"

If Safari has to take some first-mover disadvantage in this case for doing a bad job, so be it.

Best,

Alex

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

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

[Vladimir Levin]

Note that we've agreed to separate this intent into two separate intents for `match-element` (https://groups.google.com/a/chromium.org/g/blink-dev/c/o3JcMI6dGdY/m/bg3z-WX3BwAJ) and `auto` (https://groups.google.com/a/chromium.org/g/blink-dev/c/KCizytrJUMA/m/dqg_mEX4BwAJ). This intent is deprecated by the other two.

Thanks,

Vlad