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

On 2014/09/05 0:15, Sylvain Galineau wrote:
>
> 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.

Sorry, I don't understand the issue then. I thought the question was 
about the behavior of animations that finish *at* their start time? So 
I'm suggesting the behavior is identical to animations that finish 
*before* their start time due to endpoint-exclusive timing.

With regards to animations that finish *before* their start time, as far 
as I can tell, the only two questions about their observable behavior are:

a) Do they apply a forwards fill?
b) Do they fire events?

I thought we agreed on (a) and (b) was an open question.


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

Sorry, I don't understand what you're trying to clarify. What are the 
possible options in terms of observable behavior?

As far as I understand, it's only events that differ hence my proposal 
for a adopting a general rule regarding events that would cover this 
case and others.

Best regards,

Brian

Received on Thursday, 4 September 2014 23:13:25 UTC