Minutes from PEWG meeting 17 January 2024

Dear all,

the minutes from today's PEWG meeting are available at 
https://www.w3.org/2024/01/17-pointerevents-minutes.html and copied below:



PEWG
17 January 2024

Agenda: 
https://www.w3.org/events/meetings/6246bc85-4dae-43a8-a50c-9bc5a0829585/20240117T110000/
IRC log: https://www.w3.org/2024/01/17-pointerevents-irc

Attendees
flackr, mustaq, Patrick_H_Lauke, smaug

Chair: Patrick H. Lauke
Scribe: Patrick H. Lauke


* Clarify mousedown event target if the preceding pointerdown event 
listener removes the target #492 w3c/pointerevents#492 - this has an 
associated PR w3c/pointerevents#494

* Meta-issue: update WPT to cover Pointer Events Level 3 #445 
w3c/pointerevents#445

* brief discussion on PR about pointerEvent spec addition of deviceId


# Clarify mousedown event target if the preceding pointerdown event 
listener removes the target #492 w3c/pointerevents#492 - this has an 
associated PR w3c/pointerevents#494

Olli: regarding the comment 
https://github.com/w3c/pointerevents/pull/494#discussion_r1455881604 the 
algorithm didn't seem to address all points from Rob's comment

Mustaq: w3c/pointerevents#492 (comment) point 1 is already covered in 
the spec, section 11 - i think

Mustaq: right after second note

Mustaq: "Unless otherwise noted, the target of any mapped mouse event 
SHOULD be the same target as the respective pointer event unless the 
target is no longer participating in its ownerDocument's tree."

Mustaq: point 2 is covered by the last "Otherwise" in the PR 
https://github.com/w3c/pointerevents/pull/494/files

Mustaq: point 3 of Rob's is tricky. asked for remembering the target...

Rob: this is what you get by default

Mustaq: the last point in my PR should cover this

Rob: shouldn't need to have any check whether they're connected...I 
suppose you could find the common ancestor of td and tu

Rob: if that common ancestor is connected, then both td and tu must be 
connected. simpler perhaps?

Rob: if either td or tu are disconnected, they won't have a common 
ancestor. if both are disconnected, they may have a common ancestor that 
is also disconnected....

Mustaq: just want to make sure that we hone in on the DOM "at the 
current moment"

Rob: is this moment the moment of the pointerup dispatch or is it...

Mustaq: what happens if pointerup also modifies the DOM ...

Mustaq: moment of click dispatch

Rob: think it's ok, but it's important

Mustaq: we could land it and then add a second pass...

Rob: we could land this and test it, think it's ok to say at the moment 
of click dispatch

Rob: no expectation that click goes to the same element as the up

Mustaq: looking at the WPT we made for this ...

Rob: did also want it so that if the up had been captured, the click is 
also captured, right?

Rob: don't know if we did this yet, but i remember we discussed this to 
make it simpler for developers

Mustaq: my third point i think captures this

Rob: what i'm getting at is that that is computed at the pointerup, and 
that may be a good reason to keep this at the moment of pointerup 
dispatch (?)

Rob: probably simpler - if we're doing some calculation of click target 
at pointerup, then maybe we should also be calculating at the moment of 
pointerup dispatch

Rob: if pointerup modifies DOM so that nearest common ancestor is 
different, you won't see it in the click event

Mustaq: in my PR, point 4 about auxclick is affected by capturing, but 
not by common ancestor...

Mustaq: maybe we can shuffle points 3, 4, 5 to be simpler

Mustaq: let's look at PR again, if you spot a better/clearer way

Rob: common use case is either down or up event reorders the DOM (e.g. 
brings things on top by being the last in the DOM). still want click to 
be dispatched to the right thing. maybe that's not affected by when you 
compute target

Olli: in gecko, we store click target before dispatching up

Rob: which is consistent with how we want it to work

Olli: and looks like it's been done on purpose

Rob: that also makes capture case make much more sense

Rob: because after firing the up you lose capture

Mustaq: someone please write it down

Rob: click target is determined before dispatching the up

Mustaq: talking about WPTs

<mustaq> WPTs that cover this PR already are: 
pointerevents/pointerevent_after_target_{appended,removed}.html

<mustaq> except for the captured case, which I guess is covered elsewhere.

<mustaq> Perhaps this covers the last case: 
pointerevents/pointerevent_click_during_capture.html

Mustaq: i'll try to rewrite it this/next week. WPT coverage not clear, 
maybe we have cover for this one including target

ACTION: Mustaq to iterate over 
https://github.com/w3c/pointerevents/pull/494, others to give feedback 
before next meeting



# Meta-issue: update WPT to cover Pointer Events Level 3 #445 
w3c/pointerevents#445

Patrick: I think we're left with these at the moment 
https://github.com/w3c/pointerevents/issues?q=is%3Aclosed+label%3Aneeds-wpt+

Olli: I have reserved time for some of these

Rob: left a comment on PR 494 about what i think needs changing



# brief discussion on PR about pointerEvent spec addition of deviceId
w3c/pointerevents#495

Olli: concern that this competes with the idea we saw from Intel from a 
few months ago

https://www.w3.org/events/meetings/81ad3e7c-6dde-48ec-8693-09a9adea9f69/20230315T110000/

darktears/pen-customizations

Rob: Microsoft's new proposal is super-narrow - you only get the id 
until hardware can determine it / on pointerdown in most cases

<mustaq> There is another similar issue: w3c/pointerevents#353

Patrick: worth keeping an eye on this, but no immediate action until we 
get PE3 out the door. We'll reconvene in 2 weeks' time, thank you all



Summary of action items

* Mustaq to iterate over https://github.com/w3c/pointerevents/pull/494, 
others to give feedback before next meeting




-- 
Patrick H. Lauke

* https://www.splintered.co.uk/
* https://github.com/patrickhlauke
* https://flickr.com/photos/redux/
* https://mastodon.social/@patrick_h_lauke

Received on Wednesday, 17 January 2024 16:47:49 UTC