Re: [pointerevents] Should a captured pointer send boundary events by default? (#566)

I'm still on the side of not doig hit testing and not sending
boundary events during capture. Regarding Edge's implementation, I'm
curious if you've done any testing regarding the goal of 60fps JS-driven
dragging on mobile devices with their current implementation.

On Mon, Jan 12, 2026 at 4:50 PM Rick Byers ***@***.***> wrote:

> *RByers* created an issue (w3c/pointerevents#566)
> <https://github.com/w3c/pointerevents/issues/566>
>
> 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
> <https://github.com/w3c/pointerevents/issues/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 <https://github.com/w3c/pointerevents/issues/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. We're struggling to define
>       this precisely (#63 <https://github.com/w3c/pointerevents/pull/63>,
>       #15 <https://github.com/w3c/pointerevents/issues/15>)
>    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 <https://github.com/scottgonzalez> @jacobrossi
> <https://github.com/jacobrossi>,
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/w3c/pointerevents/issues/566>, or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AABCO36POWTL2KJ2R6YB7ET4GQJJXAVCNFSM6AAAAACRO7VNFOVHI2DSMVQWIX3LMV43ASLTON2WKOZTHAYDMMJRGY4TCNA>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>


-- 
GitHub Notification of comment by scottgonzalez
Please view or discuss this issue at https://github.com/w3c/pointerevents/issues/566#issuecomment-3796884289 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Sunday, 25 January 2026 16:14:35 UTC