Minutes from Pointer Events WG call 28 April 2021

Dear all,

minutes from today's call are at in order to end the stream of events 
for the pointer and copied below:

PEWG 28 April 2021 

flackr, mustaq, Patrick_H_Lauke, smaug
Patrick H. Lauke


* Review of "Add new section explaining coalesced and predicted events" 
* Major refactoring: refer to "direct manipulation" rather than "touch" 
* Clarify what the target of the click event should be after capturing 
pointer events https://github.com/w3c/pointerevents/issues/356

Meeting minutes
Review of "Add new section explaining coalesced and predicted events" 
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" 
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)


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


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 

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

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, 28 April 2021 16:30:01 UTC