[web-animations-2] procedure to convert a time-based animation to a proportional animation might yield a division by 0

[graouts]

The procedure to convert a time-based animation to a proportional animation has the following sub-step:

Let total time be equal to end time

… and then several steps after that where we divide values by total time. However, total time may be 0, for instance if the specified delay is the negative value of the specified iteration duration, as is the case in the WPT test scroll-animations/scroll-timelines/effect-updateTiming.html:

test(t => {
  const anim = createScrollLinkedAnimationWithTiming(t, {duration: 100, delay: -100})
  anim.play();
  anim.effect.updateTiming({ delay: -100 });
  assert_equals(anim.effect.getTiming().delay, -100, 'set delay -100');
  assert_equals(anim.effect.getComputedTiming().delay, -100,
                'getComputedTiming() after set delay -100');
  assert_percents_equal(anim.effect.getComputedTiming().endTime, 0,
                        'getComputedTiming().endTime after set delay -100');
}, 'Allows setting the delay to a negative number');

The spec needs a provision for computing the start delay, end delay and iteration duration in this case.

[graouts]

Cc @kevers-google, @flackr and @andruud who are the knowledgeable persons in this area.

[graouts]

By the looks of it, in that situation, Chrome sets start delay, end delay and iteration duration to 0%, maintaining the end time at 0%.

[flackr]

I think this leads to the most intuitive behavior. An animation with end time = 0 immediately produces its after phase effect once you pass the start time. Maintaining the end time here achieves the same result.

If we tried to force the animation to have some duration it would be unclear how to distribute that duration.

[graouts]

We should clarify the spec to have this behavior.

[graouts]

For reference, this was discovered while working on WebKit/WebKit#37219.