Minutes from Pointer Events WG call 16 March 2022

Dear all,

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

16 March 2022


flackr, mustaq, Patrick_H_Lauke, plh, smaug

Chair: Patrick H. Lauke
Scribe: Patrick H. Lauke

* Clarify which steps constitute canceling a pointer 
* Relationship between main pointer event and coalesced events 
* TPAC 2022

# Clarify which steps constitute canceling a pointer 
https://github.com/w3c/pointerevents/pull/437 thank you mustaq

mustaq: giving brief overview. canceling was used as a term already, so 
used "suppressing". then, same wording being used in a few places for 
which events to send when, and this is collated now in one place

Patrick: my comments were mostly wording tweaks, but fundamentally this 
looked good to me

Olli: i think suppress is exactly what gecko is using internally (when 
modals etc are shown)

mustaq: in current spec "suppress" is also used in other cases. think 
it's fine, not overlapping...but if we can use another word we can 
consider that

Patrick: i think it's fine, as "suppress" is always qualified. "cancel" 
has more historical baggage/connotations

Patrick: we happy with "suppress"?

Rob: regardless of the word, it's a step forward for sure

[all agree that it's good to merge]

ACTION: mustaq to make final edits, patrick to merge

# Relationship between main pointer event and coalesced events 
  https: //github.com/w3c/pointerevents/pull/436

Olli: only tiny, but i think it explains it

Olli: idea was that explanation below has ordering defined, and when the 
list is empty, so this was all that was needed

Patrick: I think it's good

Rob: slight concern that "parent" event is not necessarily a clone of 
the last event

Mustaq: we already say that parent event may not be matching the last event

Rob: coordinates may not necessarily be the same...

Olli: idea was that the parent event would just be added to the list, so 
you don't have to check / use *both* the parent event and the coalesced 

Rob: parent event may have frame interpolation (?)

Mustaq: i think what Rob is thinking about is captured in pointerrawupdate

Mustaq: in terms of clone, movementX/Y might still not be the same...

Rob: i'd expect movement to be different, because parent event is 
initialised in a way that represents the coalesced events

Mustaq: "clone" may be a loaded term. maybe just use a more high-level 
"an event that represents the parent event"

Olli: i want the language to be clear that it's a different object

Rob: representing is a different object

Rob: movement fields SHOULD be different

<mustaq> Is this is issue discussing movementx/y in coalesced event?

<mustaq> https://github.com/w3c/pointerevents/issues/409


<flackr> https://github.com/w3c/pointerevents/issues/374

Rob: we had a note about movementx/movementy, but we moved away from 
being too explicit

Olli: can we somehow say that the coalesced list includes the event for 
the parent, BUT that it has not got the same attributes like movement

Mustaq: maybe add the note that we used to have, as a bullet somehow?

Rob: [paraphrasing] we want to say that the "parent" event is a clone of 
the last even in the coalesced events list, with its attributes updated 
to best reflect all coalesced events

Patrick: is that perhaps not back-to-front? we're defining the coalesced 
events list here, which then would redefine what the event that you just 
got it


Rob: maybe we can avoid being too specific (and saying something about 
cloning) and say that the parent and last coalesced event represent the 
last movement/position of the pointer

Mustaq: maybe let's continue in the issue

Patrick: yes i think this needs some more time in the oven

[discsussion about movement, and whether it's normative or non-normative]

Mustaq: let's maybe decide this in a follow-up PR to not block this

Patrick: and there's no other stuff that coalesced events in the list 
and the parent event have some kind of averaging, ignoring outlier 
events, etc

ACTION: Olli to work further on the PR based on discussion/concerns 
about "clone" and defining this further

# TPAC 2022
plh: trying to gauge interest in attending TPAC in Vancouver (IRL or hybrid)

plh: have to answer survey by the 28th March

plh: if you are somewhat likely to go, say so. in april we'll start 
booking equipment. if you leave it until may we may not have all equipment

plh: things can of course still change with COVID situation, but best to 
give initial impression now

<plh> https://www.w3.org/2002/09/wbs/34786/tpac2022-fall-meetings/

Patrick: do we want to discuss now? I personally won't be able to 
physically attend, but if some of you are going to be there, do you feel 
we need to set a specific time for an official meeting?

Rob: I think the way we've been working (on github, and then bi-weekly 
meeting) actually works fine for our pace, we don't have a large agenda 
that we would want to work through

Patrick: agree, i don't think the way we work is made faster/better by 
"we need more people physically/virtually in the same room at a specific 
time", but working async on most of it works for us. so i'm happy to say 
we *won't* be meeting at TPAC, unless others feel otherwise, and we'll 
just carry on at that time with our regular work mode?

[all agree]

ACTION: Patrick to fill out the initial TPAC 2022 survey to say PEWG is 
not planning to meet specifically

Patrick: in the meantime, thank you to Mustaq and Olli for their PRs, 
and we'll meet again in two weeks' time. Olli if you need any help, 
don't feel like you're now lumped with solving the tricky problem we 
have. Feel free to add some more commits and we'll review/jump in

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, 16 March 2022 17:10:06 UTC