- From: Majid Valipour via GitHub <sysbot+gh@w3.org>
- Date: Fri, 09 Oct 2020 18:19:56 +0000
- To: public-css-archive@w3.org
FWIW when filed this issue the motivation was mostly from implementation perspective. From Blink perspective the most logical thing for us to do was to update snap element mappings as part of the scroll tree. Because simply adding and removing a scroll container has well-defined hooks which we use to redistribute the snap areas to new scroll containers. Basically treating snapping as a scrolling feature allows us to reuse lots of pre-existing machinery that exists for scrolling. If any element can capture snap areas then you need to track their add/removal (and possibly maintain a separate tree for them 🤔 ). This is not impossible but I am not sure if it the usecase justifies the implementation cost in Blink. I am no longer have the most up to date information on this feature so take my opinion with a grain of salt. /cc @flackr who may provide better guidance. -- GitHub Notification of comment by majido Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4496#issuecomment-706333521 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 9 October 2020 18:19:58 UTC