– DRAFT –
PEWG

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