Minutes from Pointer Events WG call 1 March 2023

Dear all,

the minutes from today's meeting are at 
https://www.w3.org/2023/03/01-pointerevents-minutes.html and copied below:


PEWG

01 March 2023

Agenda: 
https://www.w3.org/events/meetings/a81709f0-4b0c-48a7-afa9-36828ab63073/20230301T110000

Attendees
flackr, mustaq, Patrick_H_Lauke

Chair: Patrick H. Lauke
Scribe: Patrick H. Lauke, Patrick_H_Lauke

* Coordinates of a pointercancel event w3c/pointerevents#463

* Wacom Airbrush and tangentialPressure

* should note be normative...

* Meta-issue: update WPT to cover Pointer Events Level 3 
w3c/pointerevents#445

* Heartbeat: Clarify what the target of the click event should be after 
capturing pointer events w3c/pointerevents#356



# Coordinates of a pointercancel event w3c/pointerevents#463

Review/discuss proposed PR w3c/pointerevents#464

Mustaq made a suggestion/comment here w3c/pointerevents#463 (comment)

Mustaq: when i look at pointerup and pointercancel, i wonder if we want 
to change pointerup the same way as well

Rob: we made conscious decision to go with 0 for pointerup, as it makes 
sense from an event stream perspective

Rob: in my mind it makes sense that they're not identical (pointerup 
being empty, pointercancel carrying the last known good values)

Mustaq: thinking about perspective of spec maintenance. we now list a 
bunch of properties... developers can get those values by just checking 
the last pointermove

<mustaq> 
https://pr-preview.s3.amazonaws.com/w3c/pointerevents/464/ed733e3...1aefdf1.html

Mustaq: so is this not an edge case that makes the spec bulkier for no 
actual developer gain

Mustaq: concerned that if the spec changes in future, we may go out of sync

Rob: what are you suggesting?

Mustaq: we're changing spec without any benefit (to developers)

Mustaq: we can motivate developers to just listen to pointermove, and 
not pointercancel

Patrick: I made it quite explicit, listing all properties, and 
explicitly saying coalescedEvents and predictedEvents will be empty, to 
avoid handwavy confusion later on.

Patrick: I conceptually quite like this, as I can imagine as a developer 
maybe you're not been following EVERY pointermove, but when you get a 
pointercancel you want to make absolutely sure you "clean up house" on 
whatever you were doing just when the cancel happened

[discussion about consistency: with the proposed change to 
pointercancel, we specify values for pointercancel. but for pointerup, 
we say pressure is zero in the pressure property definition as a note]

Patrick: happy to move the note from 4.1 where it talks about pressure 
to a similar matching paragraph in the pointerup event description. does 
that make sense?

[mustaq and rob agree]

ACTION: merge the proposed PR, patrick to create matching/similar PR to 
move note about pressure into pointerup definition



# Wacom Airbrush and tangentialPressure

https://lists.w3.org/Archives/Public/public-pointer-events/2023JanMar/0041.html

<mustaq> https://chromestatus.com/feature/5765742146355200

Mustaq: we shipped tangentialPressure and twist together, but it may be 
incomplete

Patrick: problem is likely that there's not many devices that have this

Patrick: will ping Olli separately to see if he knows why it's not in 
Firefox implementation either

ACTION: Mustaq/Patrick/Olli to investigate if implementation is 
incomplete in browsers

<mustaq> w3c/pointerevents#403 (comment)



# should note be normative...

Mustaq: if i search spec for passive, I only see this one mention. did 
we want to make the note normative or did we consciously choose to make 
it non-normative?

Patrick: so looking in section 11 
https://pr-preview.s3.amazonaws.com/w3c/pointerevents/464/ed733e3...1aefdf1.html#compatibility-mapping-with-mouse-events 
the note: Compatibility mouse events can't be prevented when a pointer 
event EventListener is set to be passive [ DOM ].

Patrick: I'm happy to make this an actual normative prose, not a 
non-normative note. don't think there was any actual reason/rationale 
for us to make it a note...

<mustaq> Sounds good, I will add a test soon accordingly.

Patrick: noting that the entire section 11 is OPTIONAL, but that should 
not prevent us from making this normative text (normative as in "IF a UA 
does this, THEN this is normative")

ACTION: remove the "note" bit, and make this part of the normative text



# Meta-issue: update WPT to cover Pointer Events Level 3 
w3c/pointerevents#445

Patrick: I see that work has been progressing nicely on this, so no concerns

Mustaq: have been working on 3 at the moment, will carry on

<mustaq> I am working on #403, #404 and #457

<Github> w3c/pointerevents#403 : Expand prose about preventing 
compatibility mouse events and make it normative

<Github> w3c/pointerevents#404 : Add note about rounding coordinates for 
click, auxclick, contextmenu

<Github> w3c/pointerevents#457 : pointerout even if the pointer doesn't 
move?

Patrick: and I know Olli has been working on a few



# Heartbeat: Clarify what the target of the click event should be after 
capturing pointer events w3c/pointerevents#356

Patrick: I know there's not been movement. Suggest that once we closed 
all other issues, we have a meeting to decide what to do with this in 
the meantime (deferring to next version and explicitly mentioning it in 
spec, for instance)

Patrick: if there's no further issues, we'll adjurn for now. Thank you both


-- 
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, 1 March 2023 17:06:54 UTC