- From: Robert Flack via GitHub <sysbot+gh@w3.org>
- Date: Tue, 20 May 2025 16:47:01 +0000
- To: public-css-archive@w3.org
> +1 to [@flackr](https://github.com/flackr). That's usually the case, so probably solving velocity will solve more cases. If we want to persist the velocity past the `scrollend` point then we should probably solve transitioned progress of animations, and that might be something we can build on top of. Here is an example of both using [@bramus](https://github.com/bramus)' custom properties trick (SDA required): https://jsbin.com/calicaxuhe/edit?css,output Right, solving #7059 would mean that a VelocityTimeline could be combined with this delay to implement a an effect that persists past the end. > Furthermore, if we solve velocity/delayed we should probably do so for pointer-driven animations as well. Yes, this makes sense to me. > Though there are use-cases where direction is used without depending on velocity. These are usually show/hide of fixedpos UI, usually on mobile. For example: show/hide scroll-to-top button or header when scrolling back up, kinda like the addressbar does it. Right, in the vast majority of these cases, developers don't want the fixed pos ui to go away when scrolling stops - otherwise it would prevent a usability nightmare. For cases where the bar scrolls in as the user scrolls we have talked about this in #5670 where I proposed that a [tweak](https://github.com/w3c/csswg-drafts/issues/5670#issuecomment-887655710) to position sticky could work. -- GitHub Notification of comment by flackr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6400#issuecomment-2895178773 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 20 May 2025 16:47:02 UTC