- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Wed, 16 Mar 2022 17:09:53 +0000
- To: "public-pointer-events@w3.org" <public-pointer-events@w3.org>
Dear all, the minutes from today's meeting are at https://www.w3.org/2022/03/16-pointerevents-minutes.html and copied below PEWG 16 March 2022 Agenda https://www.w3.org/events/meetings/0d3af70c-0054-43dc-9c15-c60c5b9c3f3c/20220316T110000#agenda Attendees: flackr, mustaq, Patrick_H_Lauke, plh, smaug Chair: Patrick H. Lauke Scribe: Patrick H. Lauke * Clarify which steps constitute canceling a pointer https://github.com/w3c/pointerevents/issues/400 * Relationship between main pointer event and coalesced events https://github.com/w3c/pointerevents/issues/409 * TPAC 2022 # Clarify which steps constitute canceling a pointer https://github.com/w3c/pointerevents/issues/400 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/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://github.com/w3c/pointerevents/issues/409 <smaug> https://github.com/w3c/pointerevents/issues/131#issuecomment-333512935 <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 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://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