IRC log of pointerevents on 2023-10-25

Timestamps are in UTC.

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