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

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.

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

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

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 02:12:09 UTC