- 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