Meeting minutes
Multi-pen support and persistent pointerId #353 w3c/pointerevents#353
Patrick: I see Olli made a few comments this morning on this
Patrick: on the PR
Olli: we shouldn't reserve any id for mouse ...
Olli: don't think it says the really weird part, that on down event you may not get it. nobody expects that
Rob: even the original example doesn't address that
Rob: where they were taking the unique id from the down event
Olli: because down is EXACTLY where i'd expect to get it, and use it from that point onwards
Rob: I know i explicity asked them about whether or not it will be available on the down, and the answer was no/not necessarily, depending on hardware
Rob: I agree we need to make this a much more upfront warning for developers
Olli: if it depends on a particular hardware or driver ... and is that behaviour only happening on windows?
Rob: I think it may be down to some aspect of the communication model in hardware
Rob: it MAY be that there's only windows devices that currently have this, but not hard to imagine same problem happening on other platforms once they add the hardware (e.g. adding support for a windows pen or similar)
Patrick: so next step to comment further on PR and work with original submitter?
Rob: yes, they're interested to see this through, so should be able to. there's a patch for Chromium in review right now to reflect these changes, so seem keen to get this shipped
ACTION: continue discussion on w3c/
Wide review for PE w3c/pointerevents#482
Patrick: I submitted most of the requests for review (a11y, i18n, TAG, i believe webapps too). still need to do a few more (privacy/security)
Olli: how will they let us know if there are any problems?
Patrick: they'll file issues in our repo
ACTION: Patrick to file remaining requests for review
Meta-issue: update WPT to cover Pointer Events Level 3 #445 w3c/pointerevents#445
Patrick: just a heartbeat - are there any blockers? how are we looking?
Patrick: there's 4 (as the first one is for future change in touch action) https://
Rob: just looking through, don't think there's any blockers, just a question of time
Olli: think there was something creaky with predicted events, you don't get those while testing because of limitations of test environment
Rob: that's the one you were trying to write a test for and then got stuck?
Olli: we may need to rely on coalesced events for now
Olli: testing harness doesn't support, or might be on the browser side?
Olli: don't think there's an API to tell if there ARE predicted events
Rob: suppose in the cases where you give it a sequence of events, it COULD predict events that it still has to dispatch...
Olli: and it wouldn't be what browsers actually do, because they get them from OS
Patrick: could we just do manual tests then?
Patrick: here's the visual demo that i made for predicted events https://
[discussion on how that could be used as basis for a manual test]
ACTION: Olli to start looking at manual test for predicted events and check on other ongoing ones that were started