Re: [pointerevents] Allow pointerup-activated elements to set click target differently. (#637)

This PR [was discussed](https://www.w3.org/2026/02/11-pointerevents-minutes.html#6a6e) in the February 11 Pointer Events meeting.

The discussion there suggested using [Pointer Capture](https://w3c.github.io/pointerevents/#pointer-capture) as an alternative.  I think this seems possible, but it also seems like it has a set of issues of its own.

In particular, I think the model if we went with pointer capture would be that when the mouse is down and over a menuitem element, that element captures the pointer (and release it when it leaves).  This capturing probably isn't strictly necessary for the first menuitem (before the pointer moves into a different one), but it's probably good to do it anyway to be consistent.  Then, when the mouseup happens (and I *think* the mouseup still gets sent to its normal target -- I hope so at least), the click will go to the menuitem that's doing the capturing.

This seems a little "weird" in 2 ways:
1. The capturing is constantly changed across a single user gesture.  This seems like an "unusual" use of capturing, but maybe that's OK.
2. It's a little unclear to me how a web platform primitive is supposed to invoke setting and releasing of pointer capture.  Is it OK to just invoke those algorithms, with the resulting effects on any developer-set pointer capture and on the `hasPointerCapture` API, or does it need to guard against developer-set pointer capture, and only capture if there is none?

I'm curious if anyone (e.g., @flackr @mustaqahmed @smaug----) has opinions on whether that seems like a workable approach and what you think of the comments above.

-- 
GitHub Notification of comment by dbaron
Please view or discuss this issue at https://github.com/w3c/pointerevents/pull/637#issuecomment-4595588504 using your GitHub account


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

Received on Monday, 1 June 2026 18:59:19 UTC