- 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