IRC log of pointerevents on 2023-10-11

Timestamps are in UTC.

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