Re: [css3-animations] dynamic changes to animation properties or keyframes

On Sunday 2011-11-06 11:48 -0800, L. David Baron wrote:
> On Saturday 2011-04-02 12:14 -0700, L. David Baron wrote:
> > http://dev.w3.org/csswg/css3-animations/#animations says:
> >   # The values used for the keyframes and animation properties are
> >   # snapshotted at the time the animation starts. Changing them
> >   # during the execution of the animation has no effect. Note also,
> >   # that changing the value of ‘animation-name’ does not necessarily
> >   # restart an animation (e.g. if a list of animations are applied
> >   # and one is removed from the list, only that animation will stop;
> >   # The other animations will continue). In order to restart an
> >   # animation, it must be removed then reapplied.
> > 
> > This doesn't appear to match WebKit's behavior.  For example, in the
> [...]
> > Should the spec say instead that dynamic changes are honored, but
> > the animation start time (as adjusted by pause duration) is
> > preserved for each animation name?
> 
> I'd note that if the spec does take this approach, it needs to
> describe what happens when an animation-name occurs more than once
> in the list of animations:  in that case, I believe the start time
> for a given animation-name should always track the
> animation-play-state value of the last occurrence of that
> animation-name in the list of animations.
> 
> This is what I implemented in Gecko.
> 
> I think this behavior is preferable since in most cases the last
> occurrence overrrides earlier ones, which means it's the most likely
> of any simple rule to reflect the current state.  (This isn't true
> for some values of animation-fill-mode if some of the animations
> have completed (or not started yet) and some have not (e.g., because
> they have different durations).  It also might not be true if we
> allow a property to apply for only a part of animation (though Gecko
> currently does not, as I described in [1]).
> 
> I'd note that this means that authors will get weird behavior if
> they use multiple occurences of the same animation on the same
> element *and* dynamically change the animations list on that
> element.  But I think that's probably a cost worth paying to have
> otherwise-sensible behavior when changing the animations list on an
> element.

Note that Gecko changed behavior slightly here in [2].  Instead of
always matching the last animation in the list, we now take the new
animations list, iterate it from last to first, and for each new
animation, find the *last* matching animation in the old animations
list, *remove* it from the old animations list, and transfer the
state of that animation.

This means that a given animation will never transfer its state to
more than one new animation across a change in animation name.


smfr pointed out to me that the spec still doesn't cover the
behavior here at all.

-David

> [1] http://lists.w3.org/Archives/Public/www-style/2011Apr/0645.html
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1037316

-- 
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                          https://www.mozilla.org/   𝄂
             Before I built a wall I'd ask to know
             What I was walling in or walling out,
             And to whom I was like to give offense.
               - Robert Frost, Mending Wall (1914)