14:34:53 <RRSAgent> RRSAgent has joined #pointerevents
14:34:58 <RRSAgent> logging to https://www.w3.org/2023/10/11-pointerevents-irc
14:36:34 <Patrick_H_Lauke> Meeting: PEWG
14:36:46 <Patrick_H_Lauke> Chair: Patrick H. Lauke
14:41:11 <Patrick_H_Lauke> Agenda: https://www.w3.org/events/meetings/6246bc85-4dae-43a8-a50c-9bc5a0829585/20231011T110000/
14:41:18 <Patrick_H_Lauke> Scribe: Patrick H. Lauke
14:41:25 <Patrick_H_Lauke> ScribeNick: Patrick_H_Lauke
15:00:34 <flackr> flackr has joined #pointerevents
15:01:34 <Patrick_H_Lauke> present+
15:01:41 <Patrick_H_Lauke> present+ smaug
15:01:47 <Patrick_H_Lauke> present+ mustaq
15:04:10 <Patrick_H_Lauke> present+ flackr
15:05:38 <Patrick_H_Lauke> Patrick: since TPAC been swamped with work, apologies. need to still get wide review requested https://github.com/w3c/pointerevents/issues/482
15:08:30 <Patrick_H_Lauke> TOPIC: Review outstanding v3-blocker issues https://github.com/w3c/pointerevents/issues?q=is%3Aissue+is%3Aopen+label%3Av3-blocking
15:09:22 <Patrick_H_Lauke> Olli: just working out tests for secure context - need to rename tests for https, and not expose the http ones https://github.com/w3c/pointerevents/issues/477
15:09:33 <Patrick_H_Lauke> Mustaq: expecting chrome will fix things very soon
15:09:53 <Patrick_H_Lauke> Mustaq: hoping to have something in Chrome in a week
15:10:29 <Patrick_H_Lauke> Patrick: apologies, above link should have been https://github.com/w3c/pointerevents/issues/445
15:11:37 <Patrick_H_Lauke> Rob: when I reviewed specs, i didn't see anything relating to DOM removal
15:11:52 <Patrick_H_Lauke> Rob: UI Events spec for 477
15:12:04 <Patrick_H_Lauke> Rob: they gloss over the fact that DOM can change
15:12:48 <Patrick_H_Lauke> Rob: remember reading in one of the specs somewhere that you're not supposed to fire events on removed elements
15:13:38 <Patrick_H_Lauke> Olli: UI Events does say something ... "if the element is removed ... mouse events should not be fired to that element"
15:13:50 <Patrick_H_Lauke> Olli: ... and Safari fires on THAT element
15:14:07 <Patrick_H_Lauke> Rob: we're proposing for boundary events treating the ancestor of that element to be the target
15:14:22 <Patrick_H_Lauke> Mustaq: Olli mentioned something about shadow DOM / boundary
15:14:48 <Patrick_H_Lauke> Olli: for this issue it's not the parent, it's the same path used for event dispatching (for #477). need to use same mechanism as DOM spec
15:15:00 <Patrick_H_Lauke> Mustaq: still need WPT for 477?
15:15:12 <Patrick_H_Lauke> Rob: yes, to catch that case. slotted DOM element, when that's removed/changes slot...
15:15:36 <Patrick_H_Lauke> Olli: then there's case if you're in topmost element in shadow DOM, your parent is shadow root, I think we should then skip shadow root and go to the host
15:15:48 <Patrick_H_Lauke> Rob: intent is that this should follow the event bubbling/propagation path
15:16:08 <Patrick_H_Lauke> Olli: we treat it that mouse is now over that parent, but it's never over the root itself. maybe it works....unusual case
15:16:33 <Patrick_H_Lauke> Rob: there's edge cases to test, but answer may be simple. whatever element you entered to enter this sub element, that thing is the thing that should be considered over
15:16:51 <Patrick_H_Lauke> Olli: and yes for shadow DOM, there's the root in between. may need to handle this somehow
15:17:33 <Patrick_H_Lauke> Olli: let's say you have shadow root, and you add just one element. now move mouse over to that element, and while dispatching, you remove that element. but the parent is shadow root, but it's not an element
15:17:46 <Patrick_H_Lauke> Rob: "parent" is too naive to say....
15:17:58 <Patrick_H_Lauke> Olli: "nearest shadow-inclusive ancestor element"
15:18:12 <Patrick_H_Lauke> Mustaq: maybe should just dump this into the issue (#477)
15:18:43 <Patrick_H_Lauke> Rob: UI Events has concept of event propagation path defined
15:18:48 <Patrick_H_Lauke> Olli: DOM spec has it
15:18:56 <Patrick_H_Lauke> Rob: UI Events also mentions it
15:20:45 <Patrick_H_Lauke> Olli: ..."shadow including inclusive ancestor..."
15:21:11 <Patrick_H_Lauke> Olli: added comment to the issue
15:21:41 <Patrick_H_Lauke> Patrick: https://github.com/w3c/pointerevents/issues?q=is%3Aclosed+label%3Aneeds-wpt+ only one marked as v3. what happens with other ones?
15:22:19 <Patrick_H_Lauke> Mustaq: I was looking at #356 but can't promise when this will happen
15:24:55 <Patrick_H_Lauke> Patrick: I would suggest if you at some point commented on any of these and said you'd do it, but then didn't get around to it, maybe comment.
15:25:14 <Patrick_H_Lauke> Mustaq: we should assign people / self assign. just assigned something to Olli...
15:25:22 <Patrick_H_Lauke> Mustaq: out of 7 we have 2 assigned right now
15:25:58 <Patrick_H_Lauke> Patrick: and as ever, if you have somebody within your org that might have time/be suited, maybe ask them
15:26:20 <Patrick_H_Lauke> Patrick: I will also label these as v3
15:27:06 <Patrick_H_Lauke> Patrick: so yes, would be good to get all WPTs in place before we get to final stage
15:27:52 <Patrick_H_Lauke> Rob: UI Events spec does not mention anything about shadow DOM
15:28:13 <Patrick_H_Lauke> Olli: yes, UI Events spec is more like DOM 3 and doesn't touch shadow
15:28:42 <Patrick_H_Lauke> Mustaq: I think there's a separate branch to make UI Events algorithmic, but a big task
15:29:00 <Patrick_H_Lauke> Rob: the one ask would be to change the vague "ancestor" with "shadow-inclusive ancestor..."
15:29:13 <Patrick_H_Lauke> Olli: also talks about bubbling when it should really say propagation
15:30:11 <Patrick_H_Lauke> Rob: i'd rather WE said "follows the event propagation path" and leave it up to other spec to then define it properly
15:30:30 <Patrick_H_Lauke> Olli: do we have something useful in DOM spec? "an event has an associated path", maybe the closest
15:30:33 <smaug> https://dom.spec.whatwg.org/#event-path
15:32:13 <Patrick_H_Lauke> Patrick: so after we found relevant spec, we do still need to make change to OUR spec, right?
15:32:31 <Patrick_H_Lauke> Rob: yes, the thing we changed (about event propagation)
15:33:28 <Patrick_H_Lauke> Mustaq: trying to find something about pointer capture and what happens there when the capturing element is removed. goes back to the document?
15:33:35 <mustaq> https://w3c.github.io/pointerevents/#pointer-capture
15:34:36 <Patrick_H_Lauke> Rob: we have implicit pointer capture to be similar to touch events, but TE does send events back to removed element. tested this recently. if we changed our pointer capture to be lost on element removal, that would be in contrast with behaviour that implicit pointer capture was meant to take care of
15:35:56 <Patrick_H_Lauke> Rob: it is called out though in https://w3c.github.io/pointerevents/#implicit-release-of-pointer-capture
15:36:05 <Patrick_H_Lauke> "When the pointer capture target override is no longer connected [DOM], the pending pointer capture target override and pointer capture target override nodes SHOULD be cleared and also a PointerEvent named lostpointercapture corresponding to the captured pointer SHOULD be fired at the document."
15:36:34 <Patrick_H_Lauke> Rob: lostpointercapture is fired, but NOT the events. it just goes through the normal event path once capture lost
15:37:35 <Patrick_H_Lauke> Rob: we need more tests....
15:38:07 <Patrick_H_Lauke> Olli: looks like we (in mozilla) fire to the document
15:38:14 <Patrick_H_Lauke> Rob: but that's only for lostpointercapture
15:38:45 <Patrick_H_Lauke> Rob: i'll file an issue  about this not matching touch events, or whether we want to be different
15:39:05 <mustaq> We have this WPT: wpt/pointerevents/pointerevent_lostpointercapture_for_disconnected_node.html
15:39:12 <Patrick_H_Lauke> Mustaq: we have test for lostpointercapture?
15:40:01 <mustaq> https://www.irccloud.com/pastebin/pkPUrRPO/
15:40:49 <Patrick_H_Lauke> Mustaq: we have 4 different tests for different types of nodes / shadow DOM / etc
15:41:01 <Patrick_H_Lauke> Olli: not testing what happens to pointer events after, though. just lostpointercpature
15:41:48 <Patrick_H_Lauke> Rob: i just wrote up #486 just to capture initial thoughts, can add more detail
15:41:59 <Patrick_H_Lauke> https://github.com/w3c/pointerevents/issues/486
15:43:47 <Patrick_H_Lauke> Rob: ... i think that demo linked from 486 shows explicitly that PE doesn't match TE for events being sent or not to removed node
15:44:03 <Patrick_H_Lauke> Olli: maybe that's fine, if it's been spec'd that way...
15:44:09 <Patrick_H_Lauke> Mustaq: corner case
15:44:22 <Patrick_H_Lauke> Rob: tested in Chrome, and doesn't fire events anymore to removed elements
15:44:54 <Patrick_H_Lauke> ACTION: for next meeting, investigate #486 further
15:46:46 <Patrick_H_Lauke> TOPIC: editor/co-editor
15:47:14 <Patrick_H_Lauke> Patrick: as discussed at TPAC, I moved Navid to former editors. However, happy for somebody else to be co-editor, as some of the more technical aspects we're wading into are beyond me
15:47:24 <Patrick_H_Lauke> Rob: would be good to have a co-editor, yes. I can do it
15:47:31 <Patrick_H_Lauke> Patrick: any objections?
15:47:34 <Patrick_H_Lauke> [group agrees]
15:47:43 <Patrick_H_Lauke> ACTION: make Rob co-editor for the spec
15:48:07 <Patrick_H_Lauke> Olli: (going back to 486) browsers all seem to be inconsistent, from quick testing now
15:48:19 <Patrick_H_Lauke> Olli: testing the implicit capture....
15:48:44 <Patrick_H_Lauke> TOPIC: wide review
15:49:24 <Patrick_H_Lauke> Patrick: as said, i've been slack with getting the wide review requests out, but will definitely have this done for next meeting. and liaise with PLH on potential need for further charter extension
15:49:50 <Patrick_H_Lauke> ACTION: Patrick to action https://github.com/w3c/pointerevents/issues/482
15:50:31 <Patrick_H_Lauke> RRSAgent, set logs world-visible
15:50:39 <Patrick_H_Lauke> RRSAgent, generate minutes
15:50:40 <RRSAgent> I have made the request to generate https://www.w3.org/2023/10/11-pointerevents-minutes.html Patrick_H_Lauke
17:05:11 <Patrick_H_Lauke> rrsagent, bye
17:05:11 <RRSAgent> I see 3 open action items saved in https://www.w3.org/2023/10/11-pointerevents-actions.rdf :
17:05:11 <RRSAgent> ACTION: for next meeting, investigate #486 further [1]
17:05:11 <RRSAgent>   recorded in https://www.w3.org/2023/10/11-pointerevents-irc#T15-44-54
17:05:11 <RRSAgent> ACTION: make Rob co-editor for the spec [2]
17:05:11 <RRSAgent>   recorded in https://www.w3.org/2023/10/11-pointerevents-irc#T15-47-43
17:05:11 <RRSAgent> ACTION: Patrick to action https://github.com/w3c/pointerevents/issues/482 [3]
17:05:11 <RRSAgent>   recorded in https://www.w3.org/2023/10/11-pointerevents-irc#T15-49-50