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
In web-animations-1, getAnimations is defined to return the list of relevant animations, most notably where the associated effect is current or in effect. The intent is to not need to return animations which will no longer having an affect on the element. Animations which will later have an effect are still considered current.
Scroll-linked animations are not current or in effect due to an inactive time when:
In both of these cases, I think developers would expect the animation to still be considered relevant as it may later have an effect, just as they also expect an animation which has been delayed to be returned by getAnimations.
I propose these animations should be considered to be current, as the definition for current suggests it includes any animation which may become in play. This would mean:
…with non-increasing timelines. (#8089)
If an animation is associated with a non-monotically increasing timeline it may become active in the future (if non-idle). As such it should still be considered current (the same as an animation which may play in the future). This fixes#8053.
…with non-increasing timelines. (w3c#8089)
If an animation is associated with a non-monotically increasing timeline it may become active in the future (if non-idle). As such it should still be considered current (the same as an animation which may play in the future). This fixesw3c#8053.
In web-animations-1, getAnimations is defined to return the list of relevant animations, most notably where the associated effect is current or in effect. The intent is to not need to return animations which will no longer having an affect on the element. Animations which will later have an effect are still considered current.
Scroll-linked animations are not current or in effect due to an inactive time when:
In both of these cases, I think developers would expect the animation to still be considered relevant as it may later have an effect, just as they also expect an animation which has been delayed to be returned by getAnimations.
I propose these animations should be considered to be current, as the definition for current suggests it includes any animation which may become in play. This would mean:
Concretely the change could be adding "If has finite timeline is true" to the list of conditions under which an animation is considered to be current.
The text was updated successfully, but these errors were encountered: