W3C

– DRAFT –
PEWG

04 December 2024

Attendees

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

Meeting minutes

<smaug> just a sec

Limit the precision of floating point event fields w3c/pointerevents#517

Patrick: Although I promised I'd do this for today, time ran away with me. I will work on this today after the call

Rob: I commented on this before last meeting, pointing to animation spec that has similar wording as inspiration. Happy to review this when you have something

ACTION: Patrick to actually do #517

[touch actions] handwriting manipulation type to distinguish panning w3c/pointerevents#516

Rob: considering at the moment to decouple handwriting from panning

adettenb: yes, panning is the scrolling action, handwriting is handwriting action

Rob: and if you have BOTH allowed, it's up to the UA to decide which action to do

Rob: that to me seems right way forward. and you have the patch going forward to address existing sites

Rob: if that all sounds reasonable, think to proceed we can wait for more data before going ahead

Mustaq: wondering where discussion is taking place...

Rob: some of it might be internal/chrome issue

Rob: however yes, would be good to reflect that back into this issue. I can make a comment

ACTION: Rob to reflect back discussion to the issue #516

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

Mustaq: iframe capturing issue that Rob landed, I re-landed, so we should be good on that

Rob: so we can remove label/close issue

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

<mustaq> Only remaining: w3c/pointerevents#509

Olli: this was added two weeks ago

Olli: let me ask Masayuki if he's working on it. not v3-blocking. think spec is clear, could just do with a test

ACTION: Olli to follow up about #509

Unlabelled issues https://github.com/w3c/pointerevents/issues?q=is%3Aissue+is%3Aopen+-label%3Afuture+-label%3Av3++-label%3Av3-blocking

Mustaq: I added to this last week, sorry

Mustaq: #529 is about mouse, what events to fire w3c/pointerevents#529

Mustaq: only remaining question is whether to fire mousemove (?)

Rob: UI events says that we do need to care about things mutating behind cursor. technically for mouse events, but we should follow suit for pointer events

Olli: but PE says only fire when pointer moves...

Rob: UI events used to as well, going back to 2012... used to be the case (in Chrome), we didn't always fire events when content underneath cursor changed. we should follow suit

Mustaq: otherwise would be confusing

Rob: for scrolling it happens after delay (bit handwavy). maybe we can do similar for this case. but should be consistent

Olli: browsers are very inconsistent at this stage. don't like the behaviour, but can live with it.

Olli: if you move, you get pointermove. that's that. but can live with it...

Rob: don't think we should fire move. but for hover states, it should be consistent

Mustaq: so just tying move to the physical movement

Patrick: just as aside, not just physical movement of mouse/finger. also fires in case of change of pressure, angle/tilt, etc

Olli: for boundary events, it currently talks about pointing device being moved

Olli: we would need some tweak there

Patrick: so do we have an action?

Mustaq: we want to match boundary events behavior, but not fire move

Olli: concerned about a resulting change for interop tests

Mustaq: will post summary comment to the issue #529

Mustaq: will look into a PR. how urgent is this?

Patrick: it might be v3-blocking, but not sure if we can realistically fix this soon?

Patrick: might need more time. maybe not v3-blocking ? can also just wait until v4?

Olli: it would be a breaking change...

Patrick: let's defer to v4

<mustaq> Ok I will self assign it to me.

ACTION: continue investigation on #529

Patrick: w3c/pointerevents#530

Mustaq: in my opinion not v3 blocking

Patrick: happy to mark as future

Mustaq: [reads out inconsistencies he found with chorded button presses]

Rob: i'm inclined to think Firefox's behaviour makes sense, firing an event for each button. might not be critical for web, but for gaming

ACTION: review #516 further, but no immediate pressure to get this in for v3

Patrick: thank you all as ever. finishing early as this covers all we had at this point. catch you all again in 2 weeks' time

Summary of action items

  1. Patrick to actually do #517
  2. Rob to reflect back discussion to the issue #516
  3. Olli to follow up about #509
  4. continue investigation on #529
  5. review #516 further, but no immediate pressure to get this in for v3
Minutes manually created (not a transcript), formatted by scribe.perl version 238 (Fri Oct 18 20:51:13 2024 UTC).

Diagnostics

Maybe present: Olli, Patrick, Rob

All speakers: adettenb, Mustaq, Olli, Patrick, Rob

Active on IRC: mustaq, Patrick_H_Lauke, smaug