- From: Yehonatan Daniv via GitHub <sysbot+gh@w3.org>
- Date: Fri, 03 Feb 2023 14:02:28 +0000
- To: public-css-archive@w3.org
I'd like to take a shot at revisiting this issue, because this pattern is used quite often. I think we can take a different angle at this, by defining a friction factor to the interpolation on each frame between last and current positions, instead of having a transition with a defined duration on the animation, which is in fact the implicit way of calculating this factor. Friction is actually `1 - playbackRate`, so for the default `playbackRate=1` we get friction=0 and we get the default link between scroll and effect. For `0 < playbackRate < 1` we start getting friction>0 and the effect starts lagging behind the scroll progress in a sort of a transition and we get this drag. I think this is what @smfr was referring to above, and I think this might also simplify implementation. The way the `playbackRate` is used here is by interpolating on each frame from last position to current position using a simple lerp: `a * (1 - t) + b * t`, where `t` is the `playbackRate`. So you can see how for `t=0` the animation is paused, and we get default behavior for `t=1`. Applying easing on this effect is less common. Since the lerp already provides a nice curve, adding an extra easing on top is a bit redundant, but may be possible, I'm not quite sure yet whether this should be expressed in the interpolation function (i.e. instead of a simple lerp) or perhaps in some other way, modifying the progress that is calculated by it. Still an open question, if we consider the above, is if/how we can expose a declarative syntax/API for this. @flackr @birtles WDYT? -- GitHub Notification of comment by ydaniv Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7059#issuecomment-1415913052 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 3 February 2023 14:02:30 UTC