- From: Khushal Sagar via GitHub <sysbot+gh@w3.org>
- Date: Thu, 29 Sep 2022 19:36:37 +0000
- To: public-css-archive@w3.org
> which is later only progressed if the user continues scrolling on same direction. These types of transitions are generally set up to commit to either the new or current state based on how far the user scrolls. So you want to keep track if the user continues scrolling and what the offset is when the gesture ends. Another complexity which I was unsure about was, do we need to run another hit test and lock a new scroll target since the scrolling container which initiated the transition could go away as a part of the DOM update? > what would the duration of the timeline be? Would the author need to define some sort of a "virtual" length? I assumed it could use [scroll-timeline](https://drafts.csswg.org/scroll-animations-1/#scroll-timelines-named) but haven't thought through the details. > what happens if the author did set animation-timeline to anything other than auto, in a way that's also future compat. I'm assuming animations using scroll-timeline and view-timeline are ignored if there is no user interaction. Would that already be the case with the definition above that only considers an animation active if its in `running` or `paused` state? I don't know what state these are in if there isn't an active scroll gesture. If the above is reasonable then I'd be ok with not special-casing animations using a different timeline. > This may still be useful for allowing authors to still be able to do custom stuff +1 -- GitHub Notification of comment by khushalsagar Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7785#issuecomment-1262728559 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 29 September 2022 19:36:39 UTC