15:59:50 <RRSAgent> RRSAgent has joined #pointerevents
15:59:54 <RRSAgent> logging to https://www.w3.org/2024/01/17-pointerevents-irc
16:00:09 <Patrick_H_Lauke> Meeting: PEWG
16:00:15 <Patrick_H_Lauke> Chair: Patrick H. Lauke
16:00:25 <Patrick_H_Lauke> Agenda: https://www.w3.org/events/meetings/6246bc85-4dae-43a8-a50c-9bc5a0829585/20240117T110000/
16:00:33 <Patrick_H_Lauke> Scribe: Patrick H. Lauke
16:00:39 <flackr> flackr has joined #pointerevents
16:00:39 <Patrick_H_Lauke> ScribeNick: Patrick_H_Lauke
16:00:42 <Patrick_H_Lauke> present+
16:00:47 <Patrick_H_Lauke> present+ flackr
16:01:12 <Patrick_H_Lauke> present+ smaug
16:01:16 <Patrick_H_Lauke> present+ mustaq
16:02:55 <Patrick_H_Lauke> TOPIC: Clarify mousedown event target if the preceding pointerdown event listener removes the target #492 https://github.com/w3c/pointerevents/issues/492 - this has an associated PR https://github.com/w3c/pointerevents/pull/494
16:04:59 <Patrick_H_Lauke> 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
16:05:33 <Patrick_H_Lauke> Mustaq: https://github.com/w3c/pointerevents/issues/492#issuecomment-1823553102 point 1 is already covered in the spec, section 11 - i think
16:05:49 <Patrick_H_Lauke> Mustaq: right after second note
16:06:21 <Patrick_H_Lauke> 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."
16:07:04 <Patrick_H_Lauke> Mustaq: point 2 is covered by the last "Otherwise" in the PR  https://github.com/w3c/pointerevents/pull/494/files
16:07:41 <Patrick_H_Lauke> Mustaq: point 3 of Rob's is tricky. asked for remembering the target...
16:07:49 <Patrick_H_Lauke> Rob: this is what you get by default
16:08:11 <Patrick_H_Lauke> Mustaq: the last point in my PR should cover this
16:08:50 <Patrick_H_Lauke> Rob: shouldn't need to have any check whether they're connected...I suppose you could find the common ancestor of td and tu
16:09:08 <Patrick_H_Lauke> Rob: if that common ancestor is connected, then both td and tu must be connected. simpler perhaps?
16:10:16 <Patrick_H_Lauke> 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....
16:10:56 <Patrick_H_Lauke> Mustaq: just want to make sure that we hone in on the DOM "at the current moment"
16:11:06 <Patrick_H_Lauke> Rob: is this moment the moment of the pointerup dispatch or is it...
16:11:19 <Patrick_H_Lauke> Mustaq: what happens if pointerup also modifies the DOM ...
16:11:24 <Patrick_H_Lauke> Mustaq: moment of click dispatch
16:11:31 <Patrick_H_Lauke> Rob: think it's ok, but it's important
16:11:42 <Patrick_H_Lauke> Mustaq: we could land it and then add a second pass...
16:11:59 <Patrick_H_Lauke> Rob: we could land this and test it, think it's ok to say at the moment of click dispatch
16:12:21 <Patrick_H_Lauke> Rob: no expectation that click goes to the same element as the up
16:12:43 <Patrick_H_Lauke> Mustaq: looking at the WPT we made for this ...
16:13:04 <Patrick_H_Lauke> Rob: did also want it so that if the up had been captured, the click is also captured, right?
16:13:20 <Patrick_H_Lauke> Mustaq: don't know if we did this yet, but i remember we discussed this to make it simpler for developers
16:13:28 <Patrick_H_Lauke> s/Mustaq/Rob
16:13:50 <Patrick_H_Lauke> Mustaq: my third point i think captures this
16:14:21 <Patrick_H_Lauke> 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 (?)
16:15:13 <Patrick_H_Lauke> 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
16:15:53 <Patrick_H_Lauke> Rob: if pointerup modifies DOM so that nearest common ancestor is different, you won't see it in the click event
16:16:29 <Patrick_H_Lauke> Mustaq: in my PR, point 4 about auxclick is affected by capturing, but not by common ancestor...
16:16:39 <Patrick_H_Lauke> Mustaq: maybe we can shuffle points 3, 4, 5 to be simpler
16:16:55 <Patrick_H_Lauke> Mustaq: let's look at PR again, if you spot a better/clearer way
16:17:46 <Patrick_H_Lauke> 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
16:17:56 <Patrick_H_Lauke> Olli: in gecko, we store click target before dispatching up
16:18:05 <Patrick_H_Lauke> Rob: which is consistent with how we want it to work
16:18:14 <Patrick_H_Lauke> Olli: and looks like it's been done on purpose
16:18:23 <Patrick_H_Lauke> Rob: that also makes capture case make much more sense
16:18:34 <Patrick_H_Lauke> Rob: because after firing the up you lose capture
16:18:45 <Patrick_H_Lauke> Mustaq: someone please write it down
16:18:56 <Patrick_H_Lauke> Rob: click target is determined before dispatching the up
16:19:23 <Patrick_H_Lauke> Mustaq: talking about WPTs
16:20:09 <mustaq> WPTs that cover this PR already are: pointerevents/pointerevent_after_target_{appended,removed}.html
16:20:36 <mustaq> except for the captured case, which I guess is covered elsewhere.
16:23:27 <mustaq> Perhaps this covers the last case: pointerevents/pointerevent_click_during_capture.html
16:24:13 <Patrick_H_Lauke> Mustaq: i'll try to rewrite it this/next week. WPT coverage not clear, maybe we have cover for this one including target
16:26:04 <Patrick_H_Lauke> ACTION: Mustaq to iterate over https://github.com/w3c/pointerevents/pull/494, others to give feedback before next meeting
16:27:12 <Patrick_H_Lauke> TOPIC: Meta-issue: update WPT to cover Pointer Events Level 3 #445 https://github.com/w3c/pointerevents/issues/445
16:27:40 <Patrick_H_Lauke> Patrick: I think we're left with these at the moment https://github.com/w3c/pointerevents/issues?q=is%3Aclosed+label%3Aneeds-wpt+
16:28:03 <Patrick_H_Lauke> Olli: I have reserved time for some of these
16:28:16 <Patrick_H_Lauke> Rob: left a comment on PR 494 about what i think needs changing
16:31:32 <Patrick_H_Lauke> TOPIC: brief discussion on PR about pointerEvent spec addition of deviceId
16:31:34 <Patrick_H_Lauke> https://github.com/w3c/pointerevents/pull/495
16:33:40 <Patrick_H_Lauke> Olli: concern that this competes with the idea we saw from Intel from a few months ago
16:34:55 <Patrick_H_Lauke> https://www.w3.org/events/meetings/81ad3e7c-6dde-48ec-8693-09a9adea9f69/20230315T110000/
16:35:29 <Patrick_H_Lauke> https://github.com/darktears/pen-customizations
16:37:03 <Patrick_H_Lauke> Rob: Microsoft's new proposal is super-narrow - you only get the id until hardware can determine it / on pointerdown in most cases
16:37:55 <mustaq> There is another similar issue: https://github.com/w3c/pointerevents/issues/353
16:43:46 <Patrick_H_Lauke> 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
16:43:53 <Patrick_H_Lauke> rrsagent, set logs world-visible
16:43:58 <Patrick_H_Lauke> rrsagent, generate minutes
16:44:00 <RRSAgent> I have made the request to generate https://www.w3.org/2024/01/17-pointerevents-minutes.html Patrick_H_Lauke
16:44:19 <Patrick_H_Lauke> rrsagent, bye
16:44:19 <RRSAgent> I see 1 open action item saved in https://www.w3.org/2024/01/17-pointerevents-actions.rdf :
16:44:19 <RRSAgent> ACTION: Mustaq to iterate over https://github.com/w3c/pointerevents/pull/494, others to give feedback before next meeting [1]
16:44:19 <RRSAgent>   recorded in https://www.w3.org/2024/01/17-pointerevents-irc#T16-26-04