– DRAFT –
PEWG

regrets smaug

Multi-pen support and persistent pointerId #353 w3c/pointerevents#353

<flackr> w3c/pointerevents#495

Mustaq: commented on the PR about reporting -1 before EVERY pointerdown...

Rob: yes, wasn't sure it was clear in the spec

Rob: can continue iterating on the PR to make sure things are clear to authors, I think Olli asked for the same

ACTION: continue iterating over the draft PR

Meta-issue: update WPT to cover Pointer Events Level 3 #445 w3c/pointerevents#445

Patrick: last time we discussed possibility to make manual tests for things like predicted events based on demos

Rob: yes, Olli said he'd look at some of this, as there's no WPT support yet

Mustaq: I also looked at some of these, I think I assigned this (494) to me

<mustaq> w3c/pointerevents#494

ACTION: continue work on these

Wide review requests

Patrick: I have admittedly been slack with some of these w3c/pointerevents#482 but I have now sent an explicit wide review request (on top of the automated one that went out) to DAS, Touch Events, WebApps. Will do Security and Privacy after this call

PLH: question about w3c/pointerevents#494 - it looks like you're monkeypatching, not following UI events algorithm fully

PLH: in recent years we've tried to move away from monkeypatching - changing another spec. we'd ideally ask the original spec to add another step, then refer back from that original spec to our spec

Mustaq: blocker here is that UI events spec is not algorithmic yet. we can't follow the proper steps

Rob: two issues. i don't even recall where UI events defines target of event. we've defined a higher level. UI events says the target comes from the mouse events, but because our spec sits higher than mouse events, it should come from pointerdown (?)

Rob: but there's no functional difference in the end

PLH: looking where UI events defines event target...

<mustaq> https://w3c.github.io/uievents/#events-mouseevent-event-order

<flackr> https://w3c.github.io/uievents/#events-mouseevent-event-order:~:text=SHOULD%20fire%20click%20and%20dblclick%20events%20on%20the%20nearest%20common%20inclusive%20ancestor%20when%20the%20associated%20mousedown%20and%20mouseup%20event%20targets

PLH: worth adding an issue against UI events making them aware that we're adding an extra step. if it was WHATWG HTML we'd ask for a hook

Rob: the other oddity here is possibly capture...though it shouldn't, as up is still sent to capture target

Rob: agree it's a bit of a patch, as it tries to explain how pointer events "come first" at a higher level

Patrick: so should we file an issue against UI events about this?

Rob: yes we should, also the fact that node removal isn't explained fully - how node removal affects the targets of things still attached

Mustaq: found Gary's pull request....

<mustaq> This is a proposed PR to make UI event dispatch "more algorithmic": w3c/pointerevents#285 (comment)

Mustaq: not an official PR, but a separate copy to make this more algorithmic

PLH: would be good if we could have an issue in UI events to track that, and fine to point back to Gary's comment on that

ACTION: Mustaq to file issues in UI events for making algorithmic and node removal