IRC log of pointerevents on 2022-04-13

Timestamps are in UTC.

14:55:48 [RRSAgent]

RRSAgent has joined #pointerevents

14:55:48 [RRSAgent]

logging to https://www.w3.org/2022/04/13-pointerevents-irc

14:56:09 [Patrick_H_Lauke]

Meeting: PEWG

14:56:13 [Patrick_H_Lauke]

Chair: Patrick H. Lauke

14:56:18 [Patrick_H_Lauke]

Agenda: https://www.w3.org/events/meetings/0d3af70c-0054-43dc-9c15-c60c5b9c3f3c/20220413T110000

14:56:28 [Patrick_H_Lauke]

Scribe: Patrick H. Lauke

14:56:35 [Patrick_H_Lauke]

ScribeNick: Patrick_H_Lauke

14:57:24 [smaug]

coffee, this dragon needs coffee. Will be there in a moment.

14:59:56 [Patrick_H_Lauke]

sure thing

15:00:42 [flackr]

flackr has joined #pointerevents

15:01:48 [Patrick_H_Lauke]

present+ smaug

15:01:53 [Patrick_H_Lauke]

present+ flackr

15:02:53 [Patrick_H_Lauke]

present+ mustaq

15:03:06 [Patrick_H_Lauke]

TOPIC: Relationship between main pointer event and coalesced events https://github.com/w3c/pointerevents/issues/409

15:03:24 [Patrick_H_Lauke]

related PR Clarify that coalesced events list contain also a clone of the parent event https://github.com/w3c/pointerevents/pull/436

15:03:55 [Patrick_H_Lauke]

Olli: I reframed a tiny bit. idea with recent one is that the list is never empty for pointermove and pointerrawupdate

15:04:29 [Patrick_H_Lauke]

Olli: trying to capture that, and movementX/Y we need to do something about that in another issue. it should be always zero in all pointer events per specification

15:04:47 [Patrick_H_Lauke]

Olli: "unless the event is mousemove these are zero" per spec

15:05:30 [Patrick_H_Lauke]

Rob: i think you need this for pointerlock. still want them on mouse type pointer events

15:05:50 [Patrick_H_Lauke]

Olli: its not that they shouldn't be exposed, but that movementX/Y needs to be better defined

15:06:05 [Patrick_H_Lauke]

Robert: I think we know what we expect to see, just writing it in a sensible way

15:07:03 [Patrick_H_Lauke]

Olli: in this I just wanted to focus on the list stuff, not the movement

15:07:52 [Patrick_H_Lauke]

Rob: movementX/Y won't be the same in the clone, as the movement is relative to the last/preceding coalesced event, not the overall parent event's

15:08:20 [Patrick_H_Lauke]

Olli: question is what movementX/Y is relative to

15:08:32 [Patrick_H_Lauke]

Rob: it should be relative to previous event in the coalesced events list

15:09:30 [Patrick_H_Lauke]

Rob: reason this is tricky to specify is the movement fields

15:10:57 [Patrick_H_Lauke]

Rob: single event shouldn't be different, we want to say developers don't need to check both parent event and coalesced events list

15:12:12 [Patrick_H_Lauke]

Olli: so the last event in the coalesced events list is NOT the parent event itself

15:13:07 [mustaq]

movementxy spec: https://w3c.github.io/pointerlock/#dom-mouseevent-movementx

15:13:21 [Patrick_H_Lauke]

Rob: I have a proposal, but somewhere in UIEVents spec it talks about how movement is initialised... maybe we can say that the parent event IS copied into the coalesced events list, but THEN its movementX/Y fields are then initialised/set to be relative to the previous event in the coalesced events list

15:13:31 [Patrick_H_Lauke]

Olli: there may be even more fields that differ

15:14:17 [Patrick_H_Lauke]

Olli: we need to somehow define that / not give the impression that it's not a copy/clone/exact same event in the coalesced events list as the parent event

15:20:10 [Patrick_H_Lauke]

Patrick: could we maybe be super specific and say the last event in coalesced events list will have the same clientX, clientY, etc and list them explicitly, and then omit ones that like movementX/Y and say nothing about them?

15:20:21 [mustaq]

What if "PE spec overrides https://w3c.github.io/pointerlock/#extensions-to-the-mouseevent-interface for coalesced events like this: blah"

15:20:36 [Patrick_H_Lauke]

[discussion on being explicit what IS same, vs being explicit about what IS different]

15:21:33 [Patrick_H_Lauke]

Rob: I'm keen on having maybe a more generic text that covers all "relative" fields (present and future)

15:22:55 [Patrick_H_Lauke]

Rob: we should have a section that defines how movementX/Y are defined in PE, but for this specific situation here, it may be sufficient to be generic/vague about "relative properties" and give movementX/Y as an example and link back to the pointerlock spec

15:29:56 [Patrick_H_Lauke]

Patrick: here's a rough rewrite...would that be too wordy?

15:29:59 [Patrick_H_Lauke]

"that were coalesced into this event. The last event in the coalesced events list will have the same properties pointerId, width, height, pressure, tangentialPressure, tiltX, tiltY, twist, altitudeAngle, azimuthAngle, pointertype, isPrimary as the "parent" event. Other properties of this last event in the coalesced events list may differ - for instance, movementX and movementY which are relative to the previous event..."

15:31:02 [Patrick_H_Lauke]

Olli: it's not just those properties though, you also have to include all mouse event properties, UIEvent properties, ...

15:31:11 [smaug]

https://github.com/w3c/pointerevents/pull/436/commits/de94e446bce36198006af52649f9f2a9c80ab17e

15:32:05 [Patrick_H_Lauke]

[worry about other properties being resampled, so even more different between the "clone" of the event and the "parent" event]

15:35:34 [Patrick_H_Lauke]

[discussion on fact that we don't specify in spec HOW user agents create the "parent" event based on coalesced events]

15:41:23 [Patrick_H_Lauke]

Patrick: almost thinking that we should just go back to NOT saying anything about adding the parent event into the coalesced events list. looking back at original issue 409 that was filed, it was about convenience for authors, but we're seeing that because how UAs generate paretn based on coalesced raw events is a black box, not sure we can be authoritative about this. authors should just use parent AND coalesced events all the ti

15:41:23 [Patrick_H_Lauke]

me

15:41:50 [Patrick_H_Lauke]

Rob: but then you may end up with a situation where you go back in time, if parent event is slightly older than the last event(s) in the coalesced events list

15:42:22 [Patrick_H_Lauke]

Mustaq: there's no mention of how the resampling happens, so maybe we should define it?

15:42:47 [Patrick_H_Lauke]

Patrick: is that something we WANT to specify?

15:43:07 [Patrick_H_Lauke]

Rob: we don't want to specify, but want to make sure browsers are somehow spec compliant

15:43:58 [Patrick_H_Lauke]

Rob: "the top parent event can ... have some summing/averaging/etc ..."

15:44:15 [Patrick_H_Lauke]

Mustaq: it's the going back in time part that might need to be defined

15:44:27 [Patrick_H_Lauke]

Rob: timestamp things should not be affected though

15:44:49 [Patrick_H_Lauke]

Olli: spec does talk about/define timestamps explicitly

15:45:19 [Patrick_H_Lauke]

Olli: should we define how UAs build the parent event (but keep it vague about resampling etc), which THEN lets us define what the last event in the coalesced events list is

15:45:53 [Patrick_H_Lauke]

Rob: parent event is a representation of all events in the coalesced events list, but can have UA adaptations/changes

15:46:28 [Patrick_H_Lauke]

Olli: the actual stream of events is the coalesced (raw) events. then they're batched and represented by the parent event

15:47:00 [Patrick_H_Lauke]

Rob: we could even be explicit about "developers should either use all of the coalesced events, or the parents events, but not both"

15:47:33 [Patrick_H_Lauke]

Rob: having a summary sentence like that would help explain what it all means for developers

15:48:09 [Patrick_H_Lauke]

Olli: think this needs all of us to come up with more ideas to how to massage it into a proper spec change

15:49:53 [Patrick_H_Lauke]

Rob: we can just add comments to PR and iterate

15:50:13 [Patrick_H_Lauke]

ACTION: everybody to think again about best approach to solve https://github.com/w3c/pointerevents/pull/436

15:50:48 [smaug]

https://github.com/w3c/pointerevents/issues/356

15:51:23 [Patrick_H_Lauke]

Olli: if anybody from Google side could have a look at the most recent comment, and see what Chrome actually does, we may be able to take this forward as well

15:51:39 [Patrick_H_Lauke]

ACTION: review https://github.com/w3c/pointerevents/issues/356

15:52:11 [Patrick_H_Lauke]

rrsagent, set logs world-visible

15:52:16 [Patrick_H_Lauke]

rrsagent, create minutes

15:52:16 [RRSAgent]

I have made the request to generate https://www.w3.org/2022/04/13-pointerevents-minutes.html Patrick_H_Lauke

15:52:22 [Patrick_H_Lauke]

rrsagent, set logs world-visible

15:52:33 [Patrick_H_Lauke]

rrsagent, bye

15:52:33 [RRSAgent]

I see 2 open action items saved in https://www.w3.org/2022/04/13-pointerevents-actions.rdf :

15:52:33 [RRSAgent]

ACTION: everybody to think again about best approach to solve https://github.com/w3c/pointerevents/pull/436 [1]

15:52:33 [RRSAgent]

recorded in https://www.w3.org/2022/04/13-pointerevents-irc#T15-50-13

15:52:33 [RRSAgent]

ACTION: review https://github.com/w3c/pointerevents/issues/356 [2]

15:52:33 [RRSAgent]

recorded in https://www.w3.org/2022/04/13-pointerevents-irc#T15-51-39