- From: Brian Birtles <bbirtles@mozilla.com>
- Date: Tue, 03 Jun 2014 11:54:09 +0900
- To: www-style@w3.org
(2014/05/31 7:20), Sylvain Galineau wrote: > > 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. Sorry for the delay in following this up. I think this comes down to whether setting a negative delay is equivalent to: a) Starting the timeline at a point after the animation has finished, or b) Seeking to a point after the animation has finished. For (a) you wouldn't expect events, for (b) you probably would. I'm ok with either. However, if the negative delay meant you started half-way through the animation, I think (a) would suggest you only fire an end event in that case. Yet I thought we agreed they should be symmetrical? Again, I'm ok with (a) but is it odd that: animation: anim 3s -3s forwards; Dispatches start and end and fills but: animation: anim 3s -3.0001s forwards; Dispatches nothing and fills? Maybe it's ok? Best regards, Brian
Received on Tuesday, 3 June 2014 02:54:41 UTC