[csswg-drafts] [web-animations-2][css-animations-2] (#11910)

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

== [web-animations-2][css-animations-2] ==
The [web-animations-2#animation-trigger](https://drafts.csswg.org/web-animations-2/#animation-trigger) spec defines animation triggers, including their `default` and `exit` ranges. A trigger plays the animation when in the `default range` and resets or reverses (depending on the [type](https://drafts.csswg.org/web-animations-2/#trigger-types)) when outside the `exit range`.

Should the exit range be constrained to include the default range? This is only really relevant for the ‘repeat’, ‘state’, and ‘alternate’ types. If such a constraint does not exist, then we need to specify whether being outside the exit range (which would normally cause a reset/reverse) while being inside the default range causes a reset/reverse of the animation. I think it should not and I assume so in the example I give below.

I can’t think of very many useful cases where an author would want an exit range that doesn’t include the default range. The one case I can conjure up is this example:
A ‘repeat’ trigger with default range: `[200px, 300px]`, exit range: `[0px, 100px]`.
(We’d typically expect the default range to be defined where the animating element is in view.)
Here, the author can prevent the animation from being replayed via instant programmatic scrolls which move the scroller between `[0px, 100px]`, perhaps due to a link, and `[200px, 300px]` where the animating element is visible.
However, as this is a ‘repeat’ animation, it seems likely that an author would want the animation to be replayed so this is not really useful.

Given that, AFAICT, the only use of not having this constraint goes contrary to the idea of ‘repeat’, ‘alternate’, and ‘state’ triggers, I think we should have this constraint. And if there are use cases that come up in the future that need this constraint to be relaxed, it should be okay to remove/relax this constraint.

Lastly, if we adopt this constraint, user agents will need to handle specified exit ranges that are invalid, i.e. not inclusive of the default range. I would propose defaulting to the default range when this happens, matching what user agents should do when the exit range is not specified.

@argyleink @bramus  thoughts?

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


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

Received on Tuesday, 11 March 2025 15:58:58 UTC