W3C

– DRAFT –
PEWG

16 July 2025

Attendees

Present
flackr, mustaq, Patrick_H_Lauke
Regrets
-
Chair
Patrick H. Lauke
Scribe
Patrick_H_Lauke, Patrick H. Lauke

Meeting minutes

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

Patrick: w3c/pointerevents#445 / https://github.com/w3c/pointerevents/issues?q=label%3Aneeds-wpt+

Looks like we've got none left...

last one we had was w3c/pointerevents#509 which seems to have been resolved now

So unless there's anything else that was missed out that we think desperately needs a wpt, think we're in a good spot

So at this stage, it would be good in our respective browser implementations if we could go through the WPTs that are now complete, and see how we're doing

And if things fail, working out if it's features/bugs that are planned to be addressed or not

Next step I think was for Philippe (plh) to collate things based on the WPTs for implementation report

ACTION: review the WPT results at this stage, investigate any failures

Any particular old or new issues that we want to start thinking about/tackling?

<mustaq> w3c/pointerevents#507

mustaq: I would love to close out w3c/pointerevents#507 ... but we'd need somebody from Firefox to check in, but feel free to comment on the issue

We have 32 issues at this stage (just closed w3c/pointerevents#445 as we've sorted WPTs)

<mustaq> w3c/pointerevents#542

[mustaq explains what the intention is with drifting clicks]

Patrick: what i do hate, if this is the same: say you have a dialog, inside it there's a text field; i highlight the content by dragging my mouse, but accidentally end up finishing just outside of the dialog, and it auto-closes. i didn't intend that...

mustaq: we don't have that problem for touch, as a click is not sent when there's movement

Rob: i'm not sure i'm a fan of the thinking that click should be sent for drifting pointer - as on touch it's the way for a user to change their mind

Rob: maybe if we found a way of declaring/stating that there is a boundary, so if you stay within it it still counts as click, but otherwise don't fire click

Rob: something to say this is a clickable thing

Rob: "click boundary" as a strawman term

mustaq: might have something we can do with target...

mustaq: maybe we can do something where drifting click can work for mouse, but leave touch as is

Rob: we also have implicit capture, that brings up difference between mouse click and touch click

Rob: not sure what Joey's expectation is specifically, might need to dig in a bit more

Patrick: to be clear, that problem I have been seeing is usually in a JavaScript-y implementation, not the current native <dialog>

Patrick: if we want to explore more dramatic changes (like making touch click work more like mouse click), we can start that conversation if we're aiming that for PE Level 4 - gives us time to explore potential compat dangers etc

mustaq: let me file a new issue about the touch case, because the spec doesn't say specifically what happens, so not easy

Patrick: possibly an easy one - this issue w3c/pointerevents#543

We originally didn't include gestures for IPR concerns...but maybe the time is right now to broach the subject?

Rob: if not our group, then who?

mustaq: maybe we can start putting feelers out

This would be perfect for a hallway conversation at TPAC

mustaq: let's keep #543 open as an initial place for discussion

Thank you all, we'll reconvene in two weeks' time

Summary of action items

  1. review the WPT results at this stage, investigate any failures
Minutes manually created (not a transcript), formatted by scribe.perl version 244 (Thu Feb 27 01:23:09 2025 UTC).

Diagnostics

Maybe present: Patrick, Rob

All speakers: mustaq, Patrick, Rob

Active on IRC: mustaq, Patrick_H_Lauke