Meeting minutes
quick round-up of PRs merged
* Remove should from boundary events note and move to normative must https://
Patrick: Mustaq had extra suggestions, but went ahead and merged to unblock
* Reword altitudeAngle note, expand tiltX and tiltY explanation https://
Patrick: small tweak that came out of working on illustrations. the "correlates to" wording originally was there i suspect when default was 0, rather than pi/2. once we changed the latter, the "correlates" seemed odd
Mustaq: yes, looks good
* Improve illustrations https://
Patrick: harmonised the look of tiltX/tiltY, and tweaked them all so the X/Y/Z axes are correct (since the Y axes were pointing in the "wrong" direction - right for 3D apps, but wrong for screen coordinates)
Rob: I was just confused about the sentence change in the #422 pull request
[explanation of what the core here is: in Touch Events altitudeAngle is 0 by default, but pi/2 in PE, so we wanted to draw attention to that]
Patrick: was even considering dropping the "However, ..." sentence to make the note purely about altitudeAngle
Mustaq: our concern was that the default being 0 implied that the pen is lying flat
Rob: in ideal world it would be good to be able to differentiate between "perpendicular" or "not available".
Mustaq: could use NaN
Olli: or nullable
Patrick: but if we did it for altitudeAngle we'd have to do it for all others tiltX/tiltY/azimuthAngle/pressure ...
Rob: arguably not many devices actually use it
ACTION: Patrick to make follow-up pull request for #422 to remove "However..." and can then discuss any further changes
and also mention that there's an attribute with same name altitudeAngle in TE
How is pointer event ctor supposed to work when coalescedEvents is passed using the PointerEventInit https://github.com/w3c/pointerevents/issues/223
Olli: if we want to make PE spec more like DOM spec, we can define the steps/algorithms
Olli: other cases are easy because automatically matching DOM spec, but there's nothing for coalesced/predicted, as they're internal to our spec
Olli: we also need to change our tests/implementations, because the target of the coalesced and predicted events is set
Olli: makes sense we don't modify the untrusted events
Rob: agree
Mustaq: sounds good
Olli: DOM spec says that specs can define their construction events
Olli: need to define that it's for all pointer events
Patrick: Olli want to take a stab at this?
Olli: I will, and tweak test. then we just need to fix implementations
ACTION: Olli to make PR for #233 and tweak tests
Olli: will probably still need to ask how to best do it
touch-action:none and overflow:auto https://github.com/w3c/pointerevents/issues/319
Patrick: we had an action last time to review #319 and see if we need/want changes to spec
Rob: where it gets tricky is that as overflow-scroll is new, many sites use clip, so they may not intend to active scroll behavior
Rob: we should prevent scroll from chaining to the outer scroller, that's going to be complicated
Patrick: is this even something WE need to define, or is this something the CSS spec needs to define? or somewhere in between?
Mustaq: need mor context
Rob: currently when you have overflow:auto/overflow:scroll it implicitly re-enabled panning. and this is confusing/surprising if author has used touch-action:none.
Rob: we have overflow scroll API now, so we could use the logic from that
Olli: looking at comment https://
Rob: I can try to come up with stronger position on this for next meeting
Olli: wonder what webkit does, is it mentioned here?
Patrick: for me, one request is to have an actual live demo of the problem, can't quite grok it at the moment
Rob: i can put together few demos, that can help us
ACTION: create some demos/think some more on best way forward for #319
rssagent, drop action 3
ACTION: Rob to create some demos/think some more on best way forward for #319
three open issues around pointer capture (make sense to look at these in block?)
Patrick: we have three issues circling around pointer capture
Order of pointer events across frames when using pointer capture https://
Clarify what the target of the click event should be after capturing pointer events https://
Clarify when lostpointercapture should fire https://
Patrick: not going to resolve these all today obviously, but as they're all related to pointer capture, these make me think we need to have a good hard look at our pointer capture section
Mustaq: #356 looks significant
Olli: these are for same origin frames, so i would expect they have the same queue for all the events
Rob: is this #356 or #355
Patrick: no sorry, #355 for this. my fault for dumping them all here
Patrick: so would be good to think about these for next meeting
Olli: #355 might be a bit special because it's different frames
Rob: might just be a chrome bug
Olli: not sure if bug, or if HTML spec says anything about input event handling across frames, or if it's something we need to define ourselves
Rob: only reason to have undefined order is if it needs to be able to run async
Patrick: beyond that, didn't have anything to discuss this time. we're working off issues marked v3 https://
Once we work off these last v3 issues, we'll be in a good position to say we want to push for v3 publication. after that, we can tackle the issues marked for future, under the new publishing model which will make the process going forward much more nimble
ACTION: look at #355 #356 #357 for next meeting