- From: Robert Flack via GitHub <sysbot+gh@w3.org>
- Date: Tue, 31 Jan 2023 20:44:48 +0000
- To: public-css-archive@w3.org
> To make sure calculation of effective scroll length includes the stuck duration? Yes, we need to make sure that as you scroll you make progress from when the element enters the cover range to when it leaves. The current behavior would I believe re-evaluate the cover range around the current sticky position so you'd get an animation that wouldn't progress as you scroll - it would just stick at a given progress. > Whoa, we were just on that page this week for implementing scroll animations, and I read the definition of `principal box` but couldn't understand from the spec that it actually means _excluding_ transforms, so I _did_ expect it to behave as it is currently in blink. On one hand, yes, it makes it trickier for authors when interacting with transforms, kind of like`:hover` is. So this will simplify it. But then your effective view ranges won't match the ones calculated by the timeline. Take for example a simple parallax effect, simply using `cover` will stop animating somewhere in the middle of the range. I've seen too many cases to count where developers using this feature stumble over the instability of a view timeline animating transform. @bramus @jh3y @argyleink may have some specific examples. Also, see my above demo https://github.com/w3c/csswg-drafts/issues/8298#issuecomment-1410787032 for how accounting for transform dramatically complicates the range of sticky position. Could you give an example of this simple parallax effect? How would it not be unstable if it is observing its transformed position and animating its own transform? -- GitHub Notification of comment by flackr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8298#issuecomment-1411046099 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 31 January 2023 20:44:49 UTC