Minutes from PEWG meeting 22 May 2024

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