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