- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Wed, 28 Apr 2021 17:29:45 +0100
- To: public-pointer-events@w3.org
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 Attendees Present flackr, mustaq, Patrick_H_Lauke, smaug Regrets - Chair Patrick H. Lauke Scribe Patrick_H_Lauke Contents * Review of "Add new section explaining coalesced and predicted events" https://github.com/w3c/pointerevents/pull/364 * Major refactoring: refer to "direct manipulation" rather than "touch" https://github.com/w3c/pointerevents/pull/350 * 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" https://github.com/w3c/pointerevents/pull/364 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" https://github.com/w3c/pointerevents/pull/350 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) <mustaq> https://pr-preview.s3.amazonaws.com/w3c/pointerevents/pull/350.html#glossary 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 https://w3c.github.io/pointerevents/#the-click-auxclick-and-contextmenu-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 https://w3c.github.io/pointerevents/#the-click-auxclick-and-contextmenu-events 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