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

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.

> 2) Does this animation fire events?

The spec says yes.

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

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

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

Agreed.

~TJ

Received on Tuesday, 27 May 2014 20:30:10 UTC