Re: [csswg-drafts] [css-view-transitions-2] Allow an auto-generated `view-transition-name` that doesn't default to ID (#10995)

I might not make the call, but I want to strongly support the resolution @noamr is proposing.

**The current view transition tools support 'page' transitions, not inner component transitions**. At Shopify, we recently abandoned view transitions for some "list reordering" transitions because other UI had to become inert during the transition. Scoped view transitions are the solution here, but we're not at that stage. It feels like folks are being guided by a few codepen demos that don't actually work in practice, although they make me excited about what we could do in future with scoped transitions.

**`match-element` is useful, but maybe not as useful as folks are assuming.** It feels like folks want this to be the default under the assumption that it solves most problems. I think folks are underestimating how often 'equivalent' bits of UI are actually different element instances. Remember we're talking about page transitions here. Outside of frameworks, it's common to download a load of HTML and set it as some container's `innerHTML`. This means a lot of equivalent elements are different element instances. With frameworks, more elements are preserved, but most developers don't understand when this does and doesn't happen, since the diffing algorithms are largely treated as an optimisation.

**Using an ID as the `view-transition-name` is interesting, but not as useful as folks are assuming**. I'm glad we're looking to unlock it as a feature, but IDs aren't that common as style hooks. I've seen cases where, eg an ID is generated from a heading's content (for linkablity), then it's used for styling in some subtle way, then a small change in the heading content breaks that. For reliability, I would encourage folks to keep their `view-transition-name` and ID semantics separate, to reduce the likelyhood that an ID would change and impact view transition CSS styles. But, I'm still glad that we're making this kind of thing possible in CSS.

**View transition CSS behaviour should be as similar as possible between same-document and cross-document transitions**. Some folks don't see that as an acceptable design goal. I strongly disagree. Arbitrary behaviour differences make systems difficult to learn. I don't see why we'd put that on developers without good reason. I don't see a good reason here. We could look at different default for scoped transitions if they make sense.

**The proposed behaviour of `auto` is a confusing foot-gun**. It takes `match-element` and mixes it in with the ID behaviour in ways that are difficult to keep track of, and even if they appear to work in a given situation, will likely break in unexpected ways the developer wasn't expected (eg an ID is removed from an element). Partial failures are the worst to debug.

I'm not against at some point having a "it's what you want most of the time" `auto` value, but the behaviour proposed here isn't it. It's worrying that it's being pushed though by folks who have less experience with view transitions.

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


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

Received on Wednesday, 13 November 2024 10:00:08 UTC