14:59:52 RRSAgent has joined #pointerevents 14:59:57 logging to https://www.w3.org/2024/05/22-pointerevents-irc 15:00:31 Meeting: PEWG 15:01:00 Chair: Patrick H. Lauke 15:02:23 present+ 15:02:39 Agenda: https://www.w3.org/events/meetings/6246bc85-4dae-43a8-a50c-9bc5a0829585/20240522T110000/ 15:02:51 Scribe: Patrick H. Lauke 15:02:58 ScribeNick: Patrick_H_Lauke 15:03:16 TOPIC: Meta-issue: update WPT to cover Pointer Events Level 3 15:03:36 Olli: I've asked Edgar, but need to coordinate with Mustaq for the WPTs 15:04:50 [Discussion on finding an appropriate time to collaborate on WPTs] 15:04:56 present+ flackr 15:05:02 present+ smaug 15:05:12 present+ mustaq 15:06:50 ACTION: Olli/Mustaq/Rob meeting separately to work on WPTs 15:07:07 TOPIC: Multi-pen support and persistent pointerId 15:07:14 https://github.com/w3c/pointerevents/issues/353 15:07:32 https://github.com/w3c/pointerevents/pull/495 15:09:16 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? 15:10:08 flackr_ has joined #pointerevents 15:10:30 Patrick: wondering if Anne is satisfied with the responses so far, or do we need to rethink it? 15:10:40 Inner event creation step: https://dom.spec.whatwg.org/#inner-event-creation-steps 15:11:01 Olli: ... can't have default values for an object which is nullable... that's been part of our sticking point 15:11:10 https://github.com/w3c/pointerevents/pull/495 15:12:51 Rob: I would still propose that we go for uniqueId, as "device" can have lots of aspects 15:13:07 Mustaq: even "unique" can be ambiguous 15:13:22 Rob: unique for the pointer. idea that it's persistent... 15:14:00 Olli: if it's a separate object, it may help to drive home that it's different from the pointer id that can change 15:14:55 Olli: are there use cases for a separate interface for device properties 15:17:42 Rob: developer could hang their own extra information..so instead of doing a lookup against device id, they could store them directly? 15:22:48 [Further discussion on this different approach of providing a separate storage object for developers to hold whatever info they want there directly] 15:23:08 https://wicg.github.io/input-device-capabilities/#extensions-to-the-uievent-interface-and-uieventinit-dictionary 15:23:16 Mustaq: was looking at input device capabilities ... does this sound similar? 15:27:47 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 (?) 15:28:56 Olli: the underlying idea is similar. we might be able to merge these two concepts... 15:29:25 Rob: the other option is to put deviceId on the sourceCapabilities (defined in input device capabilities) 15:29:39 Olli: then you just have the id, so devs would need to do their hashtable 15:31:33 Rob: I like the idea of style stuff being on input device capabilities... 15:32:30 Rob: as written in the spec though, different concepts 15:33:20 Olli: if i write down on the PR .... inteface can just be an empty object 15:33:29 Rob: and in future we can add different data to this object 15:33:44 Olli: compat issues when people try to add their own stuff 15:34:22 Rob: standard compat issues though. we could add a note about not guaranteeing how persistent the data stored is, what names might be reserved, ... 15:34:30 Olli: suggest using framework-specific prefix 15:34:47 Olli: I'll try to write something down on this 15:35:10 Rob: I think MS will be happy to adopt anything that helps developers support their use case 15:35:23 ACTION: Olli to add to the PR 15:36:45 https://chromestatus.com/feature/5681847971348480 15:37:03 Patrick: out of interest, is input device capabilities actually implemented anywhere? 15:37:13 Olli: chromium has some code for it... 15:37:28 https://issues.chromium.org/issues/41345476 15:37:32 Patrick: because i remember back in the touch events days this was a hot topic, but not so much anymore 15:37:51 Mustaq: I think there's an issue open to actually remove the code from chromium 15:38:54 TOPIC: Working on separate branch for vNext ? 15:42:18 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) 15:42:38 ACTION: Check with PLH about practicality of new branch for vNext stuff 15:45:31 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"). 15:45:46 Patrick: Thank you all, catch you in two weeks' time 15:45:51 rrsagent, set logs world-visible 15:45:57 rrsagent, generate minutes 15:45:59 I have made the request to generate https://www.w3.org/2024/05/22-pointerevents-minutes.html Patrick_H_Lauke 15:46:14 rrsagent, bye 15:46:14 I see 3 open action items saved in https://www.w3.org/2024/05/22-pointerevents-actions.rdf : 15:46:14 ACTION: Olli/Mustaq/Rob meeting separately to work on WPTs [1] 15:46:14 recorded in https://www.w3.org/2024/05/22-pointerevents-irc#T15-06-50 15:46:14 ACTION: Olli to add to the PR [2] 15:46:14 recorded in https://www.w3.org/2024/05/22-pointerevents-irc#T15-35-23 15:46:14 ACTION: Check with PLH about practicality of new branch for vNext stuff [3] 15:46:14 recorded in https://www.w3.org/2024/05/22-pointerevents-irc#T15-42-38