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

On May 27, 2014, at 6:43 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Tue, May 27, 2014 at 5:59 PM, Sylvain Galineau <galineau@adobe.com> wrote:
>> On May 27, 2014, at 1:29 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>>> On Tue, May 27, 2014 at 12:28 AM, Brian Birtles <bbirtles@mozilla.com> wrote:
>>>> 2) Does this animation fire events?
>>> 
>>> The spec says yes.
>> 
>> Where? I don't think it says so unambiguously for this odd case. It's not clear whether a 0s animation fires events at the moment, for instance (issue is noted in the spec); this particular animation has a positive duration but its negative delay results in an effective 0s duration which makes it a bit of an oddball. (There are other pending issues in this area e.g. when to fire events for an animation applied in the paused state...).
> 
> It doesn't say not to, and so the general language about animations
> firing events should still apply.

The 'general language' of the spec can be used to argue the opposite so that's not very helpful e.g. the language I see suggests animationstart begins at the active/interpolating phase of the animation. In this case the negative delay makes us fast-forward beyond its duration so it's not so obvious it ever starts or ends. Or, to be precise, it's not obvious its active interpolating phase ever happens. If we had start/end event for the overall animation that were distinct from the start/end of interpolation then I'd say it'd make sense to fire the former for all valid animations, even with a 0s duration. It's not as obvious in the current model.

> 
>>>> 3) If this animation does fire events, what is the elapsedTime member?
>>> 
>>> The spec says equal to the absolute value of the delay, but it sounds
>>> like the spec forgot to think about animations whose duration is less
>>> than the delay.  I think it should be equal to min(abs(delay),
>>> duration).
>> 
>> I'm not sure the spec 'forgot'. I think this scenario has really been defined, hence the uneven interop.
> 
> Do you mean "dont' think"?

Yes. Or 'has not really been defined'.

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

Note: I'm not opposed to firing events in this case. It's just that in the absence of a use-case for this pattern I'm not sure it's that interesting a problem to resolve, regardless of which animation API you prefer.



> 
> ~TJ

Received on Wednesday, 28 May 2014 02:16:16 UTC