[web-animations-2][scroll-animations-1] Playing an animation with an unresolved scroll-timeline

[kevers-google]

In web-animations-2, enabling a seek time depends on having the auto-rewind flag set and not being associated with a finite timeline.

Suppose we have:

<style>
.scope {
  timeline-scope: --foo;
}
.animation {
  animation-name: my-anim;
  animation-timeline: --foo;
}
</style>
<div class=scope>
  <div class=animating></div>
</div>

As the timeline is not resolved, we cannot say it's a finite timeline, and thus calling play pauses the animation at the start or end. The animation's ready promise cannot be fulfilled while the timeline remains unresolved, and once resolved there is no reason to believe the animation's current time will align.

Propose the we tighten the rule for applying auto-rewind (i.e. seek time) to cases where we explicitly have a time-based timeline so that the the animation remains inactive. It will still be in a play-pending state and can start once the timeline is resolved.

Relace:

5. Let enable seek be true if the auto-rewind flag is true and has finite timeline is false. Otherwise, initialize to false.

With:

5. Let enable seek be true if the auto-rewind flag is true, the timeline is resolved, and has finite timeline is false. Otherwise, initialize to false.

Note that this proposed change would also affect null timelines, which presently are held at the start or end depending on playback rate, with an unresolvable ready promise.

@flackr @graouts @andruud @birtles

[css-meeting-bot]

The CSS Working Group just discussed [web-animations-2][scroll-animations-1] Playing an animation with an unresolved scroll-timeline, and agreed to the following:

• RESOLVED: we change the rules for auto-rewind so it has no effect if the timeline is unresolved, and see where else in the spec needs a similar change to the timeline condition

The full IRC log of that discussion

<TabAtkins> flackr: ok, so when you have an unresolved timeline, we give it a different beahvior (because we can't say it's finite yet)
<TabAtkins> flackr: so maybe we shouldn't be producing an animation effect for an unresolved timeline
<TabAtkins> flackr: i feel like we made that decision in a different context last week, so this might be nothing new
<TabAtkins> flackr: it does suggest there's a problem with the "is finite timeline" wording thruout the spec
<TabAtkins> flackr: might need to update to "is not a monotonic timline" or something
<TabAtkins> flackr: intent is clear - fi you don't have a known timeline yet, animation shouldn't produce an effect
<TabAtkins> astearns: yeah i fear this is not the only place we'll have to make this caveat
<TabAtkins> astearns: could resolve on making this change for this specific case + audit the rest of the spec?
<TabAtkins> flackr: yeah that sounds good
<TabAtkins> astearns: so proposed resolution is we change the rules for auto-rewind so it has no effect if the timeline is unresolved
<TabAtkins> flackr: yes
<TabAtkins> astearns: and look to see where else we need to do this
<TabAtkins> RESOLVED: we change the rules for auto-rewind so it has no effect if the timeline is unresolved, and see where else in the spec needs a similar change to the timeline condition