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://
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://
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://
[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.