- From: kevers-google via GitHub <noreply@w3.org>
- Date: Tue, 14 Apr 2026 16:42:01 +0000
- To: public-css-archive@w3.org
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. -- GitHub Notification of comment by kevers-google Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13807#issuecomment-4245613027 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 14 April 2026 16:42:01 UTC