15:01:11 <RRSAgent> RRSAgent has joined #pointerevents
15:01:15 <RRSAgent> logging to https://www.w3.org/2023/06/21-pointerevents-irc
15:01:36 <Patrick_H_Lauke> Meeting: PEWG
15:01:40 <Patrick_H_Lauke> Chair: Patrick H. Lauke
15:01:47 <Patrick_H_Lauke> Agenda: https://www.w3.org/events/meetings/6246bc85-4dae-43a8-a50c-9bc5a0829585/20230621T110000/
15:02:06 <Patrick_H_Lauke> Scribe: Patrick H. Lauke
15:02:12 <Patrick_H_Lauke> ScribeNick Patrick_H_Lauke
15:02:15 <Patrick_H_Lauke> present+
15:02:22 <Patrick_H_Lauke> present+ flackr
15:02:26 <Patrick_H_Lauke> present+ smaug
15:02:50 <Patrick_H_Lauke> present+ mustaq
15:03:30 <Patrick_H_Lauke> TOPIC: Meta-issue: update WPT to cover Pointer Events Level 3 https://github.com/w3c/pointerevents/issues/445
15:04:03 <Patrick_H_Lauke> Patrick: where are we up to? seeing some activity...
15:04:34 <mustaq> Reopened https://github.com/w3c/pointerevents/issues/463 when adding a test
15:04:48 <Patrick_H_Lauke> Patrick: https://github.com/w3c/pointerevents/issues?q=is%3Aclosed+label%3Aneeds-wpt+
15:04:48 <mustaq> Sent a PR to fix.
15:06:55 <Patrick_H_Lauke> Patrick: 6 still open. do you think we can get these done, do you need extra help?
15:07:05 <Patrick_H_Lauke> Mustaq: should be ok, going a bit slow
15:07:17 <Patrick_H_Lauke> Olli: there will be holidays soon - will be away in July likely
15:07:39 <Patrick_H_Lauke> Mustaq: should be able to split between us
15:07:56 <Patrick_H_Lauke> ACTION: continue working on these
15:08:22 <Patrick_H_Lauke> TOPIC: Heartbeat: Clarify what the target of the click event should be after capturing pointer events https://github.com/w3c/pointerevents/issues/356
15:09:19 <Patrick_H_Lauke> Patrick: made a changed codepen, but didn't collate all results. should i still do it?
15:10:10 <Patrick_H_Lauke> Rob: I did testing myself, and mousedown target is always consistent with the pointerup target, even when the capture was established during pointer event which happened "first"
15:10:18 <Patrick_H_Lauke> Olli: and even if you release in pointerup?
15:10:21 <Patrick_H_Lauke> Rob: yes
15:10:47 <Patrick_H_Lauke> Rob: Mustaq and I had offline discussion last week...what user may be doing, what dev expectation may be
15:11:04 <Patrick_H_Lauke> Rob: we talked about boundary events previously, and they're not consistent with click event already at this point
15:12:05 <Patrick_H_Lauke> Mustaq: makes sense to maintain special status of click event...
15:12:42 <Patrick_H_Lauke> Patrick: sorry, my connection is really bad, missing every other word at the moment...
15:13:22 <Patrick_H_Lauke> Patrick: did we get to an agreement then?
15:13:30 <Patrick_H_Lauke> [Rob and Olli confirm]
15:13:48 <Patrick_H_Lauke> Mustaq: compat side...
15:14:11 <Patrick_H_Lauke> Mustaq: [is low risk?] because it's different in all browsers already anyway (?)
15:14:19 <Patrick_H_Lauke> Mustaq: in case something still breaks, we can reconsider
15:14:30 <Patrick_H_Lauke> Olli: we can say that this is resolved, we need a PR
15:14:38 <Patrick_H_Lauke> Mustaq: I can take care of that
15:14:44 <Patrick_H_Lauke> Olli: that's fine, I can review
15:15:04 <Patrick_H_Lauke> Olli: and then there's the issue with lostpointercapture https://github.com/w3c/pointerevents/issues/357
15:15:28 <Patrick_H_Lauke> Mustaq: second comment...
15:16:10 <Patrick_H_Lauke> Rob: it's already agreed that the click's target is based on down and up, so don't need to ... (?)
15:16:49 <Patrick_H_Lauke> Olli: so lostpointercapture can happen first
15:16:58 <Patrick_H_Lauke> Mustaq: because click is a special high-level event
15:17:10 <Patrick_H_Lauke> Olli: i'm fine with that
15:17:48 <Patrick_H_Lauke> Olli: if you explicitly or implicitly release, it's the same
15:17:54 <Patrick_H_Lauke> Rob: yes because the top event is captured
15:18:31 <Patrick_H_Lauke> Olli: if pointercaputre released before pointerup, then click is not handled in any special way
15:18:43 <Patrick_H_Lauke> Rob: conceptually calculates target at some point where we get pointerup
15:19:04 <Patrick_H_Lauke> Olli: adding comment to #357 - fire lostpointercapture before click
15:20:28 <Patrick_H_Lauke> Patrick: does this need change/more explicit wording in spec?
15:20:41 <Patrick_H_Lauke> Mustaq: i think so, will try to tackle with the PR for both issues
15:20:58 <Patrick_H_Lauke> Olli: because currently spec seems to say both behaviours are fine which is contradictory
15:22:00 <Patrick_H_Lauke> Mustaq: question - does this thinking apply to auxclick and contextmenu etc as well?
15:22:08 <Patrick_H_Lauke> Rob: shouldn't be differrent...
15:22:26 <Patrick_H_Lauke> Mustaq: UI event spec doesn't mention common ancestor at all for those events
15:22:54 <Patrick_H_Lauke> Rob: we're using the targeting based on the events that led to the click...
15:23:03 <Patrick_H_Lauke> Rob: same idea could be applied to auxclick etc
15:23:27 <Patrick_H_Lauke> Rob: e.g. if auxclick is result of a single event, then its targeting depends on targeting of that single event (?)
15:23:36 <Patrick_H_Lauke> Rob: this is platform dependent
15:24:12 <Patrick_H_Lauke> Rob: contextmenu shows up on the down, and sometimes on the up. will vary by platform, but consistent with our handling of click. when based on down event, use targeting from down event, etc
15:24:26 <Patrick_H_Lauke> Rob: if not using common ancestor, just go by what the up event is
15:24:35 <Patrick_H_Lauke> Olli: but auxclick is different
15:24:47 <Patrick_H_Lauke> Mustaq: don't even know if auxclick has common ancestor concept
15:25:11 <Patrick_H_Lauke> Olli: might be a gap/shortcoming of UI event spec, not necessarily intentional that it's not mentioned
15:25:21 <Patrick_H_Lauke> Olli: ...there is also double-click
15:26:15 <Patrick_H_Lauke> Mustaq: inclusive ancestor wording in UI spec is very handwavy. so think we need to add auxclick there as well
15:26:20 <mustaq> https://w3c.github.io/uievents/#events-mouseevent-event-order
15:26:50 <mustaq> auxclick should be there too, right?
15:27:34 <mustaq> By "there" I mean the text around "nearest common inclusive ancestor"
15:27:43 <Patrick_H_Lauke> Rob: looks to me auxclick should use same inclusive ancestor targeting
15:27:59 <Patrick_H_Lauke> Rob: auxclick definition says it's always a press and a release
15:28:15 <flackr> https://w3c.github.io/uievents/#event-type-auxclick
15:29:17 <Patrick_H_Lauke> Rob: should use same targeting behaviour as click
15:29:23 <Patrick_H_Lauke> Olli: Firefox does it
15:29:49 <Patrick_H_Lauke> ACTION: mustaq to draft PR to cover #356 and #357, Olli to review
15:30:23 <Patrick_H_Lauke> TOPIC: TPAC
15:30:36 <Patrick_H_Lauke> Patrick: confirming i'll be physically at TPAC
15:36:33 <Patrick_H_Lauke> [Olli and Mustaq confirm they will also be physically there, Rob will join virtually]
15:37:02 <Patrick_H_Lauke> Patrick: additionally, worked with Philippe for the charter extension, and said that we're roughly aiming at getting last blocking issues addressed before TPAC
15:37:58 <Patrick_H_Lauke> Patrick: then to move forward with spec, we'll need to do the implementation report etc. Even if not fully implemented (though ideal), we need at least commitment/signals from different browser engines that they plan to implement the new parts, so shouldn't be a problem
15:38:22 <Patrick_H_Lauke> Patrick: thank you all. As said, will send reminders well before next meeting.
15:38:28 <Patrick_H_Lauke> RRSAgent, make logs world-visible
15:38:34 <Patrick_H_Lauke> RRSAgent, generate minutes
15:38:35 <RRSAgent> I have made the request to generate https://www.w3.org/2023/06/21-pointerevents-minutes.html Patrick_H_Lauke
15:39:02 <Patrick_H_Lauke> RRSAgent, bye
15:39:02 <RRSAgent> I see 2 open action items saved in https://www.w3.org/2023/06/21-pointerevents-actions.rdf :
15:39:02 <RRSAgent> ACTION: continue working on these [1]
15:39:02 <RRSAgent>   recorded in https://www.w3.org/2023/06/21-pointerevents-irc#T15-07-56
15:39:02 <RRSAgent> ACTION: mustaq to draft PR to cover #356 and #357, Olli to review [2]
15:39:02 <RRSAgent>   recorded in https://www.w3.org/2023/06/21-pointerevents-irc#T15-29-49