- From: Rick Byers via GitHub <sysbot+gh@w3.org>
- Date: Wed, 11 May 2016 16:22:45 +0000
- To: public-pointer-events@w3.org
We discussed this on [the call today](https://www.w3.org/2016/05/11-pointerevents-minutes.html) and nobody present could explain why the button scenario would want capture at all, it's most easily implemented by not using capture and having only a `click` listener and CSS `:hover` styling. I argued there are 3 consistency principles we're trying to uphold here: 1. CSS hover matches poitnerenter/pointerleave state 2. pointerenter/pointerleave state tell you what part of the tree will receive pointer events 3. during capture, only the captured element receives any pointer events The simplest model that does all this is the "capture overrides hit testing" concept. On capture, transition events behave as if the pointer moved to the captured element (gets `pointerenter` and CSS hover) and stays there for the duration of capture. On release behaves as if the mouse jumped to it's current position. Chrome is going to proceed with implementing this model for now (since it's much simpler and we don't have a good understanding of why the more complex Edge behavior is useful) and get some data on web compat. In parallel @teddink is going to talk with @jacobrossi and see if they can explain the benefits of Edge's current behavior. -- GitHub Notification of comment by RByers Please view or discuss this issue at https://github.com/w3c/pointerevents/issues/61#issuecomment-218512170 using your GitHub account
Received on Wednesday, 11 May 2016 16:22:47 UTC