Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-view-transitions-2] Conditionally choose participating elements when onscreen in both DOM states #9354

Open
khushalsagar opened this issue Sep 13, 2023 · 5 comments
Labels
css-view-transitions-2 View Transitions; New feature requests

Comments

@khushalsagar
Copy link
Member

khushalsagar commented Sep 13, 2023

Consider the following case:

  • There is a header in the old DOM which may or may not be onscreen in the new DOM. For example, the page is scrolled because its a fragment navigation.
  • If the header is in both DOMs, you want a position animation between the 2.
  • If the header is only in the old DOM, you want it to animate with its parent. As if it was never tagged with a name.

The above is very difficult to achieve. Once you've tagged something in the old DOM, it will generate its own ::view-transition-group and will be in a separate snapshot. Authors could try to set a custom animation so the group for the header, making it as-if it's still embedded in its parent's snapshot. But that's very hard, you need to replicate a bunch of animations (transform, opacity, filter) being applied to the VT pseudo displaying the parent's snapshot.

We can add a new CSS property to have the browser do this. Even if it captured a child as a separate snapshot, don't generate pseudos for it unless the name is on both sides. And render it as-if its still embedded within its parent's snapshot.

@khushalsagar khushalsagar added the css-view-transitions-2 View Transitions; New feature requests label Sep 13, 2023
@vmpstr
Copy link
Member

vmpstr commented Sep 19, 2023

Some of these problems may be solved by hierarchical structure for the pseudo elements. That structure might still need to be conditionally constructed, so we might need another property here, but at least it would be less magical

@khushalsagar
Copy link
Member Author

That structure might still need to be conditionally constructed, so we might need another property here, but at least it would be less magical

Fair. The use-case I saw would require the header's group pseudo to be a child of the ::view-transition-old of its parent. Since the transition would do a slide animation on the old image.

@bcole808
Copy link

bcole808 commented Oct 3, 2023

+1 to optimizing performance by skipping transitions on elements that are not visible within the viewport in either the old or new DOM.

As a developer writing Javascript and CSS, one way I might try to approach this optimization on the Javascript side could be to use Intersection Observer to keep track of when elements are visible in the viewport. Then, if they are visible, conditionally add a view-transition-name to them.

But I realize a shortcoming of that approach is that it only captures element visibility in the old DOM, and misses elements that are not presently visible but may become visible after a transition (such as for a long list of items on a page where items below the fold may need to transition to appear higher up on the page when the list is re-ordered). Those would not receive a view-transition-name in the old DOM and thus may not be animated during a transition.

@bramus
Copy link
Contributor

bramus commented Oct 5, 2023

Duplicate of #8282?

@khushalsagar
Copy link
Member Author

Duplicate of #8282?

I'm not sure, would love your feedback on that. :)

  1. This issue was for the use-case where you only want an element to animate if it will be onscreen on both sides. So we'll conceptually put the captured element's snapshot back into its parent if we don't find a matching view-transition-name onscreen in the new DOM. There's an implicit assumption that ignoring offscreen stuff is only needed for morph animations.
  2. [css-view-transitions-2] Ignore offscreen elements from participating in transitions #8282 was more general, ignore an element unless its onscreen (or within some margin of the viewport). So you could use it for elements which do exit/entry animations as well.

I think these are 2 distinct use-cases?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
css-view-transitions-2 View Transitions; New feature requests
Projects
None yet
Development

No branches or pull requests

4 participants