Meeting minutes
Meta-issue: update WPT to cover Pointer Events Level 3 w3c/pointerevents#445
Go over https://
Olli: wonder how we can get through all these tests
Mustaq: was hoping to do more, but not had time
Patrick: I'll see if i can get env set up for testing at my end, but should we rope in extra help?
Olli: I'll see if I can get Edgar (?) to help
Mustaq: same here
Heartbeat: Clarify what the target of the click event should be after capturing pointer events w3c/pointerevents#356
Patrick: did some testing with the latest codepen
w3c/
Patrick: only tested with `touch-action` and explicit release. Can rerun/document tests also with the explicit release disabled
[discussion on whether we should also test all other iterations]
Mustaq: originally, we didn't have implicit capture/implicit release, but we convinced Microsoft at the time that we'd do implicit capture for touch, but releasing would be same for all pointer types (?)
Rob: if devs use pointer capture, they can rely on implicit release, or do it themselves explicitly
Mustaq: if implicit release is different from explicit release, then that's a problem/bug
ACTION: do more testing with explicit capture off and document results
<flackr> https://
<flackr> "If the user agent supports firing the click or auxclick event, and if in an implicit release scenario both that (click or auxclick) event and a lostpointercapture event are fired, the click or auxclick event SHOULD be fired before lostpointercapture."
Rob: this is what led me to believe that explicit release is different from implicit release. if you think they should be the same, then we should remove that
Olli: didn't i file a spec issue that said the opposite of this? the order was unclear
<smaug> w3c/
Mustaq: calling release doesn't immediately release, so there may be some leeway
Rob: but we'd still expect the click to be captured
Rob: but that does affect what i'd expect the outcome to be. until lostpointercapture, i'd expect the click to be captured
Mustaq: it's because of the async nature
Rob: we should either consistently delay pointer capture before, or after. not having click dispatched sync or async and get different results
Rob: behaviour i was pushing for is changing touch behaviour so we don't use the pointer capture until after click is dispatched
Mustaq: for touch, we also have pointerleave and pointerout. which then also trigger the capture release. if we make click sync, these will also need to be addressed
Rob: naive thing would be to delay out and leave if you have delayed clicks, which doesn't seem crazy but is a pretty big change, perhaps argument in favour of losing pointer capture before the click...
Mustaq: looking for section about pending pointer capture
Patrick: https://
Mustaq: "The user agent MUST run..." so this includes out and leave
Rob: and click
Mustaq: but this was done before click
Rob: so spec is contradicting itself
Patrick: Rob do you want to file an issue on this?
Olli: my issue is about this w3c/
Rob: one question is: simplest change would be release pointer capture after pointer up. then click goes to common ancestor of common ancestor and the down event
Rob: we did some compat evaluation for this at some point?
Mustaq: not for this one
Rob: less worried about order than the target
Mustaq: compat could also be deciding factor
Rob: what would happen if we lost pointer capture before click and fired click at the ancestor
Rob: how many pages would this affect, or something to that effect
Mustaq: could you add this as a comment to the issue (https://
Olli: maybe safari on desktop is the simplest
Olli: for cases 3 and 4
Patrick: it's doing what Rob is suggesting, firing click to ancestor after capture lost
Rob: but then row 2 is weird, firing click to green
Olli: ... then there's also the weirdness for devs who do capture and then assume that means they'll also get the click
Rob: that would assume changing how capture works to wait for click as well, the other way of solving this
Mustaq: ... we could say even though point is lost, click still goes to the element where the pointerup happened
Rob: ergonomically, this is more useful for devs, but would rather do something that's more generally useful even though harder to spec
Mustaq: we should definitely check on compat
Rob: we could see how often target gets changed
Mustaq: I think we DID test that aspect, we added a counter....
Mustaq: had planned to add a test in canary, but we didn't get to that point
Mustaq: the bug mentions a counter, but we didn't post the result back
[checking if counter is still there or expired]
<flackr> https://
Rob: even if target changes, doesn't tell us if page breaks
Mustaq: what's next step then? I think we should report this upper bound in the issue
Rob: I left it in IRC/notes
Rob: I do notice - I don't think this counter cares if there's a click handler or not. so would be possible to try to get a better estimate / lower upper bound of when there ARE click handlers for the old/new target
Olli: and you'd have to check if there's elements like anchors
Mustaq: Rob for now I'll reopen the issue for this counter in case we need to fine-tune this one, WDYT
Rob: risk is unknown, we have an upper bound, we might try to launch something with caveat that if we see significant breakage we pull back
Mustaq: let's continue this outside of the meeting
ACTION: Rob/Mustaq to investigate further about counter/test to get more data to make decision
TPAC
Patrick: so the dates/times that were available are
> Monday 11 September: 09:30 - 11:00
> Monday 11 September: 11:30 - 13:00
> Monday 11 September: 17:00 - 18:30
> Tuesday 12 September: 09:30 - 11:00
> Tuesday 12 September: 11:30 - 13:00
> Tuesday 12 September: 17:00 - 18:30
> Thursday 14 September: 09:30 - 11:00
> Thursday 14 September: 11:30 - 13:00
> Thursday 14 September: 17:00 - 18:30
> Friday 15 September: 09:30 - 11:00
> Friday 15 September: 11:30 - 13:00
> Friday 15 September: 17:00 - 18:30
[discussion on which date/time would preliminarily work]
Patrick: so I'll put us down for thursday 14 September 17:00-18:30, we can always change it (within reason) on an ad-hoc basis as it's just the four of us
ACTION: complete TPAC session form