– DRAFT –
PEWG

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