- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Wed, 5 Jun 2024 16:42:15 +0100
- To: Pointer Events Working Group <public-pointer-events@w3.org>
Dear all, the minutes from today's meeting are at https://www.w3.org/2024/06/05-pointerevents-minutes.html and copied below: PEWG 05 June 2024 Agenda: https://www.w3.org/events/meetings/6246bc85-4dae-43a8-a50c-9bc5a0829585/20240605T110000/ IRC log: https://www.w3.org/2024/06/05-pointerevents-irc Attendees: flackr, mustaq, Patrick_H_Lauke, smaug Chair: Patrick H. Lauke Scribe: Patrick H. Lauke * Multi-pen support and persistent pointerId #353 w3c/pointerevents#353 * Meta-issue: update WPT to cover Pointer Events Level 3 #445 w3c/pointerevents#445 * AOB # Multi-pen support and persistent pointerId #353 w3c/pointerevents#353 related PR w3c/pointerevents#495 Rob: I left my +1 to the "sure, let's call it persistentDeviceId and put it on the event" Olli: I also agree, not sure what default values would be Rob: for default value, it could be 0 for developers to do truthiness checks Rob: we were originally going to have 0 as default, but some implementation used 0 for the mouse Olli: initially there wasn't any decision, some used 0, some 1 ... Rob: suggest as there's no precedent, we use 0 for uninitialised or unknown Olli: would be nice if the id was random... Rob: we're not reserving any id values for this, and it's supposed to be random Olli: need to make sure that implementations don't just default to something like 1 for mouse Olli: could do a WPT to check that persistentDeviceId for a mouse is different - open two origins/documents and verify that they don't have the same id for mouse Olli: test could be cross-origin Rob: sounds reasonable [discussion around whether or not different OSs support multiple mouse pointers - all OSs pretend it's one device?] Rob: I believe Chrome does give a persistent id for mouse, so we can test that Patrick: so for next steps - I will explore setting up a new vNext branch, retarget this PR to that, then we should do one final review on this and can then merge it into that. Will follow up again with Philippe about whetehr or not new branch will cause problems Olli: we should also work on test now, so we don't have to circle back ACTION: Patrick to set up new vNext branch and repoint PR there, group to review PR # Meta-issue: update WPT to cover Pointer Events Level 3 #445 w3c/pointerevents#445 Patrick: did you all manage to meet up for some WPT work two weeks ago? mustaq: yes, we were able to close a few of the outstanding WPTs, should get there in a few more days Olli: have a few more to do, but made good progress Rob: I didn't have a chance, but we're in a good spot - we know what we need/want to test Olli: so we have 2 left now <mustaq> Two more left: #477 and #300 <smaug> whatwg/html#7341 # AOB Olli: the above just came up in some other discussion Olli: mozilla internal triage of spec issues Rob: i believe, mustaq, that your comment says we can't always consider the down for non-mouse as activation, but there may be some mitigations. Rob: we could distinguish based on the cancelability of pointerdown whether it gives activation Rob: if you haven't changed the touch-action, cancelling the pointerdown does not prevent scrolling Rob: i don't know how we represent that state, I believe it's a bit handwavy in the spec. but there IS a difference betwen pointerdowns that CAN cause scrolling/can't be cancelled, and once that don't. this could help situation a bit, even if we can't fully resolve it Rob: as dev, i fear danger of developer writing a pointerDown listener, testing on desktop with mouse, and then not realising it's not triggering/activating on touch/stylus mustaq: there is a fundamental difference between dragging with mouse vs dragging with finger... mustaq: Olli if you can add more context to the issue of what challenges you face... Olli: oh this was only part of our triage, so no immediate challenge Olli: not seen any recent bug reports for this Rob: my concern is you can't use pointerevents reliably for user activation Olli: forces people to use something like click. yeah we can continue thinking about this, but just as a reminder Rob: was hoping that we can establish if you're in a situation where the pointerdown can't result in a scroll... Rob: or we just say you can't get activation until click event (even for mouse), but that could potentially break implementations mustaq: i can't see a way to consolidate them, not all pointerdown will result in scroll, but the spec should say something either way Patrick: purely from my luddite view, I quite like the idea to try and not cause "accidental activation", if there's a way to differentiate (using cancelability or similar) a pointerdown on touch/stylus that is a scroll vs one that is doing something (because the author has used touch-action), then that would make sense [discussion that it's not directly the cancelability of the event that counts here, but some hint about whether it will or won't cause panning] Patrick: thank you all, catch you again in 2 weeks' time -- Patrick H. Lauke * https://www.splintered.co.uk/ * https://github.com/patrickhlauke * https://flickr.com/photos/redux/ * https://mastodon.social/@patrick_h_lauke
Received on Wednesday, 5 June 2024 15:42:22 UTC