W3C home > Mailing lists > Public > www-style@w3.org > September 2014

Re: [css-animations] animation-iteration-count: infinite and animation-duration: 0s

From: Brian Birtles <bbirtles@mozilla.com>
Date: Mon, 08 Sep 2014 09:58:54 +0900
Message-ID: <540CFF4E.7080802@mozilla.com>
To: "www-style@w3.org" <www-style@w3.org>
CC: "Tab Atkins Jr." <jackalmage@gmail.com>, "L. David Baron" <dbaron@dbaron.org>
On 2014/09/06 3:25, Tab Atkins Jr. wrote:
> On Fri, Sep 5, 2014 at 2:23 AM, L. David Baron <dbaron@dbaron.org> wrote:
>> On Thursday 2014-09-04 11:27 +0900, Brian Birtles wrote:
>>> ...
>>>    b) let active duration = infinity -> initial key frame value is
>>> shown, start event only is dispatched
>> This doesn't make particular sense to me.
> Agreed.  This is similar to the second limit behavior (iteration-count
> held at infinity, duration approaching 0), but diverges from the
> actual behavior is a seemingly arbitrary way; it has no relation to
> the behavior of a near-zero duration.

It does with regards to start/end events.

>>>    c) it's invalid -> nothing is shown, no events are dispatched
>> This would be ok.  Not sure whether it feels consistent with the
>> rest of the model, though.
> This would also be acceptable, per the principles cited above
> (technique 3 "define a different behavior entirely for the boundary"),
> but it's specifically noted as something you should avoid if possible,
> as it exposes rounding behavior.

It sounds like (a) is the preferred option.

For the sake of completeness, one reason to prefer (b) over (a) is that 
it's more consistent with regards to start/end events.

For example, if we have:

   animation: yer 0.0001s infinite

If we adopt (a), applications that depend on getting only a start event 
(and not an end event) will break on an implementation that represents 
times as an integer count of milliseconds (I *thought* IE did this but I 
can't seem to reproduce that at the moment so perhaps it has changed).

That said, I'm ok with (a).

Best regards,

Received on Monday, 8 September 2014 00:59:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:46 UTC