15:54:00 RRSAgent has joined #pointerevents 15:54:00 logging to https://www.w3.org/2021/12/08-pointerevents-irc 15:57:41 Meeting: PEWG 15:57:44 Chair: Patrick H. Lauke 15:58:03 Agenda: https://www.w3.org/events/meetings/9718517d-0e08-4377-bb7c-07332948233b/20211208T110000 15:58:17 Scribe: Patrick_H_Lauke 15:58:22 present+ Patrick H. Lauke 16:00:03 present+ smaug 16:00:36 flackr has joined #pointerevents 16:00:42 present +flackr 16:01:22 TOPIC: quick round-up of PRs merged 16:02:08 * Remove should from boundary events note and move to normative must https://github.com/w3c/pointerevents/pull/419 16:03:28 Patrick: Mustaq had extra suggestions, but went ahead and merged to unblock 16:03:45 * Reword altitudeAngle note, expand tiltX and tiltY explanation https://github.com/w3c/pointerevents/pull/422 16:05:18 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 16:05:22 Mustaq: yes, looks good 16:05:46 * Improve illustrations https://github.com/w3c/pointerevents/pull/423 16:08:27 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) 16:11:29 bkardell_ has joined #pointerevents 16:11:57 Rob: I was just confused about the sentence change in the #422 pull request 16:12:30 [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] 16:12:45 Patrick: was even considering dropping the "However, ..." sentence to make the note purely about altitudeAngle 16:13:25 Mustaq: our concern was that the default being 0 implied that the pen is lying flat 16:15:21 Rob: in ideal world it would be good to be able to differentiate between "perpendicular" or "not available". 16:16:57 Mustaq: could use NaN 16:17:01 Olli: or nullable 16:17:29 Patrick: but if we did it for altitudeAngle we'd have to do it for all others tiltX/tiltY/azimuthAngle/pressure ... 16:18:09 Rob: arguably not many devices actually use it 16:19:51 ACTION: Patrick to make follow-up pull request for #422 to remove "However..." and can then discuss any further changes 16:20:46 and also mention that there's an attribute with same name altitudeAngle in TE 16:21:14 TOPIC: How is pointer event ctor supposed to work when coalescedEvents is passed using the PointerEventInit https://github.com/w3c/pointerevents/issues/223 16:22:09 Olli: if we want to make PE spec more like DOM spec, we can define the steps/algorithms 16:22:39 Olli: other cases are easy because automatically matching DOM spec, but there's nothing for coalesced/predicted, as they're internal to our spec 16:23:08 Olli: we also need to change our tests/implementations, because the target of the coalesced and predicted events is set 16:23:21 Olli: makes sense we don't modify the untrusted events 16:23:25 Rob: agree 16:23:29 Mustaq: sounds good 16:24:45 Olli: DOM spec says that specs can define their construction events 16:25:01 Olli: need to define that it's for all pointer events 16:25:14 Patrick: Olli want to take a stab at this? 16:25:23 Olli: I will, and tweak test. then we just need to fix implementations 16:25:41 ACTION: Olli to make PR for #233 and tweak tests 16:25:52 Olli: will probably still need to ask how to best do it 16:26:15 TOPIC: touch-action:none and overflow:auto https://github.com/w3c/pointerevents/issues/319 16:26:33 Patrick: we had an action last time to review #319 and see if we need/want changes to spec 16:28:15 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 16:28:31 Rob: we should prevent scroll from chaining to the outer scroller, that's going to be complicated 16:29:27 Patrick: is this even something WE need to define, or is this something the CSS spec needs to define? or somewhere in between? 16:29:31 Mustaq: need mor context 16:30:13 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. 16:30:43 Rob: we have overflow scroll API now, so we could use the logic from that 16:32:41 Olli: looking at comment https://github.com/w3c/pointerevents/issues/319#issuecomment-614788889 16:33:07 Rob: I can try to come up with stronger position on this for next meeting 16:33:16 Olli: wonder what webkit does, is it mentioned here? 16:34:06 Patrick: for me, one request is to have an actual live demo of the problem, can't quite grok it at the moment 16:34:17 Rob: i can put together few demos, that can help us 16:34:38 ACTION: create some demos/think some more on best way forward for #319 16:35:30 rssagent, drop action 3 16:35:46 ACTION: Rob to create some demos/think some more on best way forward for #319 16:37:05 TOPIC: three open issues around pointer capture (make sense to look at these in block?) 16:37:19 Patrick: we have three issues circling around pointer capture 16:37:20 Order of pointer events across frames when using pointer capture https://github.com/w3c/pointerevents/issues/355 16:37:20 Clarify what the target of the click event should be after capturing pointer events https://github.com/w3c/pointerevents/issues/356 16:37:20 Clarify when lostpointercapture should fire https://github.com/w3c/pointerevents/issues/357 16:38:34 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 16:38:42 Mustaq: #356 looks significant 16:39:19 Olli: these are for same origin frames, so i would expect they have the same queue for all the events 16:40:15 Rob: is this #356 or #355 16:40:25 Patrick: no sorry, #355 for this. my fault for dumping them all here 16:41:50 Patrick: so would be good to think about these for next meeting 16:42:03 Olli: #355 might be a bit special because it's different frames 16:42:13 Rob: might just be a chrome bug 16:42:38 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 16:42:57 Rob: only reason to have undefined order is if it needs to be able to run async 16:43:44 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 16:45:51 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 16:46:13 ACTION: look at #355 #356 #357 for next meeting 16:46:31 rrsagent, set logs world-visible 16:46:43 rrsagent, create minutes 16:46:43 I have made the request to generate https://www.w3.org/2021/12/08-pointerevents-minutes.html Patrick_H_Lauke 16:46:48 rrsagent, set logs world-visible 16:47:04 rrsagent, bye 16:47:04 I see 5 open action items saved in https://www.w3.org/2021/12/08-pointerevents-actions.rdf : 16:47:04 ACTION: Patrick to make follow-up pull request for #422 to remove "However..." and can then discuss any further changes [1] 16:47:04 recorded in https://www.w3.org/2021/12/08-pointerevents-irc#T16-19-51 16:47:04 ACTION: Olli to make PR for #233 and tweak tests [2] 16:47:04 recorded in https://www.w3.org/2021/12/08-pointerevents-irc#T16-25-41 16:47:04 ACTION: create some demos/think some more on best way forward for #319 [3] 16:47:04 recorded in https://www.w3.org/2021/12/08-pointerevents-irc#T16-34-38 16:47:04 ACTION: Rob to create some demos/think some more on best way forward for #319 [4] 16:47:04 recorded in https://www.w3.org/2021/12/08-pointerevents-irc#T16-35-46 16:47:04 ACTION: look at #355 #356 #357 for next meeting [5] 16:47:04 recorded in https://www.w3.org/2021/12/08-pointerevents-irc#T16-46-13