Re: [w3ctag/design-reviews] CSS view transition auto name generation (Issue #1001)

jakearchibald left a comment (w3ctag/design-reviews#1001)

> Is your point that this is a straight-up misfeature and it shouldn't exist at all because match-element is enough for SPA where as MPA can't rely on auto unless there is exceptional id-allocation discipline?

I like `match-element` as a feature, but I don't think it's "the solution". For example, if you're doing a naive vanilla SPA, a common way to do this is grab the page content from somewhere, and set it as the `innerHTML` of some container. Because of this, you're doing to lose element equality. That's how it works in the [simple demos I built](https://simple-set-demos.glitch.me/5-heading-text/) - the header bar loses element equality here.

In SPAs built with a framework such as React/Vue/Svelte, element equality is abstracted away from you. It's just an optimisation. And (as far as I know) none of them allow an element to change parent node. Fun example: In NextJS and Remix, each route is a component, so if your `<IndexRoute>` and `<AboutRoute>` each contain a `<SideNav>`, the side nav will be fully rebuilt (and not equal) as you move between those routes, since the parent component type has changed.

You can maintain element equality when reordering siblings using the `key` prop, which is essentially a sibling-scoped identifier. But, if you're already going to the trouble of assigning a `key`, it's pretty easy to assign a unique `view-transition-name`.

At somewhere like Shopify, I'd recommend assigning a `view-transition-name` ident, as it's more reliable.

That said, I think `match-element` is a nice addition and low risk. If you understand that elements are linked by referential equality, and you see the transition going wrong, then you know something is going wrong with referential equality.

The problem with `view-transition-name: auto` is it puts this behaviour behind an unassuming name, and throws in this extra `id` behaviour that seems more problematic than useful.

> Or, do you have an alternative approach in mind? Is that alternative as simple as an appropriately-scoped `[id] { view-transition-name: attr(id type(<custom-ident>)) }`?

I love that CSS `attr()` is this expressive now, and that [view transitions are used as an example on MDN](https://developer.mozilla.org/en-US/docs/Web/CSS/attr#parsing_attr_values_as_custom-idents).

As a codebase maintainer, I'd raise concerns about `view-transition-name: attr(id type(<custom-ident>))`, because I think it's risky overloading `id` in this way, and I'd suggest creating a custom `data-` attribute instead. But this is actually great because:

- Switching to use another attribute is not only possible, it's very easy
- As a code reviewer, it was obvious to me that the id attribute was being used to generate the `view-transition-name`, rather than being hidden behind the `auto` value.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1001#issuecomment-2753797858
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1001/2753797858@github.com>