- From: Florian Rivoal via GitHub <sysbot+gh@w3.org>
- Date: Sat, 19 Sep 2020 01:31:49 +0000
- To: public-css-archive@w3.org
> maybe there are cases in which you want to know beforehand when snapping will happen and maybe be able to cancel it. I suspect it's better to leave this out (as you did) unless there are extremely compelling use cases for that. Having potentially blocking JS calls in the middle of scrolling tends make browser engineers very sad. Other questions: * Is your event supposed to be fired when the browser has landed on the snapped position and stopped moving, or as soon as it has decided on a snap position, even though it might still be moving towards it? (I think it's the former, but it's good to be clear) * If the user starts scrolling away from a snap point, but not very far, releases, and the browser snaps back to the same one, do we fire a new event because we resnapped, or not, because we effectively didn't leave the snappoint? * Same question as above, but with the user resizing the window rather than scrolling. * Same question as above, but with the "resnapping" being triggered by a change in content / styling * If the snap poisition is continuously moving due to an animation or a transition, and the browser continuously tracking it, do we send a stream a events because we're continuously resnapping, or not because we never leave the snapped state? -- GitHub Notification of comment by frivoal Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/156#issuecomment-695145852 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 19 September 2020 01:31:51 UTC