(belated) Minutes from Pointer Events WG call 14 April 2021

Apologies, realised that I completely missed out sending these minutes 
to the list. Available on 
https://www.w3.org/2021/04/14-pointerevents-minutes.html and copied below:

PEWG 14 April 2021 

Attendees
Present
flackr, mustaq, Patrick_h_Lauke, smaug
Regrets
-
Chair
Patrick H. Lauke
Scribe
Patrick H. Lauke, Patrick_H_Lauke

Contents

* Major refactoring: refer to "direct manipulation" rather than "touch" 
https://github.com/w3c/pointerevents/pull/350
* Click event while a pointer event is captured 
https://github.com/w3c/pointerevents/issues/75
* Clarify what the target of the click event should be after capturing 
pointer events https://github.com/w3c/pointerevents/issues/356
* Clarify when lostpointercapture should fire 
https://github.com/w3c/pointerevents/issues/357

Meeting minutes

Major refactoring: refer to "direct manipulation" rather than "touch" 
https://github.com/w3c/pointerevents/pull/350
Patrick: [catching up Rob Flack who just joined on the background around 
touch-action and historically why we talk about direct manipulation]

flackr: wondering why we explicitly say that this does NOT apply to 
mouse-based direct manipulation

<mustaq> https://github.com/w3c/pointerevents/issues/203

Patrick: [gives summary: spec does not define what user agent should do 
with mouse etc, whether it SHOULD treat a mouse as a direct manipulation 
device or not...spec tries to instead leave that up to the user 
agent/OS, and touch-action just says "if you CHOOSE to make this input a 
direct manipulation device that by default scrolls or zooms, THEN you 
need to take heed of the touch-action values"]

ACTION: review the PR for next meeting in 2 weeks' time

Click event while a pointer event is captured 
https://github.com/w3c/pointerevents/issues/75
mustaq: I think we agreed to close this issue as we now have the other 
issues that cover the more specific aspects

Patrick: agreed. let me close it and mark as superseded - we can always 
revisit this later if we find there was some aspect not covered by 356 
and 357

ACTION: close the issue

Clarify what the target of the click event should be after capturing 
pointer events https://github.com/w3c/pointerevents/issues/356
Patrick: is anything actionable here? do we need to reach out to webkit 
folks? thinking @smfr perhaps

Patrick: the problem here is that there's perhaps no absolutely RIGHT 
behaviour, they all have their merit/logic. it's a case of deciding on 
the least worst, and sticking to it consistently across UAs

flackr: common ancestor historically makes sense, but capture makes this 
trickier

Olli: depends on how we think of the capturing ... is it the ancestor of 
where you now released, or is it the ancestor of the element that 
originally captured

flackr: thinking of use cases. thinking of dragging, it might be nice to 
get it at the point of where you originally captured it

flackr: we should have a position/explanation of the various 
philosophical reasons why one approach makes sense in a certain use case 
vs another behaviour. we should try and explain why developers would 
want/expect one

flickr: or we could go down the route of "clicks aren't affected by capture"

Olli: in chromium click is kind of affected by capture, but comes down 
to initial down

mustaq: pre-capture

Olli: think i would prefer target of the pointer capture to get the 
click, but maybe we don't want to change behaviour. but that might be 
most logical/useful

flackr: coming around to this as well

Olli: but nobody is implementing that

flackr: other question is how fungible this behaviour is, can it be 
changed. it's already inconsistent now...

Olli: gecko has no telemetry data

<flackr> https://chromestatus.com/metrics/feature/timeline/popularity/1431

<mustaq> 
https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/core/input/pointer_event_manager.cc;l=1011?q=pointereventsetcapture%20-file:%2Fgen%2F

Patrick: question if this includes implicit capture, as this looks very 
high percentage wise

flackr: looks like it does, so we need to change this to only look for 
explicit capture to be more representative

Patrick: so next steps, should we see if we can write some rationale in 
the github issue and then pull in some webkit folks?

[general agreement to start jotting down some thoughts]

mustaq: and we should look at changing metric measurement

ACTION: continue conversation on issue, writing some 
easier-to-understand "this is why this approach makes sense in this 
situation" ideas, and seeing if we can get webkit folks to look over 
this/contribute

Clarify when lostpointercapture should fire 
https://github.com/w3c/pointerevents/issues/357
Olli: this also depends on our philosophical take from 356, they're 
interrelated

ACTION: leave open for now waiting for outcome of 356

<mustaq> https://github.com/w3c/pointerevents/issues/100

[brief discussion on the issues authors face/tried to solve themselves 
in handling mouse "as if it was a direct manipulation device" for those 
cases - drag and drop, panning a map, etc - and not having click come 
out at the end, Olli mentioned how mouse behaviour changed, Patrick 
mentioning how these behaviours were never spec'd at the time and just 
browser heuristics and how we NOW try to spec stuff and are hitting 
these weird be

haviours and hacks authors had to implement in the past]

Patrick: thank you for joining the meeting. watch the github issues, and 
we meet again in 2 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, 28 April 2021 17:04:38 UTC