- From: Navid Zolghadr via GitHub <sysbot+gh@w3.org>
- Date: Tue, 10 Jul 2018 23:51:37 +0000
- To: public-pointer-events@w3.org
The use case of listening to both types of pointermove and pointerrawmove is quite valid. They serve different purposes. The argument against having a "browser context"-wide api to enable/disable rAF-aligning is the use case of using other third-party libraries or just a big webpage which has a lot of components. With disabling rAF for the whole browsing context you are forcing all the other handlers and their bubbling handlers and everything to be run with a higher frequency even though they might not care about that. Introducing a new event easily lets us make it so that it is isolated from other handlers and also we can make cancelable and bubble of that to false to make sure it is not causing any additional processing. The bubble part of it is debatable as if the parent has a pointerrawmove handler it has already expressed its interest in processing those events. Regarding limiting it to the capturing mode I don't have a strong argument for it. I'm very open to the possibility of having it fired all the time if there are handlers on the page. If the page desires to circumvent the browser hit-testing (for performance reasons or whatever else) they can always use the capture api. -- GitHub Notification of comment by NavidZ Please view or discuss this issue at https://github.com/w3c/pointerevents/issues/214#issuecomment-404001181 using your GitHub account
Received on Tuesday, 10 July 2018 23:51:40 UTC