- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Wed, 25 May 2022 16:39:47 +0100
- 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/05/25-pointerevents-minutes.html and copied below: PEWG 25 May 2022 Agenda: https://www.w3.org/events/meetings/0d3af70c-0054-43dc-9c15-c60c5b9c3f3c/20220525T110000 Attendees flackr, mustaq, Patrick_H_Lauke, smaug Chair: Patrick H. Lauke Scribe: Patrick H. Lauke * Touch Events CG * Explain relation of coalesced events to parent event https://github.com/w3c/pointerevents/pull/440 * Clarify what the target of the click event should be after capturing pointer events https://github.com/w3c/pointerevents/issues/356 * Defining event orders through a "state of the input device" https://github.com/w3c/pointerevents/issues/438 # Touch Events CG Patrick: just a small note to say that the group aim/description has now been updated - mostly pointing back to us https://www.w3.org/community/touchevents/ https://www.w3.org/groups/cg/touchevents # Explain relation of coalesced events to parent event https://github.com/w3c/pointerevents/pull/440 Olli: the "As a result..." is a bit weird, but otherwise it's ok Mustaq: concern about "events" vs "event types" Flackr: how about we merge this now and can always tweak wording later Patrick: should we merge? <mustaq> Sounds good [all agree] # Clarify what the target of the click event should be after capturing pointer events https://github.com/w3c/pointerevents/issues/356 Patrick: i added this to the agenda, but wasn't sure if there actually had been action over last two weeks, or if this a more long-running action Olli: question about whether there's always a click after the up (?) Flackr: one option is to retain pointer capture until it's determined if a click is fired Olli: wonder if this would affect something else. hopefully nobody is mixing pointer and mouse events, as that may cause issues Olli: but maybe it's ok. fire lostpointercapture when we know click won't fire so we don't need to capture anymore Olli: only for implicit release Mustaq: what about double-tap? Flackr: depends if it results in zoom Flackr: if double-tap to zoom is disabled, each tap will be an independent event Flackr: and i think that's consistent with mouse behavior Flackr: because you get implicit capture release on click ... and if you had an explicit capture, it'll be released on the first... Olli: click is odd because it's not user input, but reaction to the "up" <smaug> (btw, I'll need to leave 15 min early today) Olli: what else do we need here? was starting to look at our code Flackr: think we're in agreement that it should behave this way: without releasing capture explicitly, it should be released implicitly when determined that there won't be a click Mustaq: when touch is not canceled, it will fire a click... Patrick: so what's outcome? Flackr: change to the spec to reflect what we discussed, tests Olli: would be good to have one implementation to check we didn't overlook something Olli: and tests Olli: this will then hopefully address #356 and (maybe) #357 Flackr: I think so ACTION: next steps for #357 to find an implementation/test Mustaq: I don't think we have chrome bugs for this, but need to investigate. changes for both touch and mouse Olli: same in firefox # Defining event orders through a "state of the input device" https://github.com/w3c/pointerevents/issues/438 Mustaq: i think I got something wrong on this, so let's close this bug. think the state diagram was more confusing than helpful ACTION: close issue Patrick: let me just look over other issues not tagged as v3 ... https://github.com/w3c/pointerevents/issues Patrick: nothing there tagged "future" that we want to tackle for v3, so think we're good Mustaq: what timeline are we looking at for going to REC for v3? Patrick: i'm not in any particular rush, but will confirm with Philippe Le Hegaret about best timings. if i remember right, our group's charter still has ample time (not like last time where we needed extension to push through v2). I'm going to guess October or something this year? as for having implementations, I'm sure there's some leniency even if not rolled out, particularly as we're not talking about a whole new feature, but just a refinement of event order. even just an agreement in principle that two implementers are working on it actively should be fine, even if tests currently fail (in implementation report) Olli: question about whether we carry on with these meetings, now that the last outstanding item is this longer-running implementation question. find it quite useful as a bit of a motivator to push things through, having that scheduled meeting Flackr: agree, good to have meeting just as a reminder to do things Patrick: happy to keep these meetings going every two weeks more as a "heartbeat" / status meeting until we've published v3 REC [group agrees] Patrick: thank you all, speak to you again in 2 weeks' time -- 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, 25 May 2022 15:40:00 UTC