- From: Rick Byers via GitHub <sysbot+gh@w3.org>
- Date: Wed, 04 May 2016 17:52:53 +0000
- To: public-pointer-events@w3.org
RByers has just created a new issue for https://github.com/w3c/pointerevents: == Should a captured pointer send transition events by default? == Edge and the spec send `pointerleave`/`pointerout` when a captured pointer moves outside the bounds of an element (and it's descendants), and `pointerenter`/`pointerover' whenever it moves back in. There's been some discussion in various places about the implications of this and whether it should change, so [I offered](https://www.w3.org/2016/05/04-pointerevents-minutes.html#item04) to file a dedicated issue to summarize the arguments to see if we can come up with a plan here. In particular, this is a subset of Chrome's primary ship-blocking spec issue: #8. I'll try to keep the above summary updated as we debate the details in the conversation below. ## Advantages of sending transition events during capture 1. Edge already ships this, we shouldn't consider changing without a really good reason. 2. This is useful for capture scenarios like buttons where you want the button style to "pop back out" when the cursor is dragged off the capturing element. * But in that case, should the button really even be capturing? It needs to also know to ignore `click` events seen after `pointerleave`, so it's mostly acting like an uncaptured control, right? ## Disadvantages of sending transition events during capture 1. It requires the UA to do hit-testing on each `pointermove` events during capture (#8) * Some fast paths may be possible in common cases, but detecting these cases is hard in itself. Eg. if it's possible for a capturing element to be occluded by another element (possibly even via an accelerated animation), then a simple bounds check is insufficient. 2. It means the semantics of the transition events are fundamentally different during capture * Normally an element will not receive `pointermove` events after it sees a `pointerleave`. As currently defined, when an element has capture the transition events no longer say anything about the event stream. * `pointerover` and `pointerout` events normally apply only to the immediate bounds of the element, but under capture they (currently) behave like `pointerenter` and `pointerleave` where they reflect the bounds of the captured element and all it's descendants. 3. It means capture can't be defined simply as a modification of (the as yet unspecified) hit-testing algorithm. * A very conceptually simple model for capture would be to say that it's just an early-out from hit-testing - makes all pointer hit tests return the captured node. This is consistent with how implicit touch capture works in browsers like Safari and Chrome today. 4. In drag and drop scenarios (a common use case for capture) the events are only a potential hinderance * Typically in drag and drop the application will rely on it's own intersection testing (does the dragged item overlap a drop target at all) rather than built-in hit testing * If you start dragging near the edge of an element and drag slowly, you may receive a constant stream of `pointerleave` and `pointerenter` events as the dragged element is continually repositioned to remain underneath the mouse cursor. ## Possible alternatives 1. Don't send transition events during capture at all * I.e. define capture to be just a modification of pointer hit testing (affecting both `:hover` and transition events). * Scenarios wanting capture with hover-style behavior (like the button scenario) would need to implement their own hit-testing (`elementFromPoint`) or boundary checks on `pointermove` listeners. This should be simple to do. * We'd need to do some compat testing to determine the potential for real-world breakage here. It's not clear how to measure this in practice (just because a `pointerlevae` handler is invoked during capture doesn't mean that the handler's behavior was actually desired by the developer). Thoughts? 2. Add a boolean option to `setPointerCapture` to specify the behavior * Depending on the default value, this would strike a tradeoff between the two options What have I missed / got wrong in this summary? Other arguments / details? /cc @scottgonzalez @jacobrossi, Please view or discuss this issue at https://github.com/w3c/pointerevents/issues/61 using your GitHub account
Received on Wednesday, 4 May 2016 17:54:48 UTC