Re: [css-animations] Interaction of negative animation-delay and animation-iteration-count

On Sep 3, 2014, at 7:11 PM, Brian Birtles <bbirtles@mozilla.com> wrote:

> On 2014/08/29 1:27, Sylvain Galineau wrote:
>> I would like to resolve bug 14807 [1] on the interactions of animation-delay and animation-iteration-count. Specifically, clarify what happens when:
>> 
>> a) animation-delay is (-1 x animation-duration) e.g.
>> 	
>> 	animation-duration: 5s;
>> 	animation-delay: -5s;
> 
> It depends what we decide to do for:
> 
>  animation-duration: 5s;
>  animation-delay: -6s;
> 
> We discussed this back in May-June[1][2] but didn't reach a conclusion.
> 
> I believe my preference was that the animation dispatches start/end events and fills and your preference was that the animation just fills.
> 
> However, for:
> 
>  animation-duration: 5s;
>  animation-delay: -4s;
> 
> I think you agreed the animation should dispatch BOTH start/end events and fill.[3]
> 
> I'm ok with adopting your preferred behavior with regards to events but in that case:
> 
>  animation-duration: 5s;
>  animation-delay: -5s;
> 
> should NOT fire events.
> 
> In general we use an end-point exclusive timing model (this is true for SVG/SMIL, Web Animations, and CSS too, e.g. the way timing functions are defined[4]). So if we are going to treat animations that finish before they start specially with regards to events, then an animation with a negative delay equal to its active duration should be considered such an animation.
> 
> > For a), I believe it is equivalent to a zero duration i.e. the animation completes immediately.
> 
> I disagree based on the above. Zero-duration animations should dispatch events, but this case should not.

Yes, we need to resolve when events fire. I'd like to discuss that separately instead of piecemeal though as there are many other interesting scenarios to consider - e.g. when the animation has a negative delay but gets applied in the paused state - and I think it's going to be hard to make sure we have a good model if we discuss events a single edge-case at a time. 

(And you're more than welcome to start a new thread of when/how animation events fire, btw)

> 
>> b) when the animation has 2+ iterations and a negative animation delay covers more than one iteration e.g.
>> 
>> 	animation-duration:2s;
>> 	animation-iteration-count:2;
>> 	animation-delay:-3s;
> 
>> For b) I think we should clarify that a negative animation-delay resolves against the timeline produced by animation-duration x animation-iteration-count. (We should have a name for this, incidentally).
> 
> In Web Animations it's called the "active duration".[5]

Good term, thanks!

> 
>> In other words, it can 'swallow' iterations i.e. in the example above the UA would only run the last second of iteration #2.
> 
> I agree but I also think we should be more lenient about what iteration events we expect UAs to dispatch in the first place.
> 
> e.g. if we have
> 
> animation-duration: 0s;
> animation-iteration-count: 1000;
> 
> Do you really expect 1000 iteration events?

I do not, but the issue here is the interaction of animation delay with iteration count.

> 
> Or similarly,
> 
> animation-duration: 0.001s;
> animation-iteration-count: 1000;
> 
> From my testing all UAs drop iteration events in this case except IE which caps the precision of durations to a few digits so it never has to deal with extreme cases like:
> 
> animation-duration: 0.000001s;
> animation-iteration-count: 1000;
> 
> In Gecko we always dispatch start/end events but we only dispatch up to one iteration event per frame.
> 
> What do you think?
> 
> Best regards,
> 
> Brian
> 
> 
> [1] http://lists.w3.org/Archives/Public/www-style/2014May/0356.html
> [2] http://lists.w3.org/Archives/Public/www-style/2014Jun/0008.html
> [3] http://lists.w3.org/Archives/Public/www-style/2014Jun/0013.html
> [4] http://dev.w3.org/csswg/css-transitions/#transition-timing-function-property
> [5] http://www.w3.org/TR/2014/WD-web-animations-20140605/#calculating-the-active-duration
> 

Received on Thursday, 4 September 2014 15:16:18 UTC