- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Wed, 11 Oct 2023 18:17:23 +0100
- To: Pointer Events Working Group <public-pointer-events@w3.org>
Dear all, the minutes from today's PEWG meeting are available at https://www.w3.org/2023/10/11-pointerevents-minutes.html and copied below: PEWG 11 October 2023 Agenda: https://www.w3.org/events/meetings/6246bc85-4dae-43a8-a50c-9bc5a0829585/20231011T110000/ IRC log: https://www.w3.org/2023/10/11-pointerevents-irc Attendees flackr, mustaq, Patrick_H_Lauke, smaug Chair: Patrick H. Lauke Scribe: Patrick H. Lauke, Patrick_H_Lauke * Review outstanding v3-blocker issues https://github.com/w3c/pointerevents/issues?q=is%3Aissue+is%3Aopen+label%3Av3-blocking * editor/co-editor * wide review Patrick: since TPAC been swamped with work, apologies. need to still get wide review requested w3c/pointerevents#482 # Review outstanding v3-blocker issues https://github.com/w3c/pointerevents/issues?q=is%3Aissue+is%3Aopen+label%3Av3-blocking Olli: just working out tests for secure context - need to rename tests for https, and not expose the http ones w3c/pointerevents#477 Mustaq: expecting chrome will fix things very soon Mustaq: hoping to have something in Chrome in a week Patrick: apologies, above link should have been w3c/pointerevents#445 Rob: when I reviewed specs, i didn't see anything relating to DOM removal Rob: UI Events spec for 477 Rob: they gloss over the fact that DOM can change Rob: remember reading in one of the specs somewhere that you're not supposed to fire events on removed elements Olli: UI Events does say something ... "if the element is removed ... mouse events should not be fired to that element" Olli: ... and Safari fires on THAT element Rob: we're proposing for boundary events treating the ancestor of that element to be the target Mustaq: Olli mentioned something about shadow DOM / boundary 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 Mustaq: still need WPT for 477? Rob: yes, to catch that case. slotted DOM element, when that's removed/changes slot... 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 Rob: intent is that this should follow the event bubbling/propagation path Olli: we treat it that mouse is now over that parent, but it's never over the root itself. maybe it works....unusual case 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 Olli: and yes for shadow DOM, there's the root in between. may need to handle this somehow 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 Rob: "parent" is too naive to say.... Olli: "nearest shadow-inclusive ancestor element" Mustaq: maybe should just dump this into the issue (#477) Rob: UI Events has concept of event propagation path defined Olli: DOM spec has it Rob: UI Events also mentions it Olli: ..."shadow including inclusive ancestor..." Olli: added comment to the issue Patrick: https://github.com/w3c/pointerevents/issues?q=is%3Aclosed+label%3Aneeds-wpt+ only one marked as v3. what happens with other ones? Mustaq: I was looking at #356 but can't promise when this will happen 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. Mustaq: we should assign people / self assign. just assigned something to Olli... Mustaq: out of 7 we have 2 assigned right now Patrick: and as ever, if you have somebody within your org that might have time/be suited, maybe ask them Patrick: I will also label these as v3 Patrick: so yes, would be good to get all WPTs in place before we get to final stage Rob: UI Events spec does not mention anything about shadow DOM Olli: yes, UI Events spec is more like DOM 3 and doesn't touch shadow Mustaq: I think there's a separate branch to make UI Events algorithmic, but a big task Rob: the one ask would be to change the vague "ancestor" with "shadow-inclusive ancestor..." Olli: also talks about bubbling when it should really say propagation Rob: i'd rather WE said "follows the event propagation path" and leave it up to other spec to then define it properly Olli: do we have something useful in DOM spec? "an event has an associated path", maybe the closest <smaug> https://dom.spec.whatwg.org/#event-path Patrick: so after we found relevant spec, we do still need to make change to OUR spec, right? Rob: yes, the thing we changed (about event propagation) Mustaq: trying to find something about pointer capture and what happens there when the capturing element is removed. goes back to the document? <mustaq> https://w3c.github.io/pointerevents/#pointer-capture 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 Rob: it is called out though in https://w3c.github.io/pointerevents/#implicit-release-of-pointer-capture "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." Rob: lostpointercapture is fired, but NOT the events. it just goes through the normal event path once capture lost Rob: we need more tests.... Olli: looks like we (in mozilla) fire to the document Rob: but that's only for lostpointercapture Rob: i'll file an issue about this not matching touch events, or whether we want to be different <mustaq> We have this WPT: wpt/pointerevents/pointerevent_lostpointercapture_for_disconnected_node.html Mustaq: we have test for lostpointercapture? <mustaq> https://www.irccloud.com/pastebin/pkPUrRPO/ Mustaq: we have 4 different tests for different types of nodes / shadow DOM / etc Olli: not testing what happens to pointer events after, though. just lostpointercpature Rob: i just wrote up #486 just to capture initial thoughts, can add more detail w3c/pointerevents#486 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 Olli: maybe that's fine, if it's been spec'd that way... Mustaq: corner case Rob: tested in Chrome, and doesn't fire events anymore to removed elements ACTION: for next meeting, investigate #486 further # editor/co-editor 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 Rob: would be good to have a co-editor, yes. I can do it Patrick: any objections? [group agrees] ACTION: make Rob co-editor for the spec Olli: (going back to 486) browsers all seem to be inconsistent, from quick testing now Olli: testing the implicit capture.... # wide review 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 ACTION: Patrick to action w3c/pointerevents#482 -- Patrick H. Lauke https://www.splintered.co.uk/ | https://github.com/patrickhlauke https://flickr.com/photos/redux/ | https://www.deviantart.com/redux https://mastodon.social/@patrick_h_lauke | skype: patrick_h_lauke
Received on Wednesday, 11 October 2023 17:17:42 UTC