[pointerevents] Should a captured pointer send transition events by default?

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