Re: [css-animations] Animations that start and end in the past

On May 27, 2014, at 10:52 PM, Brian Birtles <bbirtles@mozilla.com> wrote:

> (2014/05/28 11:15), Sylvain Galineau wrote:
>>>> I think it'll be easier to nail the animation event model once we agree on basic use-cases for these events. If the use-case is 'start another effect synchronized with the execution (interpolation) of my animation' then we could, for instance, conclude that an animation applied in the paused state should probably not fire animationstart until it's in the running state *even if it also has a negative delay applied to it*. There has been disagreement on this in the past.
>>>> 
>>>> In this particular case it's not clear to me that events should fire here. Or what breaks if they don't.
>>> 
>>> In general, the transition and animation event models are broken,
>>> because devs can't rely on them firing predictably (transitions don't
>>> occur if the value doesn't change, etc.)  It might be nice if it
>>> wasn't *quite* so broken in this kind of way, but in any case WebAnim
>>> is the right way to chain things together, so maybe it doesn't matter.
>> 
>> That's not a great answer since cross-browser WebAnim interop is not quite here yet. Even if it were, telling authors 'you need to rebuild everything using this other API' is not going to be exciting for everyone either. People can and should be able to do some very basic animation synchronization with L1; I think we can achieve that, at least.
> 
> I've been using the Web Animations definitions for undefined areas here. There are quite a few of them. For example:
> 
>  animation: anim 0s infinite;
> 
> Does that animation repeat forever or for 0s? 0 * Infinity is an indeterminate form so there's no obvious answer. In Web Animations we say it goes for 0s.
> 
> The point of Web Animations is not the API primarily, but the model which defines these edge cases.

Right, but the model has to make sense for use-cases first. Then you throw edge-cases at it to make sure it has answers for those. If I just look at this particular case I think we can argue pretty convincingly for or against firing events. (And, as we know from the interop situation you documented, the current spec pretty much allows implementors to go either way as well....) 

In this specific case, it seems odd to fire event that are supposed to indicate the beginning/end of the animation's active interpolating phase when the author explicitly jumped past it entirely. It may still be the right answer but I don't think we can establish that from edge cases alone. Maybe the more general argument is that you could use a delay of (-duration) to jump to the last frame and you might still want to get start/end events with the same elapsedTime. And so on for all delays larger than (-duration). I think I can buy that.

Received on Wednesday, 28 May 2014 15:55:48 UTC