Re: [web-animations] Web Animations minutes, 2 Oct 2014

I think that having an 'always on' animation is pretty useful.

It might be enough just to have an 'always on from the start of the
document's timeline' animation, but an author could pretty easily end up
accidentally going outside that bound when manipulating currentTime and
playbackRate on a player. Having an animation guaranteed to be running no
matter what seems like a pretty basic primitive.

If we accept the need for this primitive, then 'delay = -Infinity;
iterations = Infinity' seems like a pretty straightforward way to represent
it. A little bit of extra specification cost is worth it if the result is
intuitive to developers.

Cheers,
    -Shane

On Mon, Oct 6, 2014 at 10:15 AM, Brian Birtles <bbirtles@mozilla.com> wrote:

> On 2014/10/04 0:49, Tab Atkins Jr. wrote:
>
>> What I was more concerned about is that .currentIteration would be
>> Infinity for *every* observable iteration.  You can't do Infinity+1,
>> Infinity+2, etc.
>>
>
> Right.
>
>  With regards to working out your position in an iteration, I think it
>>> depends if you allow the start time or the delay to be negative infinity. I
>>> think it's probably better to only allow the delay (since that applies to
>>> the animation which is also where you'd set the infinitely repeating
>>> behavior; and it means we don't end up with infinite current times in the
>>> player).
>>>
>>
>> I don't understand how limiting the infinite behavior to just delay
>> helps.  A negative infinity delay means the animation is treated as
>> having started infinity ago, and so there's still no way to tell how
>> far you are into the current iteration that's executing at the current
>> moment.
>>
>
> The start time remains fixed. The delay is just an offset from the start
> time and it's calculated at a different stage (within the animation, not
> the player) so restricting negative infinity to delay does simplify things
> a little.
>
>  I think there's a fair bit of extra spec work involved to make that
>>> happen, but I think it's possible?
>>>
>>
>> Possible, probably, but I'm unsure it's worthwhile.  Is this just to
>> make it so that authors don't have to care as much about some
>> calculations possibly returning Infinity?
>>
>
> Right, I'm not certain it's worthwhile either. The motivation is so that
> you can author an animation that repeats infinitely no matter what time you
> seek to. Currently you can author an animation that always runs whenever
> you seek forwards, but not backwards. I'm not sure how important that is to
> fix and might be worth deferring.
>
> Brian
>
>