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

On May 28, 2014, at 6:16 PM, Brian Birtles <bbirtles@mozilla.com> wrote:

> (2014/05/29 0:55), Sylvain Galineau wrote:
>> Right, but the model has to make sense for use-cases first. Then you throw edge-cases at it to make sure it has answers for those. If I just look at this particular case I think we can argue pretty convincingly for or against firing events. (And, as we know from the interop situation you documented, the current spec pretty much allows implementors to go either way as well....)
> 
> Right. The model actually doesn't define these events (we tried but it was too hard to get events right when you have groups). So they are a CSS-specific feature. I probably misunderstood the discussion between you and Tab about the role of Web Animations here.
> 
> I think if we have animationstart events at all, they should be symmetrical with animationend events.

Yes.

> I can imagine an app maintaining a tally of active animations by counting such events. (This could be used to tell when all animations have finished for taking a snapshot, or to gauge the load on the system.) Dispatching only an animationend event would confuse the tally.

I'm not suggesting firing animationend alone. I think an animation must fire either both start *and* end, or neither.

> 
> I think if we say an animation that starts and ends in the past still applies a forwards fill, then it should dispatch an animationend event.

That's the part I don't follow; animation-fill-mode is explicitly defined as the "values applied to the animation outside the time it is executing". Firing events related to the execution of the animation as a side-effect of something that only applies outside its execution window is confusing.

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

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

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?



> 
> What do you think?
> 
> Brian
>

Received on Friday, 30 May 2014 05:39:39 UTC