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

[scroll-animations-1][css-animations-1] A non-animated "Is in viewport" #10582

Open
noamr opened this issue Jul 16, 2024 · 7 comments
Open

[scroll-animations-1][css-animations-1] A non-animated "Is in viewport" #10582

noamr opened this issue Jul 16, 2024 · 7 comments

Comments

@noamr
Copy link
Collaborator

noamr commented Jul 16, 2024

Following up on #8282:
Currently to set a style that behaves differently based on whether the element is in the viewport, one has to use scroll-driven animations. For example, to set a view-transition-name when the element is in the viewport:

@keyframes set-name-when-in-view {
  from { view-transition-name: actual-name }
  to { view-transition-name: actual-name }
}

.thing {
  animation-name: set-name-when-in-view;
  animation-timeline-name: view();
}

The above works! However it requires going through an animation mental model for something that's not actually animated.
Perhaps view-timeline (or CSS animations in general?) can provide a convenient way to use animation primitives on something that's not animating? e.g.

.thing:in-view-range(view()) {
   view-transition-name: actual-thing;
}
@ydaniv
Copy link
Contributor

ydaniv commented Jul 18, 2024

Using a layout dependant state in a selector is something that we tried to avoid so far, as to avoid endless loops.
This is also why we went with a value-based approach for animation-trigger.
However, perhaps we could consider this as a further extension for State Container Queries?

@noamr
Copy link
Collaborator Author

noamr commented Jul 18, 2024

Using a layout dependant state in a selector is something that we tried to avoid so far, as to avoid endless loops. This is also why we went with a value-based approach for animation-trigger. However, perhaps we could consider this as a further extension for State Container Queries?

Yea that might be a better approach. Though I think endless loops in particular (pseudo-class) selectors are not an essentially different problem from view-timeline endless loops (you animate transform based on view() which changes your view-timeline and so forth)

@ydaniv
Copy link
Contributor

ydaniv commented Jul 18, 2024

Specifically for that we ignore transforms, per #8298 (comment).
This is what makes view() so appealing for animations, you can reason about it and have complex animations at the same time 🎂

@noamr
Copy link
Collaborator Author

noamr commented Jul 18, 2024

Specifically for that we ignore transforms, per #8298 (comment). This is what makes view() so appealing for animations, you can reason about it and have complex animations at the same time 🎂

Can't you animate the view timeline size, or animate something else that makes it move into/out of the viewport?
All of this is dandy but it has to do with when view() is computed, not with whether it's an at-rule or a pseudo-class.

@flackr
Copy link
Contributor

flackr commented Nov 8, 2024

This seems like more of an ask for the css-animations spec to perhaps have a convenient syntax for a single value animation, though I recognize there was also a proposal to use view timelines as a state selector. Moving this to level 2.

@bramus
Copy link
Contributor

bramus commented Dec 11, 2024

This came up again today for use with View Transitions:

  1. Visit https://frontendmasters.com/blog/
  2. Click on the title of the first article
  3. On the detail page, scroll down
  4. Hit the UA back button

On the homepage, you’ll now see the title fly-in from the top to its position on the homepage, which is weird.

Ideally, the title on the detail page would not have been captured (because it was offscreen) so that the title on the homepage can nicely fall back to a fade-in.

@argyleink
Copy link
Contributor

there's some overlap with anchor position-visibility, which allows authors to say if the anchor is outside the scrollport, then hide it.

maybe, authors can opt into hiding out of viewport pseudos with something similar, like view-transition-visibility. UA then checks to see if the starting point for this old pseudo is out of bounds, if so, it's skipped. this then makes the new pseudo an :only-child, at which point it can be brought into the page elegantly (instead of something flying in like a bat outta hell).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants