- From: Yehonatan Daniv via GitHub <sysbot+gh@w3.org>
- Date: Tue, 20 Jun 2023 17:00:26 +0000
- To: public-css-archive@w3.org
Giving this more thought, using `animation-range` will not work here since it specifies every point on the range for a continuous event, and what we need here is actually a singular trigger, more like an IntersectionObserver. Instead of knowing the exact point on the range in each frame we need to resolve a boolean value indicating whether the element is intersecting the viewport or not. This can be interpreted as 2 possible options: 1. toggle between `running`/`paused` as the value changes - sort of play/pause 2. trigger a single change to `running` when the value resolves to true - sort of play/stop, with 2 scenarios: a. run once b. re-run every time the value is true IMO option 1. is less common, and will only have a meaning for long/infinite animations, and it's probably much more interesting to pursue option 2 with both variations. Naming aside, syntax could possibly looks something like: For 2.a.: ```css .element { animation-play-state: trigger(in-view 50%, once); } ``` or for 2.b.: ```css .element { animation-play-state: trigger(in-view 50%); } ``` And possibly with `rootMargins`, if we follow IntersectionObserver's options: ```css .element { animation-play-state: trigger(in-view 50% / 10% 0); } ``` Also assuming `root` isn't specifiable for now and defaulting to `nearest`, which is nearest scroll-container, same for `ViewTimeline`s. -- GitHub Notification of comment by ydaniv Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8942#issuecomment-1599178075 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 20 June 2023 17:00:28 UTC