- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Mon, 20 Nov 2023 08:53:12 +0000
- To: Pointer Events Working Group <public-pointer-events@w3.org>
Dear all, just realised that I forgot to send out the email for the minutes from the last PEWG meeting - they're available at https://www.w3.org/2023/11/08-pointerevents-minutes.html and copied below: PEWG 08 November 2023 Agenda: https://www.w3.org/events/meetings/6246bc85-4dae-43a8-a50c-9bc5a0829585/20231108T110000/ IRC log:https://www.w3.org/2023/11/08-pointerevents-irc Attendees flackr, mustaq, Patrick_H_Lauke, plh, smaug Chair: Patrick H. Lauke Scribe: Patrick H. Lauke, Patrick_H_Lauke * Handle pointer capture node removal asynchronously w3c/pointerevents#490 * Explain how a removed DOM node should be handled for boundary events w3c/pointerevents#491 * Clarify mousedown event target if the preceding pointerdown event listener removes the target w3c/pointerevents#492 Patrick: We've been rechartered PLH: you don't have to worry, don't have to rejoin, it's all taken care of # Handle pointer capture node removal asynchronously w3c/pointerevents#490 Rob: I put together the rough idea we threw around before - not sending synchronous events when DOM updated. now relying on async pointer capture that we send with the regular dispatch Rob: I think we're all good with this one? Mustaq: if there's further concerns, we can send more PRs Rob: we can always refine, but this is close to what we want. and don't have to worry about setting pointer state to document, as document doesn't have setPointerCapture, so can't do it Mustaq: that was another corner case that I originally thought <mustaq> The PR has been merged. Patrick: thank you all for that one # Explain how a removed DOM node should be handled for boundary events w3c/pointerevents#491 Rob: having trouble wording this. we know what it should do, but we don't want to redefine things that should be defined elsewhere. like path, TECHNICALLY depends on event type, but for our events it's always the same. would be a problem later if UI events at some point defined a different path for different event types? Rob: but high level, what do we want to do? Olli: maybe it wasn't very clear ... that we fire some mouse...over? Rob: I could try and clarify, rather than anonymous child ... "as if it was over a child" Olli: just because "anonymous child (or something)" was used originally in shadow DOM discussions Rob: used it because it's a similar idea ... it's over something that the dev has no access to Rob: ... the child is removed, so we can't say "over the deleted child" Rob: I can just make this wordier, maybe there's a boolean whether it's over the parent, or something like that. reflect it in the algorithm Patrick: my preference would be "wordier, if it makes it clearer to somebody who's not followed the discussion" Rob: I'll expand and use a boolean in the algo. could be like ... "needs over event" Rob: and if target is something *other* than we targeted, we can ignore it because it's not needed... Olli: [expands on the complexity of child, parent, grandparent, what MAY be behind the actual child that's removed...] Rob: all this is handled equivalent to what happens when a child is removed (under the mouse) Rob: and that's what this internal tracking state is meant to produce Rob: every edge case you can think of, think about what would happen if you removed the child (?) Rob: I'll remove anonymous child and replace with stateful value/boolen. also add explanation that the idea here is same as "what happens if you remove the child on the next pointermove" Rob: with caveat that we drop any events targeted at deleted child, because they're not meant to be dispatched ACTION: Rob to expand w3c/pointerevents#491 further/wordier, others to review for next meeting Patrick: just circling back to w3c/pointerevents#490 do we need a WPT? Rob: i think this only clarifies existing behaviour. unless we want to test the async vs sync Mustaq: ... i think we had a test about existing capture ... Rob: only additional test i can think of is that dispatch doesn't happen sync. so you remove node and test if event listener had been called <mustaq> pointerevent_lostpointercapture_for_disconnected_node.html Mustaq: there is a test (link above), not sure if it passes Mustaq: tests wether event is fired, but not the timing # Clarify mousedown event target if the preceding pointerdown event listener removes the target w3c/pointerevents#492 Olli: background here is the interop Olli: unclear what you do from interop point of view Mustaq: i'm changing interop test to only have pointer, and a separate one for mouse. problem in current interop test is that we mix the two Mustaq: added a tentative test. not part of this year's interop, maybe next Olli: i think chrome's behaviour here is reasonable, but I can also see the logic in the opposite approach Mustaq: one difference is that chrome doesn't send click... Rob: does Firefox send click? Rob: currently you can say at point of mouseup, we check common ancestor, and see there is no common ancestor because the node's been removed... Rob: we could treat it like boundary change... I can make tests where both behaviours are reasonable Rob: state of the DOM is state of the up dispatch Olli: but what is the state of the down... is it the common ancestor, etc Mustaq: common ancestor of UNDEFINED is also a possibility. UI spec doesn't say... Rob: equally if you keep ref to deleted node, the common ancestor doesn't exist Mustaq: i'm sure we've had the current behaviour because of a bug Rob: I can think of cases where it'll be weird for developers. Many cases where React keeps track of nodes... Mustaq: Rob could you add that in the issue, so we don't forget Olli: historically, when you had mousedown and mouseup, you'd always get a click...but now it's trickier. I *would* expect click Rob: same, unless we can find strong reason why not Patrick: so is this a blocker for v3? Rob: two things: click dispatch and should there ever be a difference between pointer event dispatch and mouse event dispatch... Olli: if we always follow pointer event dispatch, there won't be a mousedown because the node is gone, so there would not be a click Rob: I don't like that too much <mustaq> I am adding a tentative WPT for this issue here: https://chromium-review.googlesource.com/c/chromium/src/+/5008504 Olli: it'd be weird because you'd still get mouseup later, yes Rob: i'll add comment to the issue explaining what sub issues are Rob: relation between pointer event and mouse event and what happens when a node is removed. click dispatch is not so strong, because it's more a UI event... Mustaq: it's a pointer event now though Rob: but also happy to specify both things <Patrick_H_Lauke1> Mustaq: compatibility risk? <Patrick_H_Lauke1> (not sure what happened with my user here...must have clicked something, or due to my connection crapping out) ACTION: Rob to investigate further / write up rationale <Patrick_H_Lauke1> Patrick: just checking if there's any other blocking issues https://github.com/w3c/pointerevents/issues?q=is%3Aissue+is%3Aopen+label%3Av3-blocking <Patrick_H_Lauke1> Patrick: I'd say concentrate on the remaining blockers, WPTs after, so we can send for wide review with all normative changes in <Patrick_H_Lauke1> Patrick: thank you all, we'll reconvene in 2 weeks Actions: * Rob to expand w3c/pointerevents#491 further/wordier, others to review for next meeting * Rob to investigate further / write up rationale -- 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 Monday, 20 November 2023 08:53:21 UTC