[scroll-animations] Should setting iterations to Infinity via a call to updatingTiming() throw?

[graouts]

I'm looking at the WPT test for updateTiming() at scroll-timelines/effect-updateTiming.html and noticed that it has this subtest:

test(t => {
  const anim = createScrollLinkedAnimationWithTiming(t, { duration: 2000 });
  anim.play();
  assert_throws_js(TypeError, () => {
    anim.effect.updateTiming({ iterations: Infinity });
  }, "test");
}, `Throws when setting iterations to Infinity`);

I couldn't find any spec text that would support this, although it seems reasonable.

[graouts]

Cc @kevers-google @flackr @andruud.

[ydaniv]

The web-animations-1 spec says this:

The number of times an animation effect repeats is called its iteration count. The iteration count is a real number greater than or equal to zero. The iteration count may also be positive infinity to represent that the animation effect repeats indefinitely.

Constructing effects with Infinity works everywhere. Seems wrong to be failing on update.

[flackr]

Constructing effects with Infinity works everywhere. Seems wrong to be failing on update.

We have many cases in the web animations spec where trying to do something nonsensical throws (e.g. negative iterations, negative duration, passing unsorted keyframes to setKeyframes, trying to play an infinite duration or iteration animation in reverse).

In this test case, having infinite iterations results in a total time of infinity when converting to a proportional animation, meaning that naively start delay, iteration duration and end delay would all be 0 I suppose. This can't match the expected result of the animation filling the specified range, so it seems like throwing an error might be reasonable in the same way you can't start a reverse direction infinite iteration animation.

[ydaniv]

Ohh, progress-based 🤦 missed that somehow.