- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Wed, 22 May 2024 16:49:36 +0100
- 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/05/22-pointerevents-minutes.html and copied below: PEWG 22 May 2024 Agenda: https://www.w3.org/events/meetings/6246bc85-4dae-43a8-a50c-9bc5a0829585/20240522T110000/ IRC log: https://www.w3.org/2024/05/22-pointerevents-irc Attendees flackr, mustaq, smaug Chair: Patrick H. Lauke Scribe: Patrick H. Lauke * Meta-issue: update WPT to cover Pointer Events Level 3 * Multi-pen support and persistent pointerId * Working on separate branch for vNext ? # Meta-issue: update WPT to cover Pointer Events Level 3 Olli: I've asked Edgar, but need to coordinate with Mustaq for the WPTs [Discussion on finding an appropriate time to collaborate on WPTs] ACTION: Olli/Mustaq/Rob meeting separately to work on WPTs # Multi-pen support and persistent pointerId w3c/pointerevents#353 w3c/pointerevents#495 Patrick: I see there's been some discussion with Anne VK about the structure. is there more iteration going on about the structure? flattening it? Patrick: wondering if Anne is satisfied with the responses so far, or do we need to rethink it? <mustaq> Inner event creation step: https://dom.spec.whatwg.org/#inner-event-creation-steps Olli: ... can't have default values for an object which is nullable... that's been part of our sticking point <mustaq> w3c/pointerevents#495 Rob: I would still propose that we go for uniqueId, as "device" can have lots of aspects Mustaq: even "unique" can be ambiguous Rob: unique for the pointer. idea that it's persistent... Olli: if it's a separate object, it may help to drive home that it's different from the pointer id that can change Olli: are there use cases for a separate interface for device properties Rob: developer could hang their own extra information..so instead of doing a lookup against device id, they could store them directly? [Further discussion on this different approach of providing a separate storage object for developers to hold whatever info they want there directly] <mustaq> https://wicg.github.io/input-device-capabilities/#extensions-to-the-uievent-interface-and-uieventinit-dictionary Mustaq: was looking at input device capabilities ... does this sound similar? Rob: ... you could have one of these, but if it takes time to identify the unique device, you'd be "switched" from one object with particular capabilities to another (?) Olli: the underlying idea is similar. we might be able to merge these two concepts... Rob: the other option is to put deviceId on the sourceCapabilities (defined in input device capabilities) Olli: then you just have the id, so devs would need to do their hashtable Rob: I like the idea of style stuff being on input device capabilities... Rob: as written in the spec though, different concepts Olli: if i write down on the PR .... inteface can just be an empty object Rob: and in future we can add different data to this object Olli: compat issues when people try to add their own stuff Rob: standard compat issues though. we could add a note about not guaranteeing how persistent the data stored is, what names might be reserved, ... Olli: suggest using framework-specific prefix Olli: I'll try to write something down on this Rob: I think MS will be happy to adopt anything that helps developers support their use case ACTION: Olli to add to the PR <mustaq> https://chromestatus.com/feature/5681847971348480 Patrick: out of interest, is input device capabilities actually implemented anywhere? Olli: chromium has some code for it... <smaug> https://issues.chromium.org/issues/41345476 Patrick: because i remember back in the touch events days this was a hot topic, but not so much anymore Mustaq: I think there's an issue open to actually remove the code from chromium # Working on separate branch for vNext ? Patrick: will catch up with plh about what the practicalities are - can we just open a new branch and then merge PRs like the previous one into it? on the face it'll then still say "Pointer Events Level 3" but clearly it would be targeted at next version after (living standard, or level 4) ACTION: Check with PLH about practicality of new branch for vNext stuff Patrick: for info, I've set the ball rolling on the graceful closure of the Touch Events CG (with additional note at the top to explain it's legacy, and that devs are advised to transition to Pointer Events instead, and then moved to a more official "resting place"). Patrick: Thank you all, catch you in two 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, 22 May 2024 15:49:43 UTC