- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Wed, 23 Oct 2024 18:10:18 +0100
- To: Pointer Events Working Group <public-pointer-events@w3.org>
Dear all, the minutes from today's quick meeting are at https://www.w3.org/2024/10/23-pointerevents-minutes.html and copied below: PEWG 23 October 2024 Agenda: https://www.w3.org/events/meetings/66591f6b-6694-4f90-b23d-bf8f1b9dda8a/20241023T110000/ IRC log: https://www.w3.org/2024/10/23-pointerevents-irc Attendees: 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 * Ensure predicted events only use input from the current partition w3c/pointerevents#518 * [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 * Triage 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 Olli: I added a comment Rob: I was on the hook to write something up. I have strong feelings that precision should be at least down to device pixel level, and not to create excessive banding Rob: to bring back to root concern, even choosing higher precision of the two options, it's not going to be precise enough to reveal things like battery fluctuations ACTION: Rob to draft an initial basic PR to get some of these thoughts down for us to iterate over # Ensure predicted events only use input from the current partition w3c/pointerevents#518 Patrick: I was the one that I'd do an initial basic PR for discussion, but had no time since last meeting. Promise that for the next meeting I'll have something to discuss ACTION: Patrick to draft a PR to address this # [touch actions] handwriting manipulation type to distinguish panning w3c/pointerevents#516 Patrick: I think one of the concerns we've had in the discussion of the issue since the meeting was what should happen on devices that don't support handwriting, and developers not being aware that effectively this will result in touch-action: none unintentionally Rob: trying to think how we tackled this with things like zoom ... just to make sure that users can also still pan Rob: if an authors specifies pinch-zoom, does that mean they can't pan? that's the same footgun Mustaq: this is the same potential problem <mustaq> Pinch-zoom in a separate bit in Chromium: https://source.chromium.org/chromium/chromium/src/+/main:cc/input/touch_action.h;drc=635df9846eb3eb7ddf2b4f36b9e32c4ea650b368;l=32 <mustaq> Here is the spec: https://compat.spec.whatwg.org/#touch-action Patrick: I admit that I am still not quite understanding the use case of touch-action: handwriting, as from the presentation at BlinkOn (?) it seems that this uses heuristics by default - if i start handwriting near an input/writeable field, it assumes i'm handwriting. so this touch-action: handwriting seems the opposite of what you'd want...telling the browser NOT to do handwriting Rob: this is consistent though with other touch actions Patrick: but it means that up to now, if a dev had set any specific touch-action, and they omitted handwriting (as it didn't exist), the browser should IGNORE handwriting, but it clearly isn't at the moment Rob: except if we say that manipulation includes handwriting ACTION: further discussion on the issue, as some aspects (use case in particular) aren't quite clear to all # Meta-issue: update WPT to cover Pointer Events Level 3 #445 w3c/pointerevents#445 Patrick: think we were close, only had this one for now w3c/pointerevents#300 Rob: I put together a test page for this Rob: as at first I thought Chrome was allowing bidirectional (?) capture, but testing this with the new test page i couldn't repro. so might be WPT framework has some bug/issue that gives wrong result Olli: ... we'll still need the same origin test though [discussion on how out-of-process might affect test/check] <flackr> https://flackr.github.io/web-demos/pointer-events/capture-frame/index.html Rob: both of the captures in the above demo fail Mustaq: you're seeing same behaviour, regardless of which direction you go Rob: i also think the silent failure may not be right. we loudly fail in other cases, why be silent on this one Rob: would anybody be opposed to allowing same origin capture? or should we delay until we see people needing it? Rob: if goal is to specify what's implemented, we can just test the current thing and figure out why the WPT behaves differently from this test page... Olli: thinking of other cases other than same origin... Rob: don't feel strongly we need to enable this - currently not allowed, and not heard any feedback from devs complaining about this, to my knowledge Patrick: suggest perhaps opening a new future speculative issue "should this be relaxed?", and passing this to a few other folks (including those from Apple) and see what the feedback there is, but for right now for v3 just investigate WPT oddity ACTION: Rob et al, investigate WPT odd behaviour for this test ACTION: Open speculative new issue about potential relaxing of the requirement for same origin Patrick: Rob is it worth also filing a new issue/doing a PR about not silently failing, but loudly failing? Olli: so about throwing error? Rob: yeah we throw in other similar scenarios, but in this case we silently fail Rob: in my mind, the developer contract is much clearer if you request a capture and it throws if it wasn't possible/allowed Mustaq: this would be fine with me Olli: not sure we can just push it for v3 Rob: we're masking developer bugs Patrick: we can leave it for now in v3, and earmark it for a consistency update in v4/future ACTION: File an issue about future update to make failed capture throw # Triage unlabelled issues https://github.com/w3c/pointerevents/issues?q=is%3Aissue+is%3Aopen+-label%3Afuture+-label%3Av3++-label%3Av3-blocking Mustaq: suggest we devote time next meeting to just go through them right there in the call Thank you all -- 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, 23 October 2024 17:10:28 UTC