– DRAFT –
PEWG

Review of "Add new section explaining coalesced and predicted events" https://github.com/w3c/pointerevents/pull/364

Patrick: thanks to all who looked at.

Patrick: did everybody have sufficient time? Rob?

[agree that this could do with another read-through as it's a large change]

Action: review this PR for next meeting, ideally be able to merge it even before then if felt appropriate

Patrick: would like to tackle the other big PR *after* this one is merged as it will need rebasing/merging into

Major refactoring: refer to "direct manipulation" rather than "touch" https://github.com/w3c/pointerevents/pull/350

Olli: is it panning or scrolling

Patrick: panning to me is "scrolling in direct manipulation" scenarios. we have a note somewhere that already says we use the terms interchangeably. my preference would be panning

Olli: but you changed all instances of panning to scrolling in the PR...

Patrick: *blushes* clearly i'm confusing myself. but today my preference is panning. straw poll on people's preference?

[consensus coalesces around "panning"]

Patrick: i'll change the PR to stick to panning (and maybe sneak in extra expansion on where we explain that we treat the terms as synonymous)

<mustaq> https://pr-preview.s3.amazonaws.com/w3c/pointerevents/pull/350.html#glossary

Patrick: do we want to review this now, or do people need more time to review on their own?

Mustaq: would like clarity on the glossary definition. The entry we had for direct manipulation - does this also include mouse or not?

Patrick: yes IF the browser/OS treats the mouse as a direct manipulation device for panning/zooming

Patrick: we'll leave this open again, please review on github. Would like to get this PR merged (like the other big one) before the next meeting in 2 weeks' time (or even earlier if we're happy with it). After that, few more stragglers like that one confusing sentence around "default behaviour", but easier to address AFTER these are merged

[more discussion/question about "is mouse direct manipulation", and the fact that our new/redefined version avoids the topic altogether. touch-action only interested in filtering panning/zooming as a result of a direct manipulation ... not interested in any other concept like drag and drop etc]

Action: review this PR before next meeting, ideally merge this before next meeting

Clarify what the target of the click event should be after capturing pointer events https://github.com/w3c/pointerevents/issues/356

Patrick: Olli already commented on this

Olli: we added some telemetry for this yesterday [in Firefox], no data yet. was something added in Chrome yet?

Mustaq: filed a bug internally, but not worked on it

Olli: if usage is higher than what we expect, we can't change and may have to adopt Chrome's model. otherwise, we could consider opting for this better behavior

Rob: and it shouldn't be difficult to change this. even if we do find explicit capture used often, will be a question of how often do you still get another ancestor handed to the event handler (to see if these scenarios would be affected by a change in behaviour)

Rob: maybe we could instrument that, as that's the only thing that matters - how often people rely on the target

Mustaq: [talks through the test case some more]

Rob: my intuition is that if an author captures on an element, they'll expect events to all go to that event

Olli: think we need some more data

Rob: let's get data and see how risky it is, but inclined to say that we consider the capture target to be the target where the click is going to go

Action: leave open and gather more data, report next meeting

Mustaq: I can collect some data for next time

Patrick: AOB?

Mustaq: I have an issue that came up from changing click to pointer event

Mustaq: we have active state. is "click" still active, or is the pointer not active just before the click is then dispatched

Rob: i think we already have incompatibility with certain implementations

Olli: i would expect if you process mouseup, then you send click in the same process. but yes there can be differences

Mustaq: [asks if it's spec'd anywhere that mouseup and then click should be synchronous]

Olli: i don't think it's specified anywhere, it could be in UI Events

https://w3c.github.io/pointerevents/#the-click-auxclick-and-contextmenu-events

Mustaq: do we care about pressure on click?

Patrick: wouldn't pressure be the pressure of the last known good pointer event, which for pointerup would be close to zero as the finger (etc) is just about to leave the digitizer?

Rob: what would be good would be to have the highest pressure

Patrick: *jokes* coalescedPressure list

Olli: so what would make sense in the click?

Olli: maybe we should just let web authors handle pressure in actual pointer* events and leave click alone

Patrick: my gut feeling is that developer won't want to overload their click handling

[group agrees the click should just keep all things like pressure as the default values, like when a pointer event is generated/initialised]

Patrick: is there any action arising from this discussion? do we need to say anything more in https://w3c.github.io/pointerevents/#the-click-auxclick-and-contextmenu-events

Mustaq: no, don't think so, we can leave it as is

Patrick: i'll have a look, see if maybe we can just make it super-explicit. but otherwise happy to leave as is

Patrick: thank you all, please review PRs for next time, see you again in 2 weeks