Re: [csswg-drafts] [css-view-transitions-2] Revisiting view-transition-name: auto keyword name (#12091)

I don't think any of my concerns were really addressed in the discussion, so I'll restate them here:

## Messy results between same & cross-document transitions

One of the things I stuck to when I was more involved with the design of VT, is that the behaviour should be consistent for transitions between documents, and transitions within the same document. This gives developers one things to learn, and transition definitions that can be applied both cross-document and same-document, which is a real world use-case. I don't want a situation where every MDN page about view transitions needs a section that defines what something does depending on whether it's cross-document or same-document.

`match-element` goes against that rule, but it does consistently fail cross-document, and it's understandable to say "this feature does not work for cross document transitions". Since this is really useful (particularly for scoped transitions), and fails consistently, I think it's fine.

The "auto" behaviour, no matter what you name it, creates a behaviour that doesn't completely work, and doesn't completely fail. This will surface in real-world cases as transitions that look broken, and that breakage will be hard for developers to track down.

"auto"/"match-auto" looks inviting, like "this is the thing you _should_ be using", and I really don't think it is.

Maybe a better name would be "match-unsafe", to go with things like [`setHTMLUnsafe`](https://developer.mozilla.org/en-US/docs/Web/API/Element/setHTMLUnsafe), but again, I don't see why we want to ship a footgun like this.

## Adding IDs becomes risky

I covered this [in my TAG post](https://github.com/w3ctag/design-reviews/issues/1001#issuecomment-2750966335), but the short version is that this overloads IDs. It puts you in a situation where you move/edit an ID which doesn't appear to be referenced in your codebase, and as a result break a bunch of transitions. This breakage won't be immediately obvious, so it's likely to make it onto your live site before you start getting vague error reports of things not looking right.

Yes, it's possible to get into this same situation with `attr()`, but my hope is that if developers do it this more manual way, they'll think about the consequences. Whereas, something like `match-auto` sounds like it's recommended by the designers of CSS, so it's less obvious that it's a footgun in practice.

The nice thing about `attr()` is you can use it to get from an attribute like `data-vt-name`, where its usage is more obvious. And if it isn't obvious, then a search of the codebase for `data-vt-name` will show you where it's hooked up to `view-transition-name` in your CSS.

## But really why are we trying to do this?

We don't provide special values to get `anchor-name`, `scroll-timeline-name`, or `view-timeline-name` from any particular attribute. I think this makes sense, because we have `attr()` as a general way for authors to do that.

I feel that this feature is being pushed by folks playing around with tiny demos, without considering how it scales to real-world sites. Small demos can still use `attr()`, but the CSSWG shouldn't be giving a footgun feature a special keyword that makes it look like recommended behaviour.

-- 
GitHub Notification of comment by jakearchibald
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12091#issuecomment-3783690699 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 22 January 2026 10:38:08 UTC