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

On May 29, 2014, at 11:29 PM, Brian Birtles <bbirtles@mozilla.com> wrote:

> Hi Sylvain,
> 
> (2014/05/30 14:38), Sylvain Galineau wrote:
>>> An app that fades an element to opacity:0 might use the animationend event to remove the element from the DOM. Suppose this animation ends up running in the past (either due to author error, user styles, or because setting a negative delay was somehow easier than overwriting animation-duration to 0s to create an 'immediate' animation). So long as the element ends up with opacity:0, the animationend event should still fire so it can be removed from the DOM.
>> 
>> We agreed start/end need to fire together. Now you say that an animation that didn't actually run needs to fire an end event. And thus, presumably a start event since they need to be paired? Hmmm.
> 
> Yes, that's right.
> 
>>> On the other hand, if we want to define animations in the past as not running and not applying a forwards fill, then I think they should not fire events.
>> 
>> Since fills apply outside the animation's execution time I do not expect them to have any connection with start/end events. Firing no events in this case is intuitively what makes the most sense to me. If you initiate an animation from a point beyond the time it interpolates, you'll never see a start or and end. The forwards fill will still apply, since it's meant to apply outside the animation's execution time.
> 
> My concern is that you should never get into a state where the fill mode is applied but no end event is dispatched. Either the animation has run or it hasn't--not it ran, but silently.

I understand that's your concern but I'm not sure where it comes from. css-animations' fill modes explicitly apply outside the animation's execution window i.e. they are visible when it's not running. So it is indeed possible for them to apply without any start/end event firing. 

For instance, I could set a positive delay, a backwards fill and apply the animation in the paused state. I do not believe there should be a start event for as long as the animation remains paused. It would be very awkward for any script that wants to synchronize with the beginning of the actual interpolation as they'd be notified of the animation being *applied*, not of its *running*. But I think the backwards fill should be visible for as long as this animation is paused (and throughout its delay when it runs). 

Same thing if you start after the animation's duration: you should see the forward fill but no event fires.



> 
> In any sequencing use case where the author says "do this animation" then "run this script" we should honour the sequence.
> 
>> Your description of this type of animation as having run "in the past" when I instead described the pattern as the author jumping into the future past may be revealing here. For you, the timeline is like a tape e.g. you can start from where you want but everything before the starting point is considered to have happened. I think only those things that happen after the animation is applied should fire events. Does that maybe clarify where we're diverging?
> 
> It's not so much the tape idea. I would be ok with saying any animation that ran completely in the past was simply discarded. SMIL does that for example.
> 
> My concern is "half-running" an animation and getting into an inconsistent state. Any script that relies on being run whenever an animation's final value is applied will break. This is particularly the case for animations that produce discrete changes such as 'visibility'.
> 

See above. I think things are actually harder for script authors if start/end can fire in situations when the animation does not, in fact, run.

Again, I understand you have a different model in mind. But though some details need work, css-animations events do not fire during the delay phase or after the animation duration completes. Fill modes do apply before/after the animation but they do not cause events to fire. 

> What do you think?
> 
> Brian
>

Received on Friday, 30 May 2014 22:21:43 UTC