Minutes from Pointer Events WG call 8 December 2021

Dear all,

the minutes from today's meeting are at 
https://www.w3.org/2021/12/08-pointerevents-minutes.html and copied below:

08 December 2021


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 

* touch-action:none and overflow:auto 

* 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 

Patrick: Mustaq had extra suggestions, but went ahead and merged to unblock

* Reword altitudeAngle note, expand tiltX and tiltY explanation 

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 
Olli: if we want to make PE spec more like DOM spec, we can define the 

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 
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 

Rob: we have overflow scroll API now, so we could use the logic from that

Olli: looking at comment 

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 

# 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 

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 

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 

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