You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The web-animations-2#animation-trigger spec defines animation triggers, including their
default
andexit
ranges. A trigger plays the animation when in thedefault range
and resets or reverses (depending on the type) when outside theexit 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?
The text was updated successfully, but these errors were encountered: