[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.

[dshin-moz]

@andruud doesn't that conflict with the definition found in css-animations-2 for animation-timeline?

If a named scroll progress timeline or view progress timeline is in scope on this element, use the referenced timeline as defined in Scroll-driven Animations §  Declaring a Named Timeline’s Scope: the timeline-scope property.

Otherwise the animation is not associated with a timeline.

[BorisChiou]

So it seems we have to update the spec for either the non-existing timeline name for animation-timeline in [css-animations-2] or the non-existing timeline name for "named timeline scoping and lookup" in [scroll-animations-1], to make their behaviors matched? They are talking about the same thing I think, but they expect different behaviors now (i.e. no associated with a timeline vs. an inactive timeline is used).

[dshin-moz]

This is an implementation consideration for Gecko. In the attached testcase, on Blink and WebKit, toggling scroll timelines (Clicking the "Switch" button, causing the animation to have an inactive/unassociated timeline for a moment) causes the animation to continue in the playing state, but toggling in and out of animation-timeline: none (By clicking the "None" button twice) causes the animation to become paused.

Intuitively, I think the former behaviour makes more sense? Also, I see that toggling between animation-timeline: auto and animation-timeline: none, the animation does not pause.

[css-meeting-bot]

The CSS Working Group just discussed [css-animations-2][web-animations-2][scroll-animations-1] Timeline returned for scope with no timeline providing that name., and agreed to the following:

• RESOLVED: unresolved timelines are represented in the OM as null
• RESOLVED: we try to preserve the requested animation state, details TBD

The full IRC log of that discussion

<ydaniv> flackr: question here was, you can have an animation that is using a timeline
<ydaniv> flackr: we don't know which specific timeline is going to be used yet cause it's using a name
<ydaniv> ... in some cases timeline is not provided yet for that name
<ydaniv> ... one WPT test is cehcking that, wanted to propose that the timeline evaluated to null instead of getting a timeline with source null
<ydaniv> ... the tests asserts that the timeline exists with a null source
<TabAtkins> q+
<ydaniv> ... you don't know yet if it's a real timeline or future timeline
<dshin-moz> q+
<astearns> ack fantasai
<ydaniv> ... some simplest solution would be to return timeline as null
<astearns> ack TabAtkins
<ydaniv> fantasai: what it means is that it has an effective timeline but is represented as null
<ydaniv> flackr: yes
<fantasai> s/effective/inactive/
<ydaniv> TabAtkins: also agree, I think it's a good solution
<kbabbitt> seems reasonable to me too, +1
<astearns> ack dshin-moz
<ydaniv> dshin-moz: effectively there wouldn't be a timeline from user's side
<ydaniv> ... so agree with that
<ydaniv> ... I think it's different from animation-timeline: none
<ydaniv> ... definition doesn't describe how it should behave, currently CH and SF put it in a <missed> state
<ydaniv> flackr: not sure what the right answer would be, but you should not see any keyframes there
<ydaniv> dshin-moz: timeline is effectively paused, but even if you find a timeline it will end up being in paused state
<ydaniv> flackr: internally we know it has a timeline that could be inserted, so perhaps should be in a playing state
<ydaniv> astearns: is that state visible to authors if we return null?
<ydaniv> flackr: it is, you can query it
<ydaniv> ... it's weird I agree
<ydaniv> dshin-moz: I think it's reasonable that if you want timelines to swap names they [missed]
<ydaniv> ... and if someone pauses animation we should keep that state
<ydaniv> astearns: first bit, sounds like we have consensus
<ydaniv> PROPOSED RESOLUTION: unresolved timelines are represented in the OM as null
<ydaniv> astearns: objections?
<ydaniv> RESOLVED: unresolved timelines are represented in the OM as null
<kbabbitt> q+
<ydaniv> astearns: should we resolve that unresolved timelines are in playing state?
<ydaniv> flackr: yes, think so
<astearns> ack kbabbitt
<ydaniv> kbabbitt: I think that the state is separate toggle on the timeline
<ydaniv> ... is that on timeline or animation?
<ydaniv> flackr: on the animation
<ydaniv> kbabbitt: so if timeline is unresolved does that affect the play state?
<ydaniv> flackr: if you have unresolved timeline you typically don't have start time
<dshin-moz> q+
<astearns> ack dshin-moz
<ydaniv> ... might need to be some detail to say "we konw this animation doesn't have a start time but we will know it once it's resolved"
<ydaniv> dshin-moz: I think we need to restore the play state, if authors pauses the animation and timeline is unresovled and resolved, should it be playing?
<ydaniv> flackr: we might need to, yeah, need to think this
<ydaniv> ... it's unclear "paused at what time"...
<ydaniv> dshin-moz: agreed
<ydaniv> astearns: shall we open a separate issue on what to do with play state around unresolved timelines?
<ydaniv> flackr: I think there are some details, like dshin-moz suggested to have state on the animtion to track this
<ydaniv> astearns: so what shall we resolved on?
<ydaniv> flackr: I guess that we try to preserve the requested animation state, details TBD how animations can track that
<ydaniv> ydaniv: +1
<kbabbitt> sgtm
<ydaniv> PROPOSED RESOLUTION: we try to preserve the requested animation state, details TBD
<ydaniv> astearns: objections?
<ydaniv> RESOLVED: we try to preserve the requested animation state, details TBD