- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Wed, 10 May 2023 16:01:39 +0000
- To: "Pointer Events Working Group" <public-pointer-events@w3.org>
Dear all, the minutes from today's meeting are at https://www.w3.org/2023/05/10-pointerevents-minutes.html and copied below: PEWG 10 May 2023 Agenda: https://www.w3.org/events/meetings/81ad3e7c-6dde-48ec-8693-09a9adea9f69/20230510T110000 IRC log: https://www.w3.org/2023/05/10-pointerevents-irc Attendees : flackr, mustaq, Patrick_H_Lauke, smaug Chair: Patrick H. Lauke Scribe : Patrick H. Lauke, Patrick_H_Lauke * Meta-issue: update WPT to cover Pointer Events Level 3 w3c/pointerevents#445 * Heartbeat: Clarify what the target of the click event should be after capturing pointer events w3c/pointerevents#356 * TPAC # Meta-issue: update WPT to cover Pointer Events Level 3 w3c/pointerevents#445 Go over https://github.com/w3c/pointerevents/issues?q=is%3Aclosed+label%3Aneeds-wpt+ Olli: wonder how we can get through all these tests Mustaq: was hoping to do more, but not had time Patrick: I'll see if i can get env set up for testing at my end, but should we rope in extra help? Olli: I'll see if I can get Edgar (?) to help Mustaq: same here # Heartbeat: Clarify what the target of the click event should be after capturing pointer events w3c/pointerevents#356 Patrick: did some testing with the latest codepen w3c/pointerevents#356 (comment) Patrick: only tested with `touch-action` and explicit release. Can rerun/document tests also with the explicit release disabled [discussion on whether we should also test all other iterations] Mustaq: originally, we didn't have implicit capture/implicit release, but we convinced Microsoft at the time that we'd do implicit capture for touch, but releasing would be same for all pointer types (?) Rob: if devs use pointer capture, they can rely on implicit release, or do it themselves explicitly Mustaq: if implicit release is different from explicit release, then that's a problem/bug ACTION: do more testing with explicit capture off and document results <flackr> https://w3c.github.io/pointerevents/#implicit-release-of-pointer-capture <flackr> "If the user agent supports firing the click or auxclick event, and if in an implicit release scenario both that (click or auxclick) event and a lostpointercapture event are fired, the click or auxclick event SHOULD be fired before lostpointercapture." Rob: this is what led me to believe that explicit release is different from implicit release. if you think they should be the same, then we should remove that Olli: didn't i file a spec issue that said the opposite of this? the order was unclear <smaug> w3c/pointerevents#357 Mustaq: calling release doesn't immediately release, so there may be some leeway Rob: but we'd still expect the click to be captured Rob: but that does affect what i'd expect the outcome to be. until lostpointercapture, i'd expect the click to be captured Mustaq: it's because of the async nature Rob: we should either consistently delay pointer capture before, or after. not having click dispatched sync or async and get different results Rob: behaviour i was pushing for is changing touch behaviour so we don't use the pointer capture until after click is dispatched Mustaq: for touch, we also have pointerleave and pointerout. which then also trigger the capture release. if we make click sync, these will also need to be addressed Rob: naive thing would be to delay out and leave if you have delayed clicks, which doesn't seem crazy but is a pretty big change, perhaps argument in favour of losing pointer capture before the click... Mustaq: looking for section about pending pointer capture Patrick: https://w3c.github.io/pointerevents/#process-pending-pointer-capture Mustaq: "The user agent MUST run..." so this includes out and leave Rob: and click Mustaq: but this was done before click Rob: so spec is contradicting itself Patrick: Rob do you want to file an issue on this? Olli: my issue is about this w3c/pointerevents#357 Rob: one question is: simplest change would be release pointer capture after pointer up. then click goes to common ancestor of common ancestor and the down event Rob: we did some compat evaluation for this at some point? Mustaq: not for this one Rob: less worried about order than the target Mustaq: compat could also be deciding factor Rob: what would happen if we lost pointer capture before click and fired click at the ancestor Rob: how many pages would this affect, or something to that effect Mustaq: could you add this as a comment to the issue (https://github.com/w3c/pointerevents/issues/356) Olli: maybe safari on desktop is the simplest Olli: for cases 3 and 4 Patrick: it's doing what Rob is suggesting, firing click to ancestor after capture lost Rob: but then row 2 is weird, firing click to green Olli: ... then there's also the weirdness for devs who do capture and then assume that means they'll also get the click Rob: that would assume changing how capture works to wait for click as well, the other way of solving this Mustaq: ... we could say even though point is lost, click still goes to the element where the pointerup happened Rob: ergonomically, this is more useful for devs, but would rather do something that's more generally useful even though harder to spec Mustaq: we should definitely check on compat Rob: we could see how often target gets changed Mustaq: I think we DID test that aspect, we added a counter.... Mustaq: had planned to add a test in canary, but we didn't get to that point Mustaq: the bug mentions a counter, but we didn't post the result back [checking if counter is still there or expired] <flackr> https://chromestatus.com/metrics/feature/timeline/popularity/3942 Rob: even if target changes, doesn't tell us if page breaks Mustaq: what's next step then? I think we should report this upper bound in the issue Rob: I left it in IRC/notes Rob: I do notice - I don't think this counter cares if there's a click handler or not. so would be possible to try to get a better estimate / lower upper bound of when there ARE click handlers for the old/new target Olli: and you'd have to check if there's elements like anchors Mustaq: Rob for now I'll reopen the issue for this counter in case we need to fine-tune this one, WDYT Rob: risk is unknown, we have an upper bound, we might try to launch something with caveat that if we see significant breakage we pull back Mustaq: let's continue this outside of the meeting ACTION: Rob/Mustaq to investigate further about counter/test to get more data to make decision # TPAC Patrick: so the dates/times that were available are > Monday 11 September: 09:30 - 11:00 > Monday 11 September: 11:30 - 13:00 > Monday 11 September: 17:00 - 18:30 > Tuesday 12 September: 09:30 - 11:00 > Tuesday 12 September: 11:30 - 13:00 > Tuesday 12 September: 17:00 - 18:30 > Thursday 14 September: 09:30 - 11:00 > Thursday 14 September: 11:30 - 13:00 > Thursday 14 September: 17:00 - 18:30 > Friday 15 September: 09:30 - 11:00 > Friday 15 September: 11:30 - 13:00 > Friday 15 September: 17:00 - 18:30 [discussion on which date/time would preliminarily work] Patrick: so I'll put us down for thursday 14 September 17:00-18:30, we can always change it (within reason) on an ad-hoc basis as it's just the four of us ACTION: complete TPAC session form -- Patrick H. Lauke https://www.splintered.co.uk/ / https://github.com/patrickhlauke / https://codepen.io/patrickhlauke https://flickr.com/photos/redux/ / https://www.deviantart.com/redux https://mastodon.social/@patrick_h_lauke
Received on Wednesday, 10 May 2023 16:01:50 UTC