- From: Robert Flack via GitHub <sysbot+gh@w3.org>
- Date: Thu, 22 Jun 2023 14:35:00 +0000
- To: public-css-archive@w3.org
This is a creative interpretation of playback rate which I can see how at a high level fits. However, playback rate already has a very specific definition of how it affects animation timing which is heavily used in many of the calculations. A negative playback rate is also used to [reverse animations](https://drafts.csswg.org/web-animations-1/#reversing-an-animation-section). All of this currently works as spec'd on scroll animations. This would make playback rate have special behavior for non-time based animations, and it would be really hard to avoid unexpected issues when other timing related properties change at the same time - as the proposed behavior is based on the previous state. E.g. what happens if you change the start time of the animation, or the duration, does it slowly progress towards the new time value? > it's effectively a linear interpolation on each frame between current progress and last progress Naively, this would make the speed of the adjustment depend on the frame rate the browser is able to render or particular device framerates. I would think that if we have a mechanism for doing this it should be framerate independent, i.e. based on the time that had passed. Also while the progress per frame is a linear interpolation, the progress over time will be non-linear, e.g. it'll make 0.5, then 0.75, then 0.875 progress never technically getting to the current time value. I do feel like this is the same high level feature as issue #7059, just approaching it from a different direction. -- GitHub Notification of comment by flackr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8816#issuecomment-1602752156 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 22 June 2023 14:35:02 UTC