Meeting minutes
<smaug> Patrick_H_Lauke: we're still using webex?
<mustaq> I am being asked for webex login!
Coordinates of a pointercancel event w3c/pointerevents#463
Olli: didn't have time to write a test
Mustaq: do firefox and chrome behave differently with touchcancel as well?
Olli: need to test, also good to check what Safari does
Rob: what do pointerenter/pointerleave do?
Olli: those are just hacks on top of over/out
Rob: but even then they still refer to the document...
Rob: would be good to make sure it gives coordinates of last known position inside the document?
Mustaq: i think Navid was looking at this...
Mustaq: for cancel it's tricky because it may have been cancelled for a variety of reasons
Olli: do we want to expose coords for situations when coords WERE known?
Rob: we could always report last known good coords. would be good to see what the developer use case would be.
Olli: wasn't there a chrome bug about this? what was the complaint
Mustaq: the bug reported complained that they got 0/0, don't think they understood the situation that may lead to a cancel
Rob: [speculates about situations where relying on getting last known good x/y on cancel may be useful]
Rob: it won't give devs anything more useful or wrong than listening to all the move events and looking at the last one that came in
Olli: might be good to see how touchcancel is handled, for possible consistency
Olli: for pointercancel just before a dragstart we send the last known good coordinates in gecko
Olli: per what the drag'n'drop spec demands
Patrick: conceptually i like the idea of "send the last known good, otherwise 0/0" or should it be null/null?
Patrick: we would always have a coordinate, as otherwise pointer would not exist in the first place
Rob: we'll still have the challenge of pressure, like we had to do for up event, but we have precedent
Patrick: we do have a slightly different situation though as cancel could happen while pressure is full, etc. so maybe copy/transplant last known good values for all of those
ACTION: propose some additional wording to clarify values of properties on cancel
ACTION: Olli to write test for touchcancel, for consistency check
Meta-issue: update WPT to cover Pointer Events Level 3 w3c/pointerevents#445
https://
<flackr> https://
Rob: touch events DO say what happens with coordinates for touchcancel
Rob: so the proposal here would be consistent
Patrick: might have a look to see if TE spec says anything about pressure etc
Patrick: so for the WPT one we do now have the list of things lacking tests https://
Mustaq: some of those tests would be trivial, others not so much. expect to look at them sometime this month, but no progress
Olli: I should try to find some time. Ask Edgar, also
Mustaq: how do we coordinate?
Olli: add a comment to the issue w3c/
Olli: sorry, comment on the relevant PR
Heartbeat: Clarify what the target of the click event should be after capturing pointer events w3c/pointerevents#356
Olli: I did ask Anne if he could find somebody from Apple to comment on it, but still waiting
<mustaq> w3c/
raw trackpad data issue
<mustaq> We discussed this here before: w3c/
Patrick: and we also have w3c/
[short discussion on the topic]
Patrick: fundamentally, this feels too low-level and not quite in line with what PE do. has shades of sensor api (access sensor for trackpad directly) and even pointer lock (as if i'm, say, doing a signature on a trackpad, i don't want my mouse to move around the screen).
Patrick: I'll file a comment on all the above issues pointing to https://
ACTION: Patrick to comment on the three related issues/feature requests about raw trackpad data
[further brief discussion on the similarities between the ask of raw trackpad and pointer lock API]