Re: [csswg-drafts] [css-animations-2][web-animations-2][scroll-animations-1] Timeline returned for scope with no timeline providing that name. (#13807)

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`

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


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13807#issuecomment-4390005560 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 6 May 2026 16:17:55 UTC