- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Wed, 14 Aug 2024 16:40:44 +0100
- To: Pointer Events Working Group <public-pointer-events@w3.org>
Dear all, the minutes from today's short meeting are at https://www.w3.org/2024/08/14-pointerevents-minutes.html and copied below: PEWG 14 August 2024 Agenda: https://www.w3.org/events/meetings/16b7312b-55ac-4645-8312-0d8103f75519/20240814T110000/ IRC log: https://www.w3.org/2024/08/14-pointerevents-irc Attendees Present flackr, Patrick_H_Lauke Regrets mustaq, smaug Chair: Patrick H. Lauke Scribe: Patrick_H_Lauke * ‘Logical’ values for the ‘touch-action’ property #505 * Add persistentDeviceId to PointerEvent #495 * Triage unlabelled issues https://github.com/w3c/pointerevents/issues * Meta-issue: update WPT to cover Pointer Events Level 3 #445 w3c/pointerevents#445 * Level 3 and Level 4 # ‘Logical’ values for the ‘touch-action’ property #505 w3c/pointerevents#505 Patrick: as discussed in last meeting, i left comment on that issue about our decision to defer to Level 4 # Add persistentDeviceId to PointerEvent #495 w3c/pointerevents#495 Patrick: as discussed in our last meeting, I've now merged this into Level 4 / gh-pages branch Triage unlabelled issues https://github.com/w3c/pointerevents/issues Patrick: want to see if anything is urgent and needs to be added to Level 3, or if we can defer Rob: the issues asking for clarification may be things we want to do for v3, but need time to review ACTION: review any unlabelled issues and mark them as v3 or future # Meta-issue: update WPT to cover Pointer Events Level 3 #445 w3c/pointerevents#445 https://github.com/w3c/pointerevents/issues?q=label%3Aneeds-wpt+ Rob: I have something started <flackr> https://chromium-review.googlesource.com/c/chromium/src/+/5759832 Rob: discovered that Chrome at least doesn't seem to match spec behaviour. matches in one direction but not other Rob: spec seems to imply that you can never capture a pointer if it's not in the active document. In chrome the capture works in one direction but not the other Rob: haven't checked whether Firefox or Safari do the "correct" thing yet. depending on the outcome, we can come back and debate if the spec needs to allow capturing in one direction but not other Rob: if i remember correctly, the issue I found was that if you try to set capture into an inner frame, Chrome allows it, but by spec we shouldn't Rob: i'll post a repro example to the issue, then we can debate (and get results from Safari/Firefox to inform discussion) ACTION: futher exploration needed # Level 3 and Level 4 Patrick: I've gone ahead and followed PLH suggestion to set up a Level 3 branch, and treat gh-pages as Level 4 ACTION: Patrick to catch up with PLH to make sure the new branch structure doesn't auto-publish to wrong place <flackr> In https://w3c.github.io/pointerevents/#setting-pointer-capture the failure when trying to capture to a different document is completely silent - no exception thrown <flackr> > If the pointer is not in the active buttons state or the element's node document is not the active document of the pointer, then terminate these steps. Patrick: so we want to make a change to spec anyway to clarify / don't keep failure silent and instead throw error Patrick: I can see how you'd possibly want to allow capturing down (from parent document into frame) but not other way around, as it could be a third party script that should not be allowed... Rob: keep in mind it can't be cross-origin [Rob gave a very brief additional context/discussion on the thinking behind w3c/pointerevents#512 to gauge interest/use cases. We will discuss this further in future meeting] -- 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, 14 August 2024 15:40:53 UTC