[css-view-transitions-1] Multiple elements with same view-transition-name

[fantasai]

What happens when multiple elements have the same view-transition-name value?

[khushalsagar]

The transition is aborted. Its step 8.3.1.6.5 here : "If usedTransitionNames contains transitionName, then return failure." Same thing happens when we look for transition names in the new DOM.

The name has to match exactly 2 elements from the old and new DOM so it must be unique or the author made an error.

[bleper]

It is worth noting that web developers have a need for the opposite (which can be solved by preprocessors, but some would like to do it natively on the platform).

[khushalsagar]

Thanks for that link! You hit a very good con of the approach to tag every item in a list with a view-transition-name here: "I imagine this is fairly moot, but could also be similar to a “too many DOM nodes” performance and debugging issue."

There is a significant rendering overhead to adding view-transition-name on an element. The browser has to render it into a separate layer/buffer since the assumption is that it will be animated independently. But when you're going from a list to details page (or back), only one of the list items needs to animate independently. So a name on every single list item causes a lot of redundant rendering work.

The optimal way to do this is to add the name only to the list item the user clicked. This is trivial to do with script (using a click or navigate event handler) but we do want this to be possible declaratively. #8889 has our current thinking behind a declarative solution. The idea is to add navigation specific CSS so when the user is leaving the list page, you can add view-transition-names (or any other styles) depending on the destination URL. Would appreciate your feedback there! #8209 also has relevant discussion.

Coming back to this topic, the fundamental issue is that the browser needs view-transition-name to match 2 unique elements between the old/new DOM states respectively. We initially considered an approach similar to querySelector, if you find the name on multiple elements use the first one. But it ended up masking developer errors instead of selecting the element the author would've wanted. For your example, if you add the same name on every list item you don't actually want the browser to select the first item. It is better to surface the duplicate view-transition-names as an error to authors instead of guessing which one to pick.

[bleper]

Without solving the performance problem, is it workable to put the calculation of the correct elements on the UA, leaving one of the pair as the root or unique element? This will make it possible to trigger a transition to an article and then back to the list item, but not from an article to a list item without a previous transition.

ui-el {
   view-transition: --name / auto; /* root */
   view-transition: --name / element(#top);
   view-transition: --name; /* default */
   view-transition-target: normal} /* same */

::view-transition-from-nth(--name) {…}
::view-transition-to-nth(--name) {…}

::view-transition-to-target(--name) {…}
::view-transition-from-target(--name) {…}

<meta name = view-transition-name content = --name>
<!-- => -1--name | -2--name -->

<ui-el>-1--name</ui-el>
<ui-el>-2--name</ui-el>

[khushalsagar]

@rthrejheytjyrtj545 do you mind clarifying the proposal? I didn't follow what view-transition-target means here or what the impact of / auto (and other values) is. Maybe starting with just the minimal syntax you'd need to get this transition right : "going from a list to details page where the user can click any list item" would be good. And an explanation for what each declaration expresses.

I'm dubious that we'd go for any solution which doesn't solve the performance problem for the list <-> details case. But I still want to understand this proposal, in case it makes sense for a different use-case we've seen.

[bleper]

My proposal specifies two entities: any number of elements on one page and one element on another. view-transition-target specifies this single element to which the transition is going, where auto is the document root, element(#foo) is the element with the id “foo”, and normal is the element with the same view-transition-name as at the element on the outgoing page (approximately today's position).

In the meantime, the UA pretends that the elements are additionally numbered, so that it can remember from the interaction with which element from the set the transition occurred (it can track this with some heuristic or a new type of container), and how to pass this number to the ending element. So, for example, if the transition came from the third element, in today's paradigm it would be the same as if both elements had a view-transition-name with a value of --name--3.

[khushalsagar]

Sorry about the late reply and thanks for the clarification.

it can remember from the interaction with which element from the set the transition occurred

It sounds like you want the UA to tie an interaction (like a click event) to an element and the transition to the interaction. This would basically allow conditionally adding a view-transition-name to one of the elements in the list, if that's the one the user interacted with. #8209 seems like a nicer way to do that, since it basically allows you to set any CSS (including view-transition-name). I noticed you +1'd the last comment there (thanks for taking the time to review the proposal). Given that, I'll close this issue but please feel free to re-open.