15:00:08 <RRSAgent> RRSAgent has joined #pointerevents
15:00:08 <RRSAgent> logging to https://www.w3.org/2022/03/16-pointerevents-irc
15:00:23 <Patrick_H_Lauke> Meeting: PEWG
15:00:27 <Patrick_H_Lauke> Chair: Patrick H. Lauke
15:00:35 <smaug> present+ smaug
15:00:35 <Patrick_H_Lauke> Agenda: https://www.w3.org/events/meetings/0d3af70c-0054-43dc-9c15-c60c5b9c3f3c/20220316T110000#agenda
15:00:48 <Patrick_H_Lauke> Scribe: Patrick H. Lauke
15:00:55 <Patrick_H_Lauke> present+ Patrick_H_Lauke
15:02:11 <Patrick_H_Lauke> present+ smaug
15:02:53 <flackr> flackr has joined #pointerevents
15:03:17 <Patrick_H_Lauke> present+ mustaq
15:03:20 <Patrick_H_Lauke> present+ flackr
15:04:47 <Patrick_H_Lauke> TOPIC: Clarify which steps constitute canceling a pointer https://github.com/w3c/pointerevents/issues/400
15:05:23 <Patrick_H_Lauke> https://github.com/w3c/pointerevents/pull/437 thank you mustaq
15:06:46 <Patrick_H_Lauke> 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
15:07:23 <Patrick_H_Lauke> Patrick: my comments were mostly wording tweaks, but fundamentally this looked good to me
15:07:56 <Patrick_H_Lauke> Olli: i think suppress is exactly what gecko is using internally (when modals etc are shown)
15:08:27 <Patrick_H_Lauke> 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
15:13:01 <Patrick_H_Lauke> Patrick: i think it's fine, as "suppress" is always qualified. "cancel" has more historical baggage/connotations
15:15:08 <Patrick_H_Lauke> Patrick: we happy with "suppress"?
15:16:06 <Patrick_H_Lauke> Rob: regardless of the word, it's a step forward for sure
15:16:14 <Patrick_H_Lauke> [all agree that it's good to merge]
15:16:44 <Patrick_H_Lauke> ACTION: mustaq to make final edits, patrick to merge
15:17:06 <Patrick_H_Lauke> TOPIC: Relationship between main pointer event and coalesced events https://github.com/w3c/pointerevents/issues/409
15:17:12 <Patrick_H_Lauke>  https://github.com/w3c/pointerevents/pull/436
15:17:19 <Patrick_H_Lauke> Olli: only tiny, but i think it explains it
15:18:38 <Patrick_H_Lauke> Olli: idea was that explanation below has ordering defined, and when the list is empty, so this was all that was needed
15:18:45 <Patrick_H_Lauke> Patrick: I think it's good
15:19:23 <Patrick_H_Lauke> Rob: slight concern that "parent" event is not necessarily a clone of the last event
15:20:00 <Patrick_H_Lauke> Mustaq: we already say that parent event may not be matching the last event
15:21:03 <Patrick_H_Lauke> Rob: coordinates may not necessarily be the same...
15:22:51 <Patrick_H_Lauke> 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
15:23:06 <Patrick_H_Lauke> Rob: parent event may have frame interpolation (?)
15:24:13 <Patrick_H_Lauke> Mustaq: i think what Rob is thinking about is captured in pointerrawevent
15:24:28 <Patrick_H_Lauke> s/pointerrawevent/pointerrawupdate
15:27:10 <Patrick_H_Lauke> Mustaq: in terms of clone, movementX/Y might still not be the same...
15:27:57 <Patrick_H_Lauke> Rob: i'd expect movement to be different, because parent event is initialised in a way that represents the coalesced events
15:29:15 <Patrick_H_Lauke> Mustaq: "clone" may be a loaded term. maybe just use a more high-level "an event that represents the parent event"
15:29:32 <Patrick_H_Lauke> Olli: i want the language to be clear that it's a different object
15:29:47 <Patrick_H_Lauke> Rob: representing is a different object
15:30:01 <Patrick_H_Lauke> Rob: movement fields SHOULD be different
15:33:25 <flackr> flackr has joined #pointerevents
15:34:10 <mustaq> Is this is issue discussing movementx/y in coalesced event?
15:34:11 <mustaq> https://github.com/w3c/pointerevents/issues/409
15:34:20 <smaug> https://github.com/w3c/pointerevents/issues/131#issuecomment-333512935
15:34:22 <flackr> https://github.com/w3c/pointerevents/issues/374
15:34:26 <plh> plh has joined #pointerevents
15:37:26 <Patrick_H_Lauke> Rob: we had a note about movementx/movementy, but we moved away from being too explicit
15:38:09 <Patrick_H_Lauke> 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
15:38:58 <Patrick_H_Lauke> Mustaq: maybe add the note that we used to have, as a bullet somehow?
15:41:17 <Patrick_H_Lauke> 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
15:42:33 <Patrick_H_Lauke> 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
15:42:34 <Patrick_H_Lauke> is
15:43:36 <Patrick_H_Lauke> 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
15:44:22 <Patrick_H_Lauke> Mustaq: maybe let's continue in the issue
15:44:30 <Patrick_H_Lauke> Patrick: yes i think this needs some more time in the oven
15:45:40 <Patrick_H_Lauke> [discsussion about movement, and whether it's normative or non-normative]
15:46:07 <Patrick_H_Lauke> Mustaq: let's maybe decide this in a follow-up PR to not block this
15:47:23 <Patrick_H_Lauke> 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
15:47:58 <Patrick_H_Lauke> ACTION: Olli to work further on the PR based on discussion/concerns about "clone" and defining this further
15:48:42 <Patrick_H_Lauke> TOPIC: TPAC 2022
15:49:27 <Patrick_H_Lauke> plh: trying to gauge interest in attending TPAC in Vancouver (IRL or hybrid)
15:49:41 <Patrick_H_Lauke> present+ plh
15:49:59 <Patrick_H_Lauke> plh: have to answer survey by the 28th March
15:50:27 <Patrick_H_Lauke> 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
15:51:50 <Patrick_H_Lauke> plh: things can of course still change with COVID situation, but best to give initial impression now
15:53:25 <plh> https://www.w3.org/2002/09/wbs/34786/tpac2022-fall-meetings/
15:56:08 <Patrick_H_Lauke> 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?
15:56:39 <Patrick_H_Lauke> 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
15:57:41 <Patrick_H_Lauke> 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?
15:57:46 <Patrick_H_Lauke> [all agree]
15:58:17 <Patrick_H_Lauke> ACTION: Patrick to fill out the initial TPAC 2022 survey to say PEWG is not planning to meet specifically
15:59:11 <Patrick_H_Lauke> 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
15:59:22 <Patrick_H_Lauke> rrsagent, make logs world-visible
15:59:27 <Patrick_H_Lauke> rrsagent, make minutes
15:59:27 <RRSAgent> I have made the request to generate https://www.w3.org/2022/03/16-pointerevents-minutes.html Patrick_H_Lauke
15:59:34 <Patrick_H_Lauke> rrsagent, make logs world-visible
16:03:38 <smaug> hmm, no rob here.
16:04:45 <smaug> mustaq: in the coalesced event list, should the momement of the first event be relative to the previous parent event? I guess that should work
16:05:02 <smaug> actually, it would be relative to the last event in the previous coalesced event list
16:05:12 <smaug> that and the last parent event just have the same coordinates