Re: [csswg-drafts] [css-view-transitions-2] Proposal for a view-transition-tree property (name tbd) (#10334)

> In this case, the top box doesn't want to be contained, as it wants to transition between containers, whereas the other items need to be contained within the container.

That's an excellent point Jake. We actually considered option 1 too but leaned towards option 2 because it avoids the possibility of circularity. The use-case you mentioned though is a good reason to go for option 1. We already know which names appear in the ancestor chain when we reach a named element, so its trivial to fix the circularity issue by simply ignoring the `view-transition-parent` not in the chain.

If we have to pick 1, seems like option 2 is maximally flexible. option 1 is then syntactic sugar for a common use-case.

Re: mismatch in old and new DOM hierarchy, the situation can happen with either syntax option. We can consider a couple of options:

1. The ancestor is decided based on the old DOM. So if a name appears in the old DOM, we ignore the `view-transition-parent` for it specified in the new DOM. This is similar to our approach for paint order, we let the paint order of names be decided by the old DOM. It's only for entry animations that we consider parent declarations in the new DOM.
2. If the ancestor mismatches for an element between old and new DOM, then fallback to flattening to the root.

> I don't have great suggestions on top of my head, but could the use cases be covered by scoped element transitions? e.g. making so running a document VT + a scoped element transition concurrently parents things accordingly? or having some API to run both at the same time?

Excellent question! The use-cases we've seen do involve a full page transition. Think clicking on a button which expands to a widget while the background changes. This kind of thing is harder to coordinate with 2 independent transitions. We also have to think through how to deal with resizing for scoped transitions. For the scoped element, its layout for the end state will keep changing as its resized.

That said, @jakearchibald's example of a subset of nested elements being clipped can't be solved with scoped transitions. When a scoped transition is started, only elements in the subtree of the scoping element can participate in that transition. Content inside the scoping element can't animate out of it. For this you do need a transition at the root but with nested `::view-transition-group`s.

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


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

Received on Wednesday, 15 May 2024 15:25:42 UTC