Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[web-animations-2][css-animations-2] #11910

Open
DavMila opened this issue Mar 11, 2025 · 0 comments
Open

[web-animations-2][css-animations-2] #11910

DavMila opened this issue Mar 11, 2025 · 0 comments

Comments

@DavMila
Copy link
Contributor

DavMila commented Mar 11, 2025

The 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) 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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant