- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Wed, 31 Jan 2024 20:49:58 +0000
- To: Pointer Events Working Group <public-pointer-events@w3.org>
Dear all, the minutes from today's PEWG meeting are available at https://www.w3.org/2024/01/31-pointerevents-minutes.html and copied below: PEWG 31 January 2024 Agenda: https://www.w3.org/events/meetings/6246bc85-4dae-43a8-a50c-9bc5a0829585/20240131T110000/ IRC log: https://www.w3.org/2024/01/31-pointerevents-irc Attendees flackr, mustaq, Patrick_H_Lauke, smaug Chair: Patrick H. Lauke Scribe: Patrick H. Lauke * Clarify mousedown event target if the preceding pointerdown event listener removes the target #492 w3c/pointerevents#492 * Note/discussion: Consider splitting [UI Events] spec into smaller specifications * Make pointerenter definition similar to pointerover w.r.t. pointerdown from a touch pointer #497 w3c/pointerevents#497 * Update https://github.com/web-platform-tests/wpt/blob/master/pointerevents/META.yml #498 w3c/pointerevents#498 * Meta-issue: update WPT to cover Pointer Events Level 3 #445 w3c/pointerevents#445 * Add logical/abstract values for touch-action #496 w3c/pointerevents#496 * Multi-pen support and persistent pointerId #353 <flackr> w3c/pointerevents#353 Rob: this is a feature that MS has been incubating for a while, now is the time for us to decide if we want to go for it # Clarify mousedown event target if the preceding pointerdown event listener removes the target #492 w3c/pointerevents#492 associated PR w3c/pointerevents#494 Patrick: I believe Olli you thumbsed up the PR Mustaq: as Olli mentions, there are handwavy aspects, but it may be ok to merge at this stage Mustaq: i've used the underscore for `user_event`, because as programmer i didn't feel good about using a space Patrick: are we using underscore or space then? Flackr: i think i prefer space Olli: DOM spec uses camelCase <smaug> https://infra.spec.whatwg.org/#variables Mustaq: I can switch to camelCase, then we can merge ACTION: Mustaq to change user_event to camelCase, then we merge Patrick: so will this close the issue #492 for sure? <mustaq> w3c/uievents#359 Mustaq: while there are other related aspects like the above, I think this will let us close #492 <mustaq> So I think my PR can close the PE issue # Note/discussion: Consider splitting [UI Events] spec into smaller specifications #369 https: //github.com/w3c/uievents/issues/369 Patrick: this is more a "be aware of this" and comment on it if you have strong feelings about it <mustaq> Gary's proposal for 5.3 and 5.4: wheel events should also be part of pointer events spec? [discussion on should mouse and pointer events merge somehow to avoid the whole PE extends mouse events] # Make pointerenter definition similar to pointerover w.r.t. pointerdown from a touch pointer #497 w3c/pointerevents#497 Mustaq: pointerdown definition looks correct, but pointerover event doesn't <mustaq> Look at the diffs in 4.2.1 and 4.2.2 Mustaq: pointerdown special case is missing <mustaq> in the first sentences. Mustaq: ah, it's just different order. I'll close the issue ACTION: Mustaq to close issue # Update https://github.com/web-platform-tests/wpt/blob/master/pointerevents/META.yml #498 w3c/pointerevents#498 w3c/pointerevents#498 Olli: a tool was using this to assign things to Rick/Navid, should we update this <mustaq> Looks like the file is manually updated: https://github.com/web-platform-tests/wpt/commits/master/pointerevents/META.yml ACTION: Olli to update the file in WPT repo Meta-issue: update WPT to cover Pointer Events Level 3 #445 w3c/pointerevents#445 Olli: didn't get chance for new issues. worked on issues for interop 2023 Mustaq: no progress from my side either. hoping to land the PR discussed earlier Olli: i think some WPTs had to be backed out recently because they broke interop2023 scoring <smaug> web-platform-tests/wpt#44251 Patrick: i think unless i'm looking at wrong link, doesn't look bad where we are https://github.com/w3c/pointerevents/issues?q=is%3Aclosed+label%3Aneeds-wpt+ <smaug> https://github.com/w3c/pointerevents/issues?q=label%3Aneeds-wpt+ # Add logical/abstract values for touch-action #496 w3c/pointerevents#496 Patrick: we had an issue opened ages ago about this, and as I was pondering this recently, wanted to make a PR just to get a sense Rob: just to check that the writing mode etc that matters is the one defined on the element that has the touch-action, and NOT the writing mode specifically inside the container that is being interacted with Patrick: that's what i would imagine ... what counts is the writing mode on the element that has the touch-action, regardless of writing modes of child elements Patrick: similarly, we probably want to explicitly mention that if writing mode changes while a gesture/action is already in progress, then that's ignored - same as how touch-action changing in the course of a gesture/action is ignored # Multi-pen support and persistent pointerId #353 Olli: do you know if MS has been implementing that, or is it windows only <mustaq> w3c/pointerevents#353 Rob: i reviewed many of the patches of the implementation, we landed on approach that does take the underlying device id from other platforms (linux, chromeOS, not confident on mac) Olli: proposal that intel brought was chromeOS only, IIRC Rob: supports identifying device on linux and chromeOS in a slightly different way than windows - but the concept of the device producing the event giving you a consistent ID is something that can be implemented on different platforms Rob: they've been trying to come resolution to this in a couple of years. so far i can tell the device id ... there's two reasonable answers: making something LIKE pointerId but not available at the start of the detection; or adding some additional event when the deviceId becomes known for a given pointer. don't like the latter, have preference towards the approach they landed on. extension of pointerId. strictly speaking[CUT] y do is supported by PE... Mustaq: the concept of info only known on down is not unique though, right? Rob: similar to intel's proposal about "this stylus wants to draw in a particular colour" Rob: maybe way to merge this idea with the intel one is to define some sort of structure that can be expanded beyond just deviceId, to also include info like preferred colour etc Rob: if we can come up with something now, MS would likely be happy to change this in their implementation without us ending up locked in with a deviceId on the top-level events properties Rob: Intel had "penCustomisationDetails" (sp?) which is too specific. but maybe deviceInfo or something like that PAtrick: flashback to the device capabilities https://wicg.github.io/input-device-capabilities/ Rob: let's give them a prop that they can hang their deviceId from <mustaq> WICG/input-device-capabilities Olli: i'd love THEM to come up with something Rob: I can take it to them - this is our concern, we'd like to put this behind a more flexible structure, that could then also accommodate other properties like Intel's proposed one ACTION: Rob to speak to Microsoft about using a more generalised structure for the deviceId info Patrick: once Mustaq's PR is ready, I'll merge it, then proceed with finally sending this out for wide review (after refreshing my memory on which groups I need to contact etc). Thank you all, catch you in 2 weeks' time -- 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, 31 January 2024 20:50:13 UTC