15:06:19 <RRSAgent> RRSAgent has joined #pointerevents
15:06:19 <RRSAgent> logging to https://www.w3.org/2021/04/14-pointerevents-irc
15:06:45 <Patrick_H_Lauke> Meeting: PEWG
15:06:49 <Patrick_H_Lauke> Chair: Patrick H. Lauke
15:07:18 <mustaq> present+ Mustaq
15:07:41 <Patrick_H_Lauke> Agenda: https://www.w3.org/events/meetings/9718517d-0e08-4377-bb7c-07332948233b/20210414T110000
15:07:42 <flackr> present+
15:07:58 <Patrick_H_Lauke> Scribe: Patrick H. Lauke
15:08:04 <Patrick_H_Lauke> present+ Patrick_h_Lauke
15:08:09 <Patrick_H_Lauke> present+ smaug
15:08:13 <Patrick_H_Lauke> present+ mustaq
15:08:37 <Patrick_H_Lauke> Topic: Major refactoring: refer to "direct manipulation" rather than "touch" https://github.com/w3c/pointerevents/pull/350
15:18:08 <Patrick_H_Lauke> Patrick: [catching up Rob Flack who just joined on the background around touch-action and historically why we talk about direct manipulation]
15:18:41 <Patrick_H_Lauke> flackr: wondering why we explicitly say that this does NOT apply to mouse-based direct manipulation
15:21:13 <mustaq> https://github.com/w3c/pointerevents/issues/203
15:22:34 <Patrick_H_Lauke> 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"]
15:28:56 <Patrick_H_Lauke> Action: review the PR for next meeting in 2 weeks' time
15:29:15 <Patrick_H_Lauke> Topic: Click event while a pointer event is captured https://github.com/w3c/pointerevents/issues/75
15:33:13 <Patrick_H_Lauke> mustaq: I think we agreed to close this issue as we now have the other issues that cover the more specific aspects
15:33:43 <Patrick_H_Lauke> 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
15:33:48 <Patrick_H_Lauke> Action: close the issue
15:33:58 <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:37:30 <Patrick_H_Lauke> Patrick: is anything actionable here? do we need to reach out to webkit folks? thinking @smfr perhaps
15:38:17 <Patrick_H_Lauke> 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
15:38:41 <Patrick_H_Lauke> flackr: common ancestor historically makes sense, but capture makes this trickier
15:39:34 <Patrick_H_Lauke> 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
15:40:41 <Patrick_H_Lauke> flackr: thinking of use cases. thinking of dragging, it might be nice to get it at the point of where you originally captured it
15:42:33 <Patrick_H_Lauke> 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
15:43:20 <Patrick_H_Lauke> flickr: or we could go down the route of "clicks aren't affected by capture"
15:43:42 <Patrick_H_Lauke> Olli: in chromium click is kind of affected by capture, but comes down to initial down
15:43:45 <Patrick_H_Lauke> mustaq: pre-capture
15:44:25 <Patrick_H_Lauke> 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
15:44:33 <Patrick_H_Lauke> flackr: coming around to this as well
15:44:39 <Patrick_H_Lauke> Olli: but nobody is implementing that
15:45:17 <Patrick_H_Lauke> flackr: other question is how fungible this behaviour is, can it be changed. it's already inconsistent now...
15:45:27 <Patrick_H_Lauke> Olli: gecko has no telemetry data
15:46:05 <flackr> https://chromestatus.com/metrics/feature/timeline/popularity/1431
15:47:17 <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
15:47:52 <Patrick_H_Lauke> Patrick: question if this includes implicit capture, as this looks very high percentage wise
15:48:09 <Patrick_H_Lauke> flackr: looks like it does, so we need to change this to only look for explicit capture to be more representative
15:49:53 <Patrick_H_Lauke> Patrick: so next steps, should we see if we can write some rationale in the github issue and then pull in some webkit folks?
15:50:10 <Patrick_H_Lauke> [general agreement to start jotting down some thoughts]
15:50:24 <Patrick_H_Lauke> mustaq: and we should look at changing metric measurement
15:51:03 <Patrick_H_Lauke> 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
15:51:34 <Patrick_H_Lauke> Topic: Clarify when lostpointercapture should fire https://github.com/w3c/pointerevents/issues/357
15:51:57 <Patrick_H_Lauke> Olli: this also depends on our philosophical take from 356, they're interrelated
15:52:30 <Patrick_H_Lauke> Action: leave open for now waiting for outcome of 356
15:54:35 <mustaq> https://github.com/w3c/pointerevents/issues/100
16:01:35 <Patrick_H_Lauke> [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
16:01:35 <Patrick_H_Lauke> haviours and hacks authors had to implement in the past]
16:02:02 <Patrick_H_Lauke> Patrick: thank you for joining the meeting. watch the github issues, and we meet again in 2 weeks' time.
16:02:43 <Patrick_H_Lauke> rrsagent, set logs world-visible
16:02:55 <Patrick_H_Lauke> rrsagent, publish minutes
16:02:55 <RRSAgent> I have made the request to generate https://www.w3.org/2021/04/14-pointerevents-minutes.html Patrick_H_Lauke
16:03:45 <Patrick_H_Lauke> rrsagent, bye
16:03:45 <RRSAgent> I see 4 open action items saved in https://www.w3.org/2021/04/14-pointerevents-actions.rdf :
16:03:45 <RRSAgent> ACTION: review the PR for next meeting in 2 weeks' time [1]
16:03:45 <RRSAgent>   recorded in https://www.w3.org/2021/04/14-pointerevents-irc#T15-28-56
16:03:45 <RRSAgent> ACTION: close the issue [2]
16:03:45 <RRSAgent>   recorded in https://www.w3.org/2021/04/14-pointerevents-irc#T15-33-48
16:03:45 <RRSAgent> 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 [3]
16:03:45 <RRSAgent>   recorded in https://www.w3.org/2021/04/14-pointerevents-irc#T15-51-03
16:03:45 <RRSAgent> ACTION: leave open for now waiting for outcome of 356 [4]
16:03:45 <RRSAgent>   recorded in https://www.w3.org/2021/04/14-pointerevents-irc#T15-52-30