- From: Yehonatan Daniv via GitHub <sysbot+gh@w3.org>
- Date: Fri, 21 Feb 2025 14:10:02 +0000
- To: public-css-archive@w3.org
> Isn’t that inverted? I would imagine the code to look more like this: > > ```css > #elem { > animation: anim 5s linear infinite; > animation-timeline-name: --timeline-from-the-elem; > } > > video { > playback-timeline: --timeline-from-the-elem; /* Link my playback to the progress of the timeline of the animation */ > } > ``` > > I know, animation-timeline-name as a name for the property is a bit weird here. It should export a timeline that exposes the overallProgress of the animation. These are two different features: 1. Allow an animation use a video's playback as timeline. 2. Allow a video's playback use a progress-based timeline, e.g. ViewTimeline. Example for the first can be playing a canvas-based effect on a video. And the second is simply video scrubbing via scroll. Both are valid, but in this case we're referring to the second. ----------------- I like the `video()` approach as a declarative way of binding the progress of the animation to the playback, and then we can reuse all the props that animations bring with them. i think also quite coherent with the `VideoEffect` in WAAPI. Just wondering as possible future extensions, other things we may want to control on a video could be: 1. playbackrate 2. volume - though this is probably better handled via separate API for audio Just to keep in the background. -- GitHub Notification of comment by ydaniv Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11611#issuecomment-2674653454 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 21 February 2025 14:10:03 UTC