- From: Rick Byers via GitHub <sysbot+gh@w3.org>
- Date: Wed, 25 May 2016 14:02:32 +0000
- To: public-pointer-events@w3.org
To summarize, I think we're all on the same page wrt. the use case, the debate is just centering around how easy/hard the different ways to implement that use case are: 1. Using pointer capture and boundary events (what works in Edge today but this issue is questioning) with custom click-detection logic 2. Using pointer capture and explicit hit testing (`elementFromPoint`) with custom click-detection logic. 3. Not using pointer capture, but using boundary and click events. Suppress events reaching other targets with a temporary window-level capturing listener that does `stopImmediatePropagation`. Does someone want to try writing the simplest possible code they can for these 3 scenarios so we can compare them concretely? Of course ease of development is just one issue here, once we have some conclusion from that we also need to consider (arguably more important): 1. Complexity of the model (eg. this issue seems to make it hard for us to precisely define / reason about the behavior) 2. Compatibility impact of changing this > I do wonder if the UA can make more optimizations in its hit testing than the web developer can in JavaScript That's not the case in blink at least. `elementFromPoint` is basically a direct path into the same hit testing algorithm we use internally, and I see that as an important property (hit-testing is a key primitive of the platform, if we internally had access to some more optimized version, we really should be exposing that to web developers somehow too). -- GitHub Notification of comment by RByers Please view or discuss this issue at https://github.com/w3c/pointerevents/issues/61#issuecomment-221585715 using your GitHub account
Received on Wednesday, 25 May 2016 14:02:34 UTC