- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Wed, 8 Dec 2021 16:50:53 +0000
- To: "public-pointer-events@w3.org" <public-pointer-events@w3.org>
Dear all, the minutes from today's meeting are at https://www.w3.org/2021/12/08-pointerevents-minutes.html and copied below: PEWG 08 December 2021 Agenda https://www.w3.org/events/meetings/9718517d-0e08-4377-bb7c-07332948233b/20211208T110000 Attendees Present flackr, Patrick H. Lauke, smaug, mustaq Chair: Patrick H. Lauke Scribe: Patrick_H_Lauke * quick round-up of PRs merged * How is pointer event ctor supposed to work when coalescedEvents is passed using the PointerEventInit https://github.com/w3c/pointerevents/issues/223 * touch-action:none and overflow:auto https://github.com/w3c/pointerevents/issues/319 * three open issues around pointer capture (make sense to look at these in block?) # quick round-up of PRs merged * Remove should from boundary events note and move to normative must https://github.com/w3c/pointerevents/pull/419 Patrick: Mustaq had extra suggestions, but went ahead and merged to unblock * Reword altitudeAngle note, expand tiltX and tiltY explanation https://github.com/w3c/pointerevents/pull/422 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://github.com/w3c/pointerevents/pull/423 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://github.com/w3c/pointerevents/issues/319#issuecomment-614788889 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://github.com/w3c/pointerevents/issues/355 Clarify what the target of the click event should be after capturing pointer events https://github.com/w3c/pointerevents/issues/356 Clarify when lostpointercapture should fire https://github.com/w3c/pointerevents/issues/357 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://github.com/w3c/pointerevents/issues?q=is%3Aissue+is%3Aopen+label%3Av3 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 -- Patrick H. Lauke https://www.splintered.co.uk/ | https://github.com/patrickhlauke https://flickr.com/photos/redux/ | https://www.deviantart.com/redux twitter: @patrick_h_lauke | skype: patrick_h_lauke
Received on Wednesday, 8 December 2021 16:51:10 UTC