Minutes from PEWG meeting 24 April 2024

Dear all,

the minutes from today's relatively short meeting are available at 
https://www.w3.org/2024/04/24-pointerevents-minutes.html and copied below:

24 April 2024

IRC log: https://www.w3.org/2024/04/24-pointerevents-irc

flackr, mustaq, Patrick_H_Lauke, plh



Chair: Patrick H. Lauke
Scribe: Patrick H. Lauke

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

* Meta-issue: update WPT to cover Pointer Events Level 3 #445 

* Wide review requests

# 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 

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


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 

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

Patrick H. Lauke

* https://www.splintered.co.uk/
* https://github.com/patrickhlauke
* https://flickr.com/photos/redux/
* https://mastodon.social/@patrick_h_lauke

Received on Wednesday, 24 April 2024 15:29:55 UTC