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

On Sep 4, 2014, at 4:13 PM, Brian Birtles <bbirtles@mozilla.com> wrote:

> On 2014/09/05 0:15, Sylvain Galineau wrote:
>> 
>> On Sep 3, 2014, at 7:11 PM, Brian Birtles <bbirtles@mozilla.com> wrote:
>> 
>>> 
>> 
>> 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.

Quite simply, css-animations does not define the concept of active duration as a reference for animation-delay. So the scope of my question is way, way simpler than you think: simply to make sure a delay longer than a single iteration 'swallows' one or more of the iteration you specified. Also, that a delay as long as the duration is equivalent to a 0s duration.

I know this bit is obvious and boring to you, but we haven't specified it anywhere. (Though I believe implementations agree). 

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

I don't know what 'endpoint-exclusive' timing means. But to the extent we agree a 0s duration animation fires events *and* this particular scenario is equivalent to it then yes, they'd fire in that case too. 

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

Exactly right; I'd rather discuss event handling generally, thinking of this case along with all the others we need to handle. I find it hard to understand whether a general rule makes sense in the context of a specific use-case or edge-case. And I'm totally open to a proposal that covers all the weird combinations of properties/values, including this one. So if that's your thing...

> 
> Best regards,
> 
> Brian

Received on Thursday, 4 September 2014 23:37:52 UTC