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)
• IntersectionObservers take transforms into account, so that messes up the ability to properly know when an 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 could look like:

.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, so the same semantics could apply here and help solve this problem of transforms messing with initial position for triggering on viewport intersection.

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. Or maybe use specific syntax for distinguishing between the two.

cc @bramus @flackr