[csswg-drafts] [css-animations] Extend animation-play-state for triggering animations when an element is in viewport (#8942)

ydaniv has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-animations] Extend animation-play-state for triggering animations when an element is in viewport ==
Entry animations are pretty common on the web. Currently in order to trigger time-based animations when an element enters the viewport we have to use IntersectionObserver.
The problems with this:

- requires writing some amount of JS for rather simple use-case
- requires waiting for JS to start for playing animations (may be slow when sites import a lot of JS)
- `IntersectionObserver`s take `transforms` into account, so that messes up the ability to properly know when then element is in viewport when animating from outside of it using transforms
- the web engine is not aware of the fact that the element will be animated on entry and may punish you on perf

The idea of using an `in-view` selector was dismissed, so another idea is perhaps to extend the `animation-play-state` property to support a sort of "trigger" values instead of only `running`/`paused`,  and reuse the new `animation-range` values syntax to toggle between these states, which:

```css
.element {
  animation-name: fly-in;
  animation-duration: 1s;
  animation-fill-mode: backwards;

  /* magic right here */
  animation-play-state: toggle(entry 50%);
}
```

A good thing about ranges is that they already ignore transforms for SDA.

While this condition evaluates to `false` the value computes to `paused`, and when it's `true` it will change to `running`.
Another requirement would be to be able to both toggle every time the computed value changes, and also have it set once. Perhaps this could be inferred from the `animation-fill-mode`, so that `both` and `backwards` are used for those respectively.

cc @bramus @flackr 

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8942 using your GitHub account


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

Received on Saturday, 10 June 2023 11:32:01 UTC