- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Wed, 22 Nov 2023 18:36:39 +0000
- 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/11/22-pointerevents-minutes.html and copied below: PEWG 22 November 2023 Agenda: https://www.w3.org/events/meetings/6246bc85-4dae-43a8-a50c-9bc5a0829585/20231122T110000/ IRC log: https://www.w3.org/2023/11/22-pointerevents-irc Attendees flackr, mustaq, Patrick_H_Lauke, smaug Chair: Patrick H. Lauke Scribe: Patrick H. Lauke, Patrick_H_Lauke * 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 # Explain how a removed DOM node should be handled for boundary events w3c/pointerevents#491 [group agrees this is good to merge for now] Rob: i think mustaq has already landed tests for the simple cases Rob: have some concerns about this assuming the same event chain / path for all event types Rob: "get the parent" algorithm in DOM spec, which can vary by event type Rob: we might want to say we use that algo for an event with type pointermove, and standardise on that Rob: it's weird that by spec you can have different chain depending on event type Mustaq: missing tests relate to slot ... <mustaq> w3c/pointerevents#477 Mustaq: ...and shadow dom boundaries # Clarify mousedown event target if the preceding pointerdown event listener removes the target w3c/pointerevents#492 Rob: tricky part here is when you have a pointer event and compat mouse event dispatched. when PE removes target, does it affect the mouse compat target Olli: and what happens if you modify DOM even more Rob: i'm in favour to having it behave similar to tracking what pointer is over - goes to the parent. think there's a lot of pages which ... things like React replace large chunks of inner elements, but want to still fire to ancestor... Patrick: event delegation... Olli: tricky part is click, because that's not dispatched by any implementation Rob: could be accident because we remove the down event, and as result doesn't fire click Olli: unfortunate because a dev might expect a click Rob: sounds like we may need to do some measurement for this Mustaq: i already added WPTs for this Mustaq: do we have click there? I forgot... Rob: think test wasn't adding a click listener, so we weren't testing for that <mustaq> https://wpt.fyi/results/pointerevents?label=master&label=experimental&aligned&q=interleaved.tentative.html Rob: we probably need to add some metrics to see how often we're going to be dispatching click for something removed in the pointerdown Mustaq: neither firefox nor chrome fire? Rob: firefox, chrome, safari - none of them do Rob: we could say that if the down element is removed, the click isn't dispatched - if it's too late for us to change this Rob: but could be better outcome if we COULD dispatch click Mustaq: we can't measure compat impact without trying... Rob: not necessarily, can measure how often we currently DON'T fire a click because the down element was removed. can further determine what the target of the click would be, and check if ancestor has a click handler Mustaq: ... we can get some estimate Rob: we can at least get an estimate, but can't tell if it would break things Olli: what happens if you don't REMOVE the target, but just move it to another place in the DOM Rob: good point, think we might still dispatch click, and we need to test Olli: target would be the same though yes Rob: if there's already incompatibility with moved elements...there's an argument to fix this for both removed and moved Mustaq: the test ... we check for click, but not sure what outcome is Rob: why don't i fork this bin and modify it to check for moved target <flackr> Moved case https://jsfiddle.net/flackr/grv2956n/5/ [group tests, and finding different results depending on browser, platform ... inconsistencies] <mustaq> I am seeing Chrome + Forefox firing click on Linux. <mustaq> Apparently Chrome on Mac doesn't?! Patrick: do we need to do something in our spec, or is this covered elsewhere? Rob: probably need to call out the mouse compat events, and that it fires to parent. click event is tricky Rob: might be functionally same whether we say it goes to ancestor of pointerdown/pointerup or of the mouse compat ones (?) Olli: feels scary potentially firing click where before it didn't, but seems sensible Rob: but at least it's a click to the ancestor/higher up, not the elements that have been modified Patrick: how easy/hard would it be to patch our spec for this? realistic to say for next meeting? Rob: we'll need data Patrick: so do we want to delay v3 until this is resolved? or punt this to future? Rob: i'd be ok leaning to: if target removed from DOM since the down event, before the up event, we don't fire click Rob: in terms of something less likely to break things. but it will be a change, as in the moved case we do see clicks Mustaq: move not so different from removed Rob: moving is remove then add Olli: it's question of at which point you check ancestor Rob: if we're worried about compat of clicks being fired where they weren't being fired before, then my suggestion is the above (if target removed since down but before up, don't fire click) Mustaq: in chrome we remember node ... Olli: i need to check implementation. we have callback for case where it's removed from DOM and it's definitely called... Rob: those are two reasonable options. third option: on removal, we implicitly track nearest thing in the chain that still IS in the DOM Rob: because with moving, you could end up firing click to something that didn't originally track the down event, which might be weird Olli: guess we need to check the click target Mustaq: tricky also if you have capturing on top ... capture on down, then remove the node ... who gets lostpointercapture Mustaq: ah no, it never gets resolved Olli: i assume you track target on stack somewhere, and then dispatch Rob: time delay. question is if we want to keep hold of a reference ... Olli: presumably, at high level, on pointerdown you check target, and then immediately/in the same task also fire mousedown, without even checking again right away Rob: whether we keep track of that target until we see the up event... chrome does, based on test results, but we need to define this [further testing] Rob: tracking element that we dispatched the down to is more useful, as it supports the reordering case i linked the bug for. maybe we can try to resolve on that Olli: that works for moving, and for removals... there's a possible web compat issue we need to figure out though Rob: need to also work out where in spec this needs to be clarified Mustaq: don't think PE spec doesn't define click target, just points to UI Events spec... Rob: think the behaviour that Firefox has might already be implied. nothing in spec says forget about down target if node is removed Mustaq: UI Event spec doesn't mention anything of that i think Rob: through that, you hold on to the element of the down event, and use that to check ancestor. if node removed, it won't have an ancestor... Rob: ... at the time of up ... Mustaq: spec doesn't say about the time of up though, so i could interpret it as at the time of down Rob: where does spec say that? Mustaq: "nearest common inclusive ancestor" Mustaq: can have multiple interpretations... Rob: we don't want to remember entire ancestor chain Mustaq: agree, spec is very handwavy Rob: we could add a few words here like: when the mouseup event is dispatched, compute the common ancestor of the down target and the up target in the current state of the DOM, or something to that effect Mustaq: need to agree on behaviour... Rob: UI Events spec also seems to say we *shouldn't* fire click... oh, doesn't say anything about not firing the event, just not to the same target (?) Olli: ...spec hints at behaviour that FX has, but it's not very precise... Rob: all for standardising on this behaviour and then checking WPT [further discussion] Rob: it does feel a bit weird, but then we define arguably weird behaviours for other situations Olli: there's also still the question about mousedown on removal Rob: feels like such an edge case ... Mustaq: think PE defines that the compat events should go to ancestor? <mustaq> "the original target's nearest ancestor node" as per PE spec... Olli: we might need to define that click only fires if pointerdown and pointerup are still in DOM Rob: prefer looking at it as the ancestor of pointerdown and poitnerup is the same... ACTION: Rob to try and write something up in the issue, continue discussion next time -- 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, 22 November 2023 18:36:48 UTC