Re: [css-animations] Proposal for handling changes to animation-* properties while an animation is running

On Sep 9, 2014, at 6:24 PM, Brian Birtles <bbirtles@mozilla.com> wrote:

> On 2014/09/10 1:04, Tab Atkins Jr. wrote:
>> Currently, the animations spec requires "snapshotting" all the
>> animation-affecting properties when the animation starts.  We
>> previously discussed allowing some things to be updated on the fly,
>> and in today's f2f discussion, we clarified more.
>> 
>> Here's the proposal: just let everything be adjustable.  The start
>> time of the animation (when the animation starts applying; when value
>> is adjusted (in the animation-* properties, or in the @keyframes
>> rule), just recompute what value the animation would be at if it had
>> always had those values, and start applying that instead.
> 
> This (or actually the clarified version in your follow-up mail) seems good to me. It will be possible to change all these properties via the Web Animations API anyway so it seems preferable that authors see the same kind of behavior with regards to liveness whether they make changes to animation parameters via style or script.

Sounds good.

> 
>> Event-handling needs to be dealt with here; we propose that start and
>> end events are fired once, and are guaranteed to fire, even if an
>> adjustment caused the actual start/end time to never be instantiated.
>> Iteration events just fire whenever the animation plays through an
>> iteration boundary; adjusting an animation to "skip" a bunch of
>> iterations does *not* fire a bunch at once, and if you adjust an
>> animation to return to an earlier point, the iteration event for a
>> particular index will fire again.
> 
> One case worth considering is start/end events when re-entering the active interval.
> 
> For example:
> 
> i. the animation finishes,
> ii. 'animationend' gets dispatched,
> iii. you adjust 'animation-duration' making the animation longer so that you're now running again

Unless I misunderstand what you mean, adjusting animation-duration would not restart the animation using today's CSS Animations. The issue under discussion is what happens when CSS properties get tweaked while the animation is running. Once it's ended, updating the duration does not restart it. You need to reapply it through animation-name. At which point it would of course fire start/end events, use its new duration etc.

> 
> Do you fire an additional 'animationstart' (and a subsequent 'animationend' event once we leave the active interval again)?

As mentioned above, no additional events would be fired as a result of updating the duration after 'animationend' was fired.

> 
> My hunch is that for most uses of animation events, that's the more useful behavior. That is, animationstart/animationend events are always paired, but there may be more than one pair.
> 
> (For reference, SMIL takes the approach that once you reach an interval boundary, it is fixed. i.e. once an animation has started the start time is fixed; once it has ended the end time is fixed. I don't think we can do that here, however, since it will still be possible to affect the end time using the API and we'll need to decide what events should be dispatched in that case anyway.)
> 
>> (More discussion today showed that this idea of how to handle events
>> appears to generalize well; we can use this as a general rule for how
>> to resolve "when do events fire in case X".)
> 
> Yes, this is worth investigation. I'd like to see us explicitly call out that UAs are not required to dispatch more than one iteration event per frame for cases like:
> 
>  animation: yer 0.001s 1000
> 
> In fact, for the above, I'd like if UAs weren't required to dispatch an iteration event at all if no frame fell within the animation's interval.

Sounds reasonable. (Though I do not believe we really define what a frame is)
> 
> So perhaps the general rule could be phrased in terms frames, comparing the current iteration from the previous frame with the current frame.
> 
> Best regards,
> 
> Brian
>

Received on Tuesday, 23 September 2014 22:43:09 UTC