- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Wed, 11 May 2022 16:47:30 +0100
- To: Pointer Events Working Group <public-pointer-events@w3.org>
Dear all, the minutes from today's meeting are at https://www.w3.org/2022/05/11-pointerevents-minutes.html and copied below: PEWG 11 May 2022 Agenda: https://www.w3.org/events/meetings/0d3af70c-0054-43dc-9c15-c60c5b9c3f3c/20220511T110000 Attendees: flackr, mustaq, Patrick_H_Lauke. Regrets: smaug Chair: Patrick H. Lauke Scribe: Patrick H. Lauke, Patrick_H_Lauke * Relationship between main pointer event and coalesced events https://github.com/w3c/pointerevents/issues/409 * Clarify what the target of the click event should be after capturing pointer events https://github.com/w3c/pointerevents/issues/356 # Relationship between main pointer event and coalesced events https://github.com/w3c/pointerevents/issues/409 Rob: had very initial pass trying to specify this https://github.com/w3c/pointerevents/pull/440 Rob: it's a very rough initial summing up of what we discussed in previous meetings. Goal is not to explain resampling, but just handwave it/mention it Rob: intention to explain that it's not necessarily identical to the set of coalesced events Patrick: looks good to me, as we don't want to explain coalescing anyway as it's out of scope for our group (proprietary / secret sauce / blackbox left up to UAs / devices) Mustaq: wondering if there's an alternative to "frame" Rob: could say "align to display" Mustaq: refresh rate? Rob: not the best either. could be super vague "align with the hardware..." Mustaq: ...to align with frame refresh timing... to align with frame timing ... Rob: frame timing has specific meaning, there's a specific frame timing spec Rob: we could have "but may have additional processing (for example, to align with the display refresh rate)" Patrick: yes I could go for this Rob: we don't want to specify all cases, just give examples. happy to modify the PR with that Patrick: great, I'll point Olli to this, and we can either approve whenever he oks this or at the next meeting ACTION: Olli to review https://github.com/w3c/pointerevents/pull/440/ and see if it's ok # Clarify what the target of the click event should be after capturing pointer events https://github.com/w3c/pointerevents/issues/356 Patrick: action was "Mustaq to propose some more fleshed out wording" <mustaq> https://github.com/w3c/pointerevents/issues/356#issuecomment-1064765460 <mustaq> I kind of agree here that about not expecting/interpreting "click" on drag. Mustaq: not arguing about sending click or not, but about the target Mustaq: my interpretation is that we don't need to worry about click dispatch after release on a drag Rob: but this is asking to get click on the captured element, final line Rob: I think they agree with my proposed behavior that click is captured [looking at the two opposite requests in the comments] Rob: think we agreed in last meeting ... what Olli said in https://github.com/w3c/pointerevents/issues/356#issuecomment-1111142169 Mustaq: so fire releasePointerCapture after click? Rob: yes Rob: we agree on proposed behavior as long as there's no implementation concerns. conceptually it should be fine, because until we send delayed click there can't be any other events. there should be no conflict with other events coming in before we release capture, as they're involved in the current gesture Rob: really just question of implementations deferring the release of pointercapture until we decide if click is generated or not Mustaq: what if it's double-tap? [discussion on whether you'd be even able to get double-tap, pointercapture, UA deciding if click needs sending] Rob: in this proposal we wouldn't release pointercapture on the first up, because it's not been decided if a click gets sent. but the pointerid will be different for the second tap (?) Mustaq: some timing challenges Rob: think there's a consistent stream of events that can be sent ACTION: further exploration of what the implications of specifying the above proposed behavior would have on gesture dispatch etc in UAs <flackr> https://www.w3.org/groups/cg/touchevents https://www.w3.org/community/touchevents/ Patrick: thank you both, catch you again in two 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, 11 May 2022 15:47:45 UTC