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

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.

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

What do you think?

Brian

Received on Friday, 30 May 2014 06:29:59 UTC