Meeting minutes
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
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://
Olli: ... can't have default values for an object which is nullable... that's been part of our sticking point
<mustaq> w3c/
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: 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://
Patrick: out of interest, is input device capabilities actually implemented anywhere?
Olli: chromium has some code for it...
<smaug> https://
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