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

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

Received on Sunday, 5 October 2014 23:16:07 UTC