14:49:30 <RRSAgent> RRSAgent has joined #pointerevents
14:49:34 <RRSAgent> logging to https://www.w3.org/2023/10/25-pointerevents-irc
14:49:40 <Patrick_H_Lauke> present+
14:52:43 <Patrick_H_Lauke> Meeting: PEWG
14:52:49 <Patrick_H_Lauke> Chair: Patrick H. Lauke
14:53:16 <Patrick_H_Lauke> Agenda: https://www.w3.org/events/meetings/6246bc85-4dae-43a8-a50c-9bc5a0829585/20231025T110000/
14:53:29 <Patrick_H_Lauke> Scribe: Patrick H. Lauke
14:53:35 <Patrick_H_Lauke> ScribeNick: Patrick_H_Lauke
14:58:54 <flackr> flackr has joined #pointerevents
15:01:12 <Patrick_H_Lauke> present+ flackr
15:01:21 <Patrick_H_Lauke> present+ smaug
15:02:45 <Patrick_H_Lauke> TOPIC: wide review
15:03:21 <mustaq> present+
15:03:41 <Patrick_H_Lauke> Patrick: https://github.com/w3c/pointerevents/issues/482
15:04:47 <Patrick_H_Lauke> Patrick: been slack after TPAC with vacation and another conference, but am now looking at this
15:05:03 <Patrick_H_Lauke> Patrick: extra wrinkle is our charter runs out, so coordinating with PLH about extending it again
15:05:12 <Patrick_H_Lauke> Patrick: want to get this done on my end ASAP
15:05:23 <Patrick_H_Lauke> TOPIC: Rob as co-editor
15:05:37 <Patrick_H_Lauke> Patrick: you may have seen, but now Rob officially co-editor as well
15:06:15 <Patrick_H_Lauke> https://github.com/w3c/pointerevents/pull/488
15:07:08 <Patrick_H_Lauke> TOPIC: wide review and charter
15:07:08 <Patrick_H_Lauke> present+ plh
15:07:44 <Patrick_H_Lauke> plh: timeline in charter is outdated, so don't know what to put
15:08:49 <Patrick_H_Lauke> Patrick: if I kick off wide review now, how long will it take realistically?
15:08:52 <Patrick_H_Lauke> plh: usually 2 months, maybe even 1
15:09:22 <Patrick_H_Lauke> Patrick: safer to say 2 months
15:09:39 <Patrick_H_Lauke> plh: when do you expect wide review to be sent out?
15:09:50 <Patrick_H_Lauke> Patrick: want to get it done tonight, tomorrow, this week at least
15:10:42 <Patrick_H_Lauke> plh: so that puts us into January. i'll update timeline and charter
15:12:12 <Patrick_H_Lauke> TOPIC: Review outstanding v3-blocker issues https://github.com/w3c/pointerevents/issues?q=is%3Aissue+is%3Aopen+label%3Av3-blocking
15:12:50 <Patrick_H_Lauke> Patrick: where are we up to with #477 https://github.com/w3c/pointerevents/issues/477 ?
15:13:34 <Patrick_H_Lauke> mustaq: we have comment that we need one implementer. chrome will hopefully have this. also we need a WPT for shadow DOM
15:13:42 <Patrick_H_Lauke> Olli: yes we need to define how that is supposed to work
15:13:53 <Patrick_H_Lauke> mustaq: anyone working on that WPT?
15:13:59 <Patrick_H_Lauke> Olli: i'm not on that one, no
15:14:16 <mustaq> I am not either!
15:14:32 <Patrick_H_Lauke> Olli: hoping that while writing the test, it will become clear what the right approach should be
15:14:47 <Patrick_H_Lauke> Olli: it should be event path though, as mentioned
15:15:10 <Patrick_H_Lauke> Rob: yes, it's mentioned in various places, like UI Events, but they don't mention shadow DOM
15:15:27 <Patrick_H_Lauke> Olli: was thinking DOM spec, if there's a nice algorithm...
15:15:49 <Patrick_H_Lauke> Rob: we need to define event path somewhere, and then refer to it. then we can just refer to parent in event path
15:16:30 <Patrick_H_Lauke> Rob: the modification ... you need to do this not while processing the event, happens outside of the event processing. you could refer to the historical event, but realistically want to follow same logic as an event that would have targeted that element
15:16:55 <Patrick_H_Lauke> mustaq: the event path is constructed during the dispatch, so will be tricky...
15:17:20 <Patrick_H_Lauke> Rob: we should use same rules as the constructed event path for the thing that you're now considered to be over
15:17:36 <Patrick_H_Lauke> Rob: i see you (Olli) have added a link to the DOM spec event path
15:18:08 <Patrick_H_Lauke> Olli: yeah but sorry if we can't really use any of the algo. because it's to dispatch an event to a target. then there's the composed (?) path
15:19:05 <Patrick_H_Lauke> Patrick: so we still iterating...
15:19:17 <Patrick_H_Lauke> Rob: looks like the event dispatching constructs the path, so maybe can extract that
15:19:19 <smaug> https://dom.spec.whatwg.org/#dispatching-events
15:19:22 <flackr> https://dom.spec.whatwg.org/#dispatching-events
15:20:41 <Patrick_H_Lauke> Patrick: are we defining stuff that we shouldn't?
15:20:51 <Patrick_H_Lauke> Rob: I want to take 5.9 and just extract/reuse that
15:21:06 <Patrick_H_Lauke> Rob: you keep stepping up until you get to the root, and that's what defines the path
15:21:29 <Patrick_H_Lauke> mustaq: so we basically say ... "conform to 5.9" so we don't need to change the DOM spec
15:21:59 <Patrick_H_Lauke> Rob: that would be the correct test, but we probably need to say something more direct in our spec. when target is removed, we follow this algo until we find a still attached node
15:22:51 <Patrick_H_Lauke> Patrick: just wondering, as this is the last substantive change, should we hold off with wide review until we have this?
15:23:01 <Patrick_H_Lauke> Olli: yeah, might be true
15:24:05 <mustaq> https://github.com/w3c/pointerevents/issues/487
15:24:35 <Patrick_H_Lauke> Patrick: we can probably go for review before there's implementation and WPT, but we probably should make the change to spec first before asking for review
15:24:48 <Patrick_H_Lauke> mustaq: filed the above bug which is related...
15:24:55 <Patrick_H_Lauke> Rob: I thought our spec did say what to do
15:24:58 <Patrick_H_Lauke> Olli: yeah so did i
15:25:16 <Patrick_H_Lauke> mustaq: feel free to comment in issue, maybe i missed something
15:26:03 <Patrick_H_Lauke> Rob: section 9.5 implicit release of pointer capture says that when target override is no longer connected, we clear ...
15:26:21 <Patrick_H_Lauke> Olli: need to look whether it's talking about connected, disconnected, or removed
15:26:43 <Patrick_H_Lauke> mustaq: ... we're expected to fire lostpointercapture...
15:26:45 <Patrick_H_Lauke> Rob: I believe so
15:26:52 <Patrick_H_Lauke> Olli: this is the behaviour that browsers had
15:26:57 <Patrick_H_Lauke> Rob: I thought so yes
15:27:45 <Patrick_H_Lauke> mustaq: the timing is not clear. the get or lostpointercapture is fired in a lazy mannger
15:27:51 <Patrick_H_Lauke> s/manger/manner
15:27:58 <Patrick_H_Lauke> s/mannger/manner
15:28:12 <Patrick_H_Lauke> mustaq: should we fire immediately after DOM change or should it wait?
15:28:28 <Patrick_H_Lauke> Rob: it also talks about the pending pointer capture in 9.5. my reading is that it should be immediate
15:28:55 <Patrick_H_Lauke> mustaq: i think second para mostly addresses that, but timing could do with clarification
15:29:18 <Patrick_H_Lauke> Rob: we don't want to fire immediately as that makes it sync, but we should treat it as lost pointer capture as normal and queue it
15:29:28 <Patrick_H_Lauke> Olli: do we queue a task or run as soon as possible
15:30:15 <Patrick_H_Lauke> mustaq: lazy mechanism might not see it as a change that needs dispatching
15:30:26 <Patrick_H_Lauke> Rob: when does the pending stuff get sent
15:30:52 <Patrick_H_Lauke> Rob: ... do we expect a notification when we don't get pointercapture?
15:31:14 <Patrick_H_Lauke> mustaq: lazy mechanism mentions something...
15:32:26 <mustaq> https://w3c.github.io/pointerevents/#process-pending-pointer-capture
15:32:37 <Patrick_H_Lauke> mustaq: i think this section (link) mentions the lazy mechanism
15:33:16 <Patrick_H_Lauke> Rob: right now, i f you set pointercapture, if you remove node before the next event, there will be no notification that you didn't succeed in getting pointercapture
15:33:19 <Patrick_H_Lauke> mustaq: which is fine right?
15:33:30 <Patrick_H_Lauke> Rob: not great from a developer perspective
15:33:50 <Patrick_H_Lauke> mustaq: it's not a got or lost, it's a cancel pending request
15:34:09 <Patrick_H_Lauke> Rob: you could send lostpointercapture, but then it wouldn't match up to a gotpointercapture
15:34:21 <Patrick_H_Lauke> Rob: maybe it's something we add in future...
15:34:35 <Patrick_H_Lauke> mustaq: back to timing, do we agree...
15:35:01 <Patrick_H_Lauke> Rob: it says "otherwise clear the pointercapture target override". is that when we fire lostpointecapture.... oh no it's step 1
15:35:25 <Patrick_H_Lauke> Rob: if the node was removed, it would be in step 1 that we detect that the capture target is null
15:35:46 <Patrick_H_Lauke> Rob: that's the point where we would fire lostpointercapture
15:35:56 <Patrick_H_Lauke> mustaq: so there we should immediately set pending to null
15:36:07 <Patrick_H_Lauke> mustaq: please comment in issue, then we can resolve this easily
15:36:27 <Patrick_H_Lauke> ACTION: review #487 and hopefully close if already covered
15:37:23 <Patrick_H_Lauke> Patrick: getting back to #477 who would like to take a stab at this
15:39:01 <Patrick_H_Lauke> PAtrick: would be keen to get the small change in our spec
15:39:05 <Patrick_H_Lauke> Rob: not sure how easy it is to get change into DOM spec...
15:39:11 <Patrick_H_Lauke> Patrick: but just the part for our spec...
15:39:31 <Patrick_H_Lauke> Rob: I can try and just reference...
15:39:52 <Patrick_H_Lauke> ACTION: Rob to review/make necessary change to PE spec relating to #477
15:40:57 <Patrick_H_Lauke> TOPIC: interop 2024 effort
15:41:15 <Patrick_H_Lauke> mustaq: want to highlight proposal for pointervent/mouseevent
15:41:39 <mustaq> Interop 2024 carryover proposal for Pointer Events and Mouse Events:
15:41:40 <mustaq> https://github.com/web-platform-tests/interop/issues/472
15:42:14 <mustaq> It would be great to see other browsers adding to the list.
15:42:33 <Patrick_H_Lauke> Patrick: so is this for Olli to be aware of and have a look at? Yeah, cool
15:42:54 <Patrick_H_Lauke> ACTION: Olli to review interop 2024 carryover proposal for PE and Mouse Events
15:43:09 <Patrick_H_Lauke> TOPIC: sideline pointervent id
15:43:19 <Patrick_H_Lauke> Patrick: https://groups.google.com/a/chromium.org/g/blink-dev/c/3eU-AHH8x4k/m/rCyxcYnQAgAJ intent to ship in chrome
15:44:15 <Patrick_H_Lauke> Patrick: assume this is stuff for future versions of PE?
15:44:29 <Patrick_H_Lauke> Rob: yeah that seems reasonable
15:45:04 <Patrick_H_Lauke> Patrick: not trying to put any of you on the spot, just wondered if you had more inside knowledge
15:45:44 <Patrick_H_Lauke> Patrick: assume this is what came out of the presentation we had a while ago from... Microsoft? Wacom? ... about their idea to store id more permanently to then open up possibility of storing preferences
15:46:48 <Patrick_H_Lauke> Rob: looks like that on that intent thread two of the owners pointed out it should have a spec
15:47:04 <Patrick_H_Lauke> Patrick: cool, just no action right now, just something to be aware of that it might come in for future versions
15:47:30 <Patrick_H_Lauke> Rob: FWIW i reviewed early work on this, and made sure things were designed in similar way to what we already have. but yes we'll evaluate it properly when it comes to us
15:48:29 <Patrick_H_Lauke> RRSAgent, make minutes world-visible
15:48:29 <RRSAgent> I'm logging. I don't understand 'make minutes world-visible', Patrick_H_Lauke.  Try /msg RRSAgent help
15:48:38 <Patrick_H_Lauke> RRSAgent, set logs world-visible
15:48:45 <Patrick_H_Lauke> RRSAgent, generate minutes
15:48:46 <RRSAgent> I have made the request to generate https://www.w3.org/2023/10/25-pointerevents-minutes.html Patrick_H_Lauke
15:49:04 <Patrick_H_Lauke> RRSAgent, bye
15:49:04 <RRSAgent> I see 3 open action items saved in https://www.w3.org/2023/10/25-pointerevents-actions.rdf :
15:49:04 <RRSAgent> ACTION: review #487 and hopefully close if already covered [1]
15:49:04 <RRSAgent>   recorded in https://www.w3.org/2023/10/25-pointerevents-irc#T15-36-27
15:49:04 <RRSAgent> ACTION: Rob to review/make necessary change to PE spec relating to #477 [2]
15:49:04 <RRSAgent>   recorded in https://www.w3.org/2023/10/25-pointerevents-irc#T15-39-52
15:49:04 <RRSAgent> ACTION: Olli to review interop 2024 carryover proposal for PE and Mouse Events [3]
15:49:04 <RRSAgent>   recorded in https://www.w3.org/2023/10/25-pointerevents-irc#T15-42-54