Minutes from Pointer Events WG call 7 July 2021

Dear all,

minutes from today's call will be at 
https://www.w3.org/2021/07/07-pointerevents-minutes.html (though 
RRSAgent has been having issues) and copied below (apologies for the 
rough and ready manual formatting)


Meeting: PEWG
Chair: Patrick H. Lauke
Agenda: 
https://www.w3.org/events/meetings/9718517d-0e08-4377-bb7c-07332948233b/20210707T110000
Scribe: Patrick_H_Lauke

Present: smaug, flackr, plh, mustaq

TOPIC: "Update targets of predicted and coalesced events when trusted 
event target changes." https://github.com/w3c/pointerevents/pull/390
Patrick: i've seen some good comments, pull request was approved, but i 
wonder how this will square with the other PR 
https://github.com/w3c/pointerevents/pull/377 which essentially rips out 
the section you just updated Rob
Patrick: what I would propose, in light of #377 which changes the whole 
section anyway, is not to spend time now refining this (for consistency 
etc) but get it out there into main branch, and THEN see how this 
affects #377 and if we can then put that into that one in some way
[group agrees to merge now]
ACTION: merge PR 390


TOPIC: Review 'Expand explanation for non-coalesced 
events' https://github.com/w3c/pointerevents/pull/379 (in particular, 
use of "measurable" in the definition)
https://github.com/w3c/pointerevents/pull/379
Patrick: I know there's been approvals, but i wonder as we were going 
back and forth on "measurable" vs "continuous" if we can graft the two 
together https://github.com/w3c/pointerevents/pull/379#discussion_r665399239
Patrick: think this is in line with what Rob was suggesting last time. 
is this a good idea? if so which variant? i think the first one 
("continuous pointer sensor data") is closest to what Rob had in mind
[group agrees first one is good]
ACTION: Patrick to make change (add "continuous") and merge #379


TOPIC: Review 'Simplify/clarify coalesced and predicted 
events' https://github.com/w3c/pointerevents/pull/377
Patrick: apologies, but even i have lost track now of where we are with this
Mustaq: after Rob's change in the other PR, we had good separation 
between author-facing (10.1 / 10.2) and browser engineer facing (10.3)
Patrick: and now in #377 10.3 doesn't exist anymore 
https://pr-preview.s3.amazonaws.com/w3c/pointerevents/pull/377.html
Rob: where we introduce the concepts of coalesced and predicted events 
lists, we can put the bit about trusted events from the other PR
Rob: do we have to do any modification of the list when 
getCoalescedEvents is called now? don't think we do, because it was only 
target that changes
flackr: Could mention when target changes after dfn here 
https://github.com/w3c/pointerevents/pull/377/files#diff-0eb547304658805aad788d320f10bf1f292797b5e6d745a3bf617584da017051R969
mustaq: 
https://pr-preview.s3.amazonaws.com/flackr/pointerevents/pull/390.html#populating-and-maintaining-the-coalesced-and-predicted-event-lists
mustaq: After #390, both 10.1 and 10.2 are dev facing, while #10.3 is 
for browser engineers.  I prefer keeping 10.3 separate.
Patrick: wondering if we keep 10.3, if there's anything that can still 
be salvaged with #377 ? might be easier to do a fresh PR that can then 
salvage any bits, but supersede #377
Rob: might be worth making sure we talk about "trusted" events consistently
[group agrees to supersede #377 and fresh PR]
ACTION: Patrick to supersede #377 with fresh PR, still make sure it 
addresses issues it set out to close in #377


TOPIC: Tweak the definition of coalesced event list to deal with 
untrusted events https://github.com/w3c/pointerevents/pull/391
Patrick: unless somebody sees a problem with this, should we just merge?
Rob: seems fine
Olli: i'll write another matching one for predicted events
Patrick: and i'll just merge when it comes in, if it's along same lines
ACTION: Merge #391


TOPIC: Unclear note about PointerEvent initialization of attributes to 
reflect coalesced events https://github.com/w3c/pointerevents/issues/374
Patrick: I had an action from last time, clearly I haven't done 
anything, will do though
Rob: we talked about maybe generalising to giving the idea that the 
event will contain everything author needs to know what changed since 
last event
ACTION: Patrick to propose more generalised note

smaug: https://github.com/w3c/pointerevents/issues/392

TOPIC: How is pointer event ctor supposed to work when coalescedEvents 
is passed using the 
PointerEventInit https://github.com/w3c/pointerevents/issues/223
Olli: filed a new DOM issue because i think we need a tweak at that spec 
to refer to it more easily
once DOM spec is updated we can update PE spec

TOPIC: HTML monkeypatching: initiate the drag-and-drop operation 
definition https://github.com/w3c/pointerevents/issues/384
Mustaq: forgot, will do for next time
ACTION: Mustaq to review issue #384


TOPIC: Clarify whether touch contact must fire a pointerrawupdate 
event https://github.com/w3c/pointerevents/issues/373
Patrick: these are my triage items, wondering if they can be closed or 
if there's actions that need to be taken
Patrick: original poster then added info about their use case to 
https://github.com/w3c/pointerevents/issues/339
ACTION: Close issue


TOPIC: Immediately firing coalesced events for 
enter/leave/over/out? https://github.com/w3c/pointerevents/issues/278
Olli: agree this can be closed
Rob: agree, don't want this behaviour. this is specifically addressed by 
the work with did for target changes
ACTION: Close #278

mustaq: https://github.com/w3c/pointerevents/issues/100
Mustaq: keep in mind for next meeting
ACTION: Review issue #100 for discussion at next meeting


-- 
Patrick H. Lauke

https://www.splintered.co.uk/ | https://github.com/patrickhlauke
https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
twitter: @patrick_h_lauke | skype: patrick_h_lauke

Received on Thursday, 8 July 2021 01:10:04 UTC