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

(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.

Best regards,

Brian

Received on Wednesday, 28 May 2014 05:52:42 UTC