[css-animations-2][web-animations-2][scroll-animations-1] Timeline returned for scope with no timeline providing that name.

[flackr]

The wpt test Animation.timeline returns a timeline with no source for inactive deferred timeline in https://github.com/web-platform-tests/wpt/blob/master/scroll-animations/css/animation-timeline-deferred.html is testing that if you have the following:

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

That if you get the animation you will get a timeline with a null source:

    let animation = main.querySelector('.animating').getAnimations[0];
    assert_equals(animation.timeline.source, null);

This seems reasonable, however I do not believe we have discussed or specified it, so opening this to take a resolution to specify this behavior and I think it is a bit tricky, so we should agree on it. In particular, there are a few details we should agree on.

1. Per the test expectation, animation.timeline returns a generic AnimationTimeline object.
2. Since we cannot know what type the eventually attached animation timeline is (e.g. ViewTimeline or ScrollTimeline), it is a generic AnimationTimeline instance which means source is not a field on it.
3. Since the type of the timeline depends on the eventual source, I expect that the timeline instance you get will not have the same identity as when a real source is attached. This raises the question of what should the identity match to? The simplest implementation-wise would be to have a single unresolved timeline instance that is used anytime we have an unresolved animation timeline, so I would propose this - all scoped timelines without an attached timeline return a shared unresolved timeline instance.

@kevers-google @andruud please add anyone else who may have context.

[kevers-google]

@graouts

[kevers-google]

Returning a shared unresolved timeline instance sounds reasonable. As a generic AnimationTimeline object we won't know whether the resolved timeline is time or progressed based. Presently, we don't have timeline names resolving to time based timelines, but down the road this could be a viable path to declarative group effects.

The distinction of time or progress based is important when starting the animation to know whether the animation should set a hold time or remain pending with an unresolved value for current time. Presently we set the hold time unless the timeline is finite. The unresolved timeline should likely also leave hold time unresolved so the animation is not in effect until the timeline is resolved.

Calling currentTime on an animation with the incompatible units throws a type error. While the timeline remains unresolved, we cannot make this assessment. We have a similar issue with startTime. Perhaps these methods should throw a type error when called with an unresolved timeline.

[andruud]

Hmm, yeah. The spec does say an inactive timeline should be used in these cases (also before the recent edits in this area), but the nature of this inactive timeline is not really defined.