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

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:
>> Hi,
>> 
>> It is possible to define an animation that starts and ends in the past like
>> so:
>> 
>>  /* duration: 1s, delay: -2s */
>>  animation: anim 1s -2s forwards;
>> 
>> The questions I have are:
>> 
>> 1) Does this animation apply a forwards fill?
> 
> Yes.

Agree.

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

But first, is there an actual use-case for this specific pattern? If not, I'd rather agree on a model that makes sense for use-cases and then try to derive a consistent answer for the more exotic situations.

> 
>> With regards to (3), currently the spec says that for start events the
>> elapsedTime is equal to -delay when 'delay' is negative, which would mean
>> you get something like:
>> 
>>  animationstart, elapsedTime: 2s (despite the fact the duration is 1s)
>>  animationend, elapsedTime: 1s? (since the special delay handling only
>> applies to animationstart events)
>> 
>> Cross-browser testing: http://jsfiddle.net/VnuV7/1/
>> 
>> 1) IE, Firefox, Chrome, Safari: Yes
>> 2) IE: animationend only;
>>   Chrome, Safari: animationstart and animationend;
>>   Firefox: nothing (I'm fixing this, hence this mail)
>> 3) IE: animationend: 2s
>>   Chrome, Safari: animationstart: 0s,
>>                   animationend: 1s
>>   Firefox: -
>> 
>> (I've only tested with IE10 since I can't use IE11 on this machine.)
>> 
>> Proposal: Such animations are valid and with regards to the questions above:
>> 
>> 1) Yes
>> 
>> 2) Yes, both animationstart and animationend events should be dispatched
>> (I think it is legitimate to skip animationiteration events, if there were
>> any, but that is probably a separate discussion.)
> 
> Not sure I agree about skipping the iteration events, but I could be convinced.

To the extent the delay goes beyond iteration-count*duration, maybe. Again, easier to think about with use-cases.

> 
>> 3) elapsedTime for animationstart/animationiteration events is:
>>      min(max(initialAdvance, eventTime), activeDuration)
>>   where:
>>      initialAdvance = min(-delay, 0)
>>      activeDuration = iteration-duration * iteration-count
>> 
>>   (for animationend events it's just activeDuration)
>> 
>>   So for the above example that would give:
>>      animationstart: 1s
>>      animationend: 1s
>> I think the above preserves the intent of the spec which is to provide an
>> elapsedTime value that "allows the event handler to determine the current
>> iteration of a looping animation or the current position of an alternating
>> animation" whilst also bounding it within the interval where the animation
>> actually plays.
> 
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.
 

> Agreed.
> 
> ~TJ

Received on Wednesday, 28 May 2014 00:59:57 UTC