- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Wed, 28 Apr 2021 18:04:23 +0100
- To: public-pointer-events@w3.org
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