Re: [animations] appendRule() and deleteRule() impact on currently running animations

In FF, the rules take effect right away.
In Chrome, the changes take effect when the animation is removed and reattached.

Here’s a codepen: http://codepen.io/estelle/pen/dogmoG <http://codepen.io/estelle/pen/dogmoG>


On Jul 25, 2015, at 10:18 PM, Estelle Weyl <estelle@weyl.org> wrote:

I should add: in Chrome, the change is not impacting the currently animated element, in Firefox changes to the keyframe are effecting the currently animating elements.
It is, of course, possible, that with Chrome I was not using the proper prefixing or otherwise made a typo, though cssText did show the changes.
-Estelle 





On Jul 25, 2015, at 10:10 PM, Estelle Weyl <estelle@weyl.org <mailto:estelle@weyl.org>> wrote:

If a keyframe rule with is changed with either deleteRule() or appendRule(), my assumption is that currently running animations will not be effected by the update to the @keyframes animation. My assumptions are based on the non-normative explanations "Note that dynamically updating keyframe style rules does not start or restart an animation”, "Once an animation has started it continues until it ends or the 'animation-name’ is removed,” and "In order to restart an animation, it must be removed then reapplied.” 

While none of those quotes actually address the issue of what happens if a property / value is altered in a keyframe declaration once the animation is running, the content in the spec, including the discussion earlier today about animation-timing-functions only impacting properties that are declared in the same keyframe selector block (not cascading like other properties), makes me think that making changes to any properties in a keyframe animation will only impact animations that have yet to start iterating.

I assume attaching the keyframe animation to elements in the future will result in them using the more newly defined animation, but changing a keyframe animation, like making a change to any animation properties other than name, will have no effect on a currently iterating animation. 

Is that correct?

If not, please advise if something is written about htis in the spec (didn’t find it, but doesn’t mean that it’s not there).

Also, what happens if 50% {top: 0;} get’s changed to 50% {top: 1000px; } - does the element jump, to the new interpolated value immediately, with the next iteration following the exact path, or does it smoothly interpolate this animation iteration, and the next iteration follows what would have been the path had the property always had that value at that point in the animation.

Hope I made sense.

-Estelle 

Estelle Weyl