- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Wed, 4 Dec 2024 16:36:40 +0000
- To: Pointer Events Working Group <public-pointer-events@w3.org>
Dear all, the minutes from today's meeting are at https://www.w3.org/2024/12/04-pointerevents-minutes.html and copied below: PEWG 04 December 2024 Agenda: https://www.w3.org/events/meetings/66591f6b-6694-4f90-b23d-bf8f1b9dda8a/20241204T110000/ IRC log: https://www.w3.org/2024/12/04-pointerevents-irc Attendees adettenb, flackr, mustaq, Patrick_H_Lauke, smaug Chair: Patrick H. Lauke Scribe: Patrick_H_Lauke * Limit the precision of floating point event fields w3c/pointerevents#517 * [touch actions] handwriting manipulation type to distinguish panning w3c/pointerevents#516 * Meta-issue: update WPT to cover Pointer Events Level 3 #445 w3c/pointerevents#445 * Unlabelled issues https://github.com/w3c/pointerevents/issues?q=is%3Aissue+is%3Aopen+-label%3Afuture+-label%3Av3++-label%3Av3-blocking # 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: * Patrick to actually do #517 * Rob to reflect back discussion to the issue #516 * Olli to follow up about #509 * continue investigation on #529 * review #516 further, but no immediate pressure to get this in for v3 -- 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, 4 December 2024 16:36:47 UTC