Meeting minutes
Clarify which steps constitute canceling a pointer https://github.com/w3c/pointerevents/issues/400
https://
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/issues/409
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 event
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://
<smaug> https://
<flackr> https://
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
is
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://
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