[web-animations-1] Effect value algorithm has strange early-exit; why?

[stephenmcgruer]

This came up when investigating #3290 . I was all ready to declare that the web-animations-1 spec already says you must always interpolate and thus we just need to add a note to make that concrete, when I discovered the following in the effect value of a keyframe effect algorithm:

11. Populate interval endpoints by following the steps from the first matching condition from below:
  -> If iteration progress < 0 and there is more than one keyframe in property-specific keyframes with a computed keyframe offset of 0,
    Add the first keyframe in property-specific keyframes to interval endpoints.
  -> If iteration progress ≥ 1 and there is more than one keyframe in property-specific keyframes with a computed keyframe offset of 1,
    Add the last keyframe in property-specific keyframes to interval endpoints.
  -> Otherwise,
    Append to interval endpoints the last keyframe in property-specific keyframes whose computed keyframe offset is less than or equal to iteration progress and less than 1. If there is no such keyframe (because, for example, the iteration progress is negative), add the last keyframe whose computed keyframe offset is 0.
    Append to interval endpoints the next keyframe in property-specific keyframes after the one added in the previous step.
12. For each keyframe in interval endpoints: [irrelevant step] 
13. If there is only one keyframe in interval endpoints return the property value of target property on that keyframe.

What are the purposes of the special cases in step 11? They can then cause an early exit with no interpolation for either negative iteration-progress or (weirdly) iteration-progress >= 1. Consider the following animation:

target.animate([
  {'left': '0%', offset: '0'},
  {'left': '100px', 'offset': 1},
  {'left': '100px', 'offset': 1},
], {
  duration: 1000, fill: 'forwards'
});

At progress 1.0, this has a value of 100px rather than calc(0% + 100px), because of the special cases. This can be seen by running the attached reproduction in Firefox (available at http://output.jsbin.com/daxicil/quiet). The output is:

Version with one final keyframe: calc(100px + 0%)
Version with two final keyframes: 100px

repro.txt <-- actually html, but github wont upload that

[birtles]

I believe it's because if the author writes:

target.animate([
  {'left': '0%', offset: '0'},
  {'left': '100px', 'offset': 1},
  {'left': '200px', 'offset': 1},
], {
  duration: 1000, fill: 'forwards'
});

then we need to define the result when the animation is sampled at iteration progress >= 1. In this case the author wants it to make a discrete jump to '200px' at that point.

[birtles]

@stephenmcgruer Does my comment answer your question or do you think this needs to be changed?

[stephenmcgruer]

Wow, this is a blast from the past 🤣

I'm afraid I no longer work on animations. @flackr may have thoughts, otherwise given how old this issue is it seems reasonable to just close it out (I have no context for it in my brain anymore :))

[flackr]

Yes, the rationale and conditions make sense to me.