Minutes from PEWG meeting 5 June 2024

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