Re: [pointerevents] Defining event orders through a "state of the input device" (#438)

Hmm, fair point about capturing `pointerup`.  Can we perhaps say that in this case the `pointerup` event forces the implicit release _after_ hit-testing is done so event target is not affected by this state change?  

I think logically we cannot be in the captured state without being in the active button state, but the other way around is possible.  Current spec wording seems to support this notion by allowing explicit capture only from within the active button state, right?  If we don't have this state vs sub-state hierarchy, "active button" vs "captured" would be two partially-overlapped states which IMHO is one source of the complicated event ordering discussions.

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


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

Received on Wednesday, 27 April 2022 21:10:56 UTC