– DRAFT –
PEWG

Order of pointerover/enter/move and corresponding mouse events is different on browsers https://github.com/w3c/pointerevents/issues/454

Patrick: we have two pull requests for this https://github.com/w3c/pointerevents/pull/459

Patrick: and https://github.com/w3c/pointerevents/pull/458

<mustaq> https://mustaqahmed.github.io/web/pe-legacy-pointer-animation/legacy-pointer-animation.html

https://pr-preview.s3.amazonaws.com/mustaqahmed/pointerevents/pull/458.html#tracking-the-effective-position-of-the-legacy-mouse-pointer

[discussion on the changes in PR 458]

Mustaq: after the call, i'll shorten the caption. other than that i think Patrick's changes are great, but Olli please add any more comments

Patrick: I'm planning to tweak the webm itself to also show the actual events being fired, but for now it's good enough

Mustaq: one question about adding events, how to distinguish which pointer they relate to

Patrick: I'd say just list the mouse events for the idealised/faked legacy mouse pointer, as that's what we care about - show how it enters/leaves the two buttons even though nothing really MOVED between them

Patrick: what about the other PR https://github.com/w3c/pointerevents/pull/459

Mustaq: I think the core note is good, but give me some time to check if the second sentence needs to be tweaked to make it even clearer

Patrick: wonder if this note could also use an extra para about "authors should not mix and match between pointer events and mouse events"

Mustaq: could make it normative?

<mustaq> Like normative "recommend against mix-and-match"

Patrick: as spec is aimed primarily at UA devs, not authors, i'm not sure we can MANDATE what authors do. but we can make strong recommendation

Patrick: i'll have a think about the extra recommendation, and mustaq feel free to comment with changes to second sentence

ACTION: Patrick and Mustaq to tweak PR 459 further

ACTION: Mustaq to make first stab at new webm showing orange mouse events being dispatched for #458

<Github> https://github.com/w3c/pointerevents/pull/458 : Add a note and diagram to clarify legacy mouse pointer behavior.

pointerout even if the pointer doesn't move? https://github.com/w3c/pointerevents/issues/457

PAtrick: there was an action ACTION: add WPT that reflects both Safari and Firefox, investigate reason for Chrome's behaviour

Mustaq: i might not have mentioned, but plan to address this as part of Interop 2022. please assign to me, looks like chrome bug

ACTION: Mustaq to review/action #457

<Github> https://github.com/w3c/pointerevents/issues/457 : pointerout even if the pointer doesn't move?

Meta-issue: update WPT to cover Pointer Events Level 3 https://github.com/w3c/pointerevents/issues/445

https://github.com/w3c/pointerevents/issues?page=1&q=is%3Aclosed+label%3Awpt

<smaug> https://searchfox.org/mozilla-central/search?q=&path=testing%2Fweb-platform%2Ftests%2Fpointerevents&case=false&regexp=false

Olli: maybe easiest might to search in the above url

Patrick: I was looking briefly over this https://github.com/web-platform-tests/wpt/tree/master/pointerevents but there's probably better

Mustaq: I was looking at #456 and was about to remove the wpt tag, but then realised the test we have doesn't fully cover this

<Github> https://github.com/w3c/pointerevents/pull/456 : Fix stale text around click, auxclick and contextmenu events

[discussion on how to best handle notes about whether or not WPTs are there, or if they're incomplete]

Patrick: so we'll note in the pull request itself whether a test exists (as part of then removing the WPT label), or add a comment of incomplete/missing tests (and leave the WPT label intact)

Heartbeat: Clarify what the target of the click event should be after capturing pointer events https://github.com/w3c/pointerevents/issues/356

ACTION: everybody review the WPT labelled PRs and note/comment where tests are present (and remove WPT label), or if they're incomplete/missing

Olli: I don't think that (#356) is part of the Interop effort

<Github> https://github.com/w3c/pointerevents/issues/356 : Clarify what the target of the click event should be after capturing pointer events

Mustaq: we need to evaluate this still before proceeding

Patrick: looking over any other open/outstanding issues https://github.com/w3c/pointerevents/issues?q=is%3Aissue+is%3Aopen+label%3Av3

Mustaq: if you want to work on something on the interop list, just add your name to it...

<smaug> https://docs.google.com/spreadsheets/d/1K3lnen0hP0T3z7lDmUnTtTrA-qWJ5JVTvkuvhV8AQhY/edit#gid=0

<mustaq> PE Interop list is here:

<mustaq> https://docs.google.com/spreadsheets/d/1K3lnen0hP0T3z7lDmUnTtTrA-qWJ5JVTvkuvhV8AQhY/edit#gid=0

Patrick: only other issue i can see is https://github.com/w3c/pointerevents/issues/357

Patrick: which we said we'll park until 356 is addressed

Patrick: we may need to defer #356 and #357 for future version, if they take too long to investigate/come to an agreement

<Github> https://github.com/w3c/pointerevents/issues/356 : Clarify what the target of the click event should be after capturing pointer events

<Github> https://github.com/w3c/pointerevents/issues/357 : Clarify when lostpointercapture should fire

Patrick: not seeing any other major issues marked as v3 otherwise, and all other issues in issue tracker are marked as future, so we're in good shape. thank you both. let's iterate over the two open PRs a bit more, and the WPT list, and meet again in two weeks' time