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

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.

> 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

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

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.

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 Wednesday, 10 September 2014 01:25:08 UTC