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

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?

2) Does this animation fire events?

3) If this animation does fire events, what is the elapsedTime member?

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

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.


Alternatively, we could just drop the special handling for negative 
delays. It actually seems a bit odd to me. If the event handler knows 
enough to know that the animation in question's animation-direction and 
animation-iteration-duration, then it probably knows its animation-delay 
as well.

Best regards,

Brian

Received on Tuesday, 27 May 2014 07:29:20 UTC