Re: [csswg-drafts] [css-animations-2] Add animation-trigger for triggering animations when an element is in a timeline's range (#8942)

@flackr 
> To clarify https://github.com/w3c/csswg-drafts/issues/8942#:~:text=however%20maybe%20a%20range%20based%20trigger%20always%20plays%20forward%20when%20you%20enter%20the%20range%20and%20plays%20backwards%20when%20you%20leave%20it%20and%20if%20you%20don%27t%20want%20one%20of%20the%20directional%20trigger%20points%20it%20is%20conceptually%20infinite%20/%20the%20start%20or%20end%20of%20the%20range., I think it would be helpful to always have a range (i.e. start and end) for all cases. When the end of the range is not specified it could be some form of infinity / auto value so that most of the time developers would only need to specify a start point.

Yes, of course. If you don't expect navigation to an anchor then you're fine with just the start.

> does having a trigger range not fix the discontinuity issue?

Usually "entrance" animations are usually "from" animations, meaning, they animate to an implicit `to` keyframe or an identity transform, etc. So your range needs to account for the element to be visible. Question is, what happens when exiting the range on the same position where the element is visible?
Perhaps we could say there's no change when exiting, but then if you enter again the animation will go back to 0% and play again,  just like @bramus described above ☝️ .
My intent was to see if we can allow specifying the exit point a bit further, where the element is out of view, so that a nicer effect can be easily achieved.

@bramus 
> When I think of a Scroll-Trigger Animation, I think of a certain line that the elements needs to cross, not a range. Say I want to trigger an animation when scrolling past the 1000px scroll offset, would your range then be [1000px, +Infinity] to indicate that the animation can play while in that range?

It's just like scroll vs. view timelines again (: You can set s specific point on the scroll and that's a valid use-case. But usually you'll set a trigger using IntersectionObserver and wait for an intersection, which can better described by view timeline. And the nice extra is that this also fixes the awkwardness of transforms on the same element, that by ignoring them we can reason about the trigger point without worrying about the initial animation frame.

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


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

Received on Friday, 15 September 2023 08:44:45 UTC