- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Wed, 28 Sep 2022 16:50:07 +0100
- To: Pointer Events Working Group <public-pointer-events@w3.org>
Dear all, the minutes from today's meeting are at https://www.w3.org/2022/09/28-pointerevents-minutes.html and copied below. PEWG 28 September 2022 Agenda: https://www.w3.org/events/meetings/0d3af70c-0054-43dc-9c15-c60c5b9c3f3c/20220928T110000 Attendees Present: flackr, mustaq, Patrick_H_Lauke Regrets: smaug Chair: Patrick H. Lauke Scribe: Patrick H. Lauke, Patrick_H_Lauke * Order of pointerover/enter/move and corresponding mouse events is different on browsers https://github.com/w3c/pointerevents/issues/454 * Heartbeat: Clarify what the target of the click event should be after capturing pointer events https://github.com/w3c/pointerevents/issues/356 * WPT https://github.com/w3c/pointerevents/issues/445 Apologies, running a few minutes late. will be with you shortly I'm getting a "Too many redirects" error trying to get to the details for joining the meeting... # Order of pointerover/enter/move and corresponding mouse events is different on browsers https://github.com/w3c/pointerevents/issues/454 mustaq: created an animation that hopefully clarifies the situation patrick: I can take it as a starting point and jazz it up patrick: did we want to add it to a specific section? mustaq: 11.1 flackr: do we also want to call out events that are being fired? mustaq: i could add a log of events at the side, or that might be too confusing flackr: yes, might be confusing, and i do like the simplicity we have in the animation mustaq: i explicitly wanted it b/w except for the legacy pointer in gray as that's the point we're making flackr: i like the click on the mouse flackr: legacy pointer should move on touch up, not down [discussion on when exactly the legacy pointer moves ... on touch down, or when a tiny drag happens] patrick: i might be getting confused with touch events, but certainly fallback mouse events are not sent if it's a "dirty" tap with too much movement <mustaq> https://rbyers.github.io/eventTest.html <mustaq> I am using touch emu on this page to see this. patrick: just testing on https://patrickhlauke.github.io/touch/tests/event-listener.html it only fires legacy mouse events after the up mustaq: 11.3 says unless it's cancelled in pointerdown, it should fire mousedown right away patrick: look at the extra sentence after the numbered list: "If the user agent supports both Touch Events (as defined in [TOUCH-EVENTS]) and Pointer Events, the user agent MUST NOT generate both the compatibility mouse events as described in this section, and the fallback mouse events outlined in [TOUCH-EVENTS]." patrick: so what chrome is doing is NOT doing both, but actually ONLY firing the fallback mouse events outlined in touch events (which only happen on the UP) mustaq: assume we DIDN'T support touch events, would it not make sense to interleave as defined in 11.3? flackr: problems with contextmenu firing - mousedown often dows destructive state changes which would break contextmenu other interactions like drag-and-drop would be broken even things like touch scrolling could be broken at times if events were interleaved even for the pointerdown patrick: the interleaving does make sense, IF the author explicitly set touch-action:none, as they opted out of gesture handling patrick: this might even apply to mouse/devices that hover. so we could add some qualifier to both of these saying that the interleaving happens in theory, but ONLY if the user agent is not doing gesture processing / higher level gesture processing, which authors CAN opt out of using touch-action (misnomer as not just for touch) mustaq: so for the animation, i can make a quick tap, and on the up the legacy mouse pointer jumps flackr: touch-action does imply gesture handling which does imply interleaving may not happen patrick: i can try to make a PR that explains all of this stuff ("the spec is philosophically pure and does interleaving, but in practice gesture handling etc gets in the way unless author opts out") mustaq: [checks if all this answers the original question of isse #454] <Github> https://github.com/w3c/pointerevents/issues/454 : Order of pointerover/enter/move and corresponding mouse events is different on browsers ACTION: patrick to create issue that explains nuance of interleaving in theory vs practice, patrick to recreate animation done by mustaq for inclusion in 11.3 flackr: do we need to also change the numbered steps, to make it clear that touch-action has an influence? mustaq: i'd make that a separate issue though flackr: 11.3 should only suggest interleaving if no touch-action is affecting it # Heartbeat: Clarify what the target of the click event should be after capturing pointer events https://github.com/w3c/pointerevents/issues/356 mustaq: started fixing chrome, but it's going to take time flackr: it is a web-facing change. touch one is going to be more complicated to implement technically as well # WPT https://github.com/w3c/pointerevents/issues/445 going through the old PRs https://github.com/w3c/pointerevents/pulls?q=is%3Apr+is%3Aclosed+label%3Awpt and removing label wpt once confirmed that it DOES have a test (or doesn't need a test/can't be tested) so then whatever's left over with wpt label still intact needs a test, and we can tackle that later ACTION: go through list of closed/merged PRs with wpt to confirm/check if there's a test (in which case remove label)/if it needs a test thanks all -- 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 September 2022 15:50:20 UTC