14:56:53 <RRSAgent> RRSAgent has joined #pointerevents
14:56:53 <RRSAgent> logging to https://www.w3.org/2022/05/11-pointerevents-irc
14:58:02 <Patrick_H_Lauke> Meeting: PEWG
14:58:07 <Patrick_H_Lauke> Chair: Patrick H. Lauke
14:58:09 <Patrick_H_Lauke> Agenda: https://www.w3.org/events/meetings/0d3af70c-0054-43dc-9c15-c60c5b9c3f3c/20220511T110000
14:58:14 <Patrick_H_Lauke> Scribe: Patrick H. Lauke
14:58:22 <Patrick_H_Lauke> ScribeNick: Patrick_H_Lauke
14:58:31 <Patrick_H_Lauke> present+ Patrick_H_Lauke
14:59:07 <Patrick_H_Lauke> regrets+ smaug
15:00:45 <flackr> flackr has joined #pointerevents
15:02:59 <Patrick_H_Lauke> present+ flackr
15:03:19 <Patrick_H_Lauke> TOPIC: Relationship between main pointer event and coalesced events https://github.com/w3c/pointerevents/issues/409
15:03:59 <Patrick_H_Lauke> Rob: had very initial pass trying to specify this
15:04:35 <Patrick_H_Lauke> https://github.com/w3c/pointerevents/pull/440
15:05:56 <Patrick_H_Lauke> present+ mustaq
15:06:30 <Patrick_H_Lauke> 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
15:08:25 <Patrick_H_Lauke> Rob: intention to explain that it's not necessarily identical to the set of coalesced events
15:09:04 <Patrick_H_Lauke> 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)
15:09:18 <Patrick_H_Lauke> Mustaq: wondering if there's an alternative to "frame"
15:09:26 <Patrick_H_Lauke> Rob: could say "align to display"
15:09:31 <Patrick_H_Lauke> Mustaq: refresh rate?
15:10:01 <Patrick_H_Lauke> Rob: not the best either. could be super vague "align with the hardware..."
15:10:34 <Patrick_H_Lauke> Mustaq: ...to align with frame refresh timing... to align with frame timing ...
15:10:50 <Patrick_H_Lauke> Rob: frame timing has specific meaning, there's a specific frame timing spec
15:12:03 <Patrick_H_Lauke> Rob: we could have "but may have additional processing (for example, to align with the display refresh rate)"
15:12:09 <Patrick_H_Lauke> Patrick: yes I could go for this
15:12:31 <Patrick_H_Lauke> Rob: we don't want to specify all cases, just give examples. happy to modify the PR with that
15:13:10 <Patrick_H_Lauke> Patrick: great, I'll point Olli to this, and we can either approve whenever he oks this or at the next meeting
15:13:37 <Patrick_H_Lauke> ACTION: Olli to review https://github.com/w3c/pointerevents/pull/440/ and see if it's ok
15:16:35 <Patrick_H_Lauke> TOPIC: Clarify what the target of the click event should be after capturing pointer events https://github.com/w3c/pointerevents/issues/356
15:16:56 <Patrick_H_Lauke> Patrick: action was "Mustaq to propose some more fleshed out wording"
15:17:46 <mustaq> https://github.com/w3c/pointerevents/issues/356#issuecomment-1064765460
15:18:18 <mustaq> I kind of agree here that about not expecting/interpreting "click" on drag.
15:19:28 <Patrick_H_Lauke> Mustaq: not arguing about sending click or not, but about the target
15:19:49 <Patrick_H_Lauke> Mustaq: my interpretation is that we don't need to worry about click dispatch after release on a drag
15:20:06 <Patrick_H_Lauke> Rob: but this is asking to get click on the captured element, final line
15:20:33 <Patrick_H_Lauke> Rob: I think they agree with my proposed behavior that click is captured
15:21:03 <Patrick_H_Lauke> [looking at the two opposite requests in the comments]
15:22:04 <Patrick_H_Lauke> Rob: think we agreed in last meeting ... what Olli said in https://github.com/w3c/pointerevents/issues/356#issuecomment-1111142169
15:22:14 <Patrick_H_Lauke> Mustaq: so fire releasePointerCapture after click?
15:22:15 <Patrick_H_Lauke> Rob: yes
15:24:08 <Patrick_H_Lauke> 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
15:24:30 <Patrick_H_Lauke> Rob: really just question of implementations deferring the release of pointercapture until we decide if click is generated or not
15:25:00 <Patrick_H_Lauke> Mustaq: what if it's double-tap?
15:26:15 <Patrick_H_Lauke> [discussion on whether you'd be even able to get double-tap, pointercapture, UA deciding if click needs sending]
15:27:27 <Patrick_H_Lauke> 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 (?)
15:27:59 <Patrick_H_Lauke> Mustaq: some timing challenges
15:28:09 <Patrick_H_Lauke> Rob: think there's a consistent stream of events that can be sent
15:31:49 <Patrick_H_Lauke> ACTION: further exploration of what the implications of specifying the above proposed behavior would have on gesture dispatch etc in UAs
15:34:38 <flackr> https://www.w3.org/groups/cg/touchevents
15:34:41 <Patrick_H_Lauke> https://www.w3.org/community/touchevents/
15:40:43 <Patrick_H_Lauke> Patrick: thank you both, catch you again in two weeks' time
15:40:51 <Patrick_H_Lauke> rrsagent, set logs world-visible
15:40:57 <Patrick_H_Lauke> rrsagent, generate minutes
15:40:57 <RRSAgent> I have made the request to generate https://www.w3.org/2022/05/11-pointerevents-minutes.html Patrick_H_Lauke
15:41:03 <Patrick_H_Lauke> rrsagent, set logs world-visible
16:28:24 <Patrick_H_Lauke> Patrick_H_Lauke has left #pointerevents