Meeting minutes
<smaug> coffee, this dragon needs coffee. Will be there in a moment.
sure thing
Relationship between main pointer event and coalesced events https://github.com/w3c/pointerevents/issues/409
related PR Clarify that coalesced events list contain also a clone of the parent event https://
Olli: I reframed a tiny bit. idea with recent one is that the list is never empty for pointermove and pointerrawupdate
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
Olli: "unless the event is mousemove these are zero" per spec
Rob: i think you need this for pointerlock. still want them on mouse type pointer events
Olli: its not that they shouldn't be exposed, but that movementX/Y needs to be better defined
Robert: I think we know what we expect to see, just writing it in a sensible way
Olli: in this I just wanted to focus on the list stuff, not the movement
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
Olli: question is what movementX/Y is relative to
Rob: it should be relative to previous event in the coalesced events list
Rob: reason this is tricky to specify is the movement fields
Rob: single event shouldn't be different, we want to say developers don't need to check both parent event and coalesced events list
Olli: so the last event in the coalesced events list is NOT the parent event itself
<mustaq> movementxy spec: https://
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
Olli: there may be even more fields that differ
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
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?
<mustaq> What if "PE spec overrides https://
[discussion on being explicit what IS same, vs being explicit about what IS different]
Rob: I'm keen on having maybe a more generic text that covers all "relative" fields (present and future)
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
Patrick: here's a rough rewrite...would that be too wordy?
"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..."
Olli: it's not just those properties though, you also have to include all mouse event properties, UIEvent properties, ...
<smaug> https://
[worry about other properties being resampled, so even more different between the "clone" of the event and the "parent" event]
[discussion on fact that we don't specify in spec HOW user agents create the "parent" event based on coalesced events]
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
me
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
Mustaq: there's no mention of how the resampling happens, so maybe we should define it?
Patrick: is that something we WANT to specify?
Rob: we don't want to specify, but want to make sure browsers are somehow spec compliant
Rob: "the top parent event can ... have some summing/averaging/etc ..."
Mustaq: it's the going back in time part that might need to be defined
Rob: timestamp things should not be affected though
Olli: spec does talk about/define timestamps explicitly
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
Rob: parent event is a representation of all events in the coalesced events list, but can have UA adaptations/changes
Olli: the actual stream of events is the coalesced (raw) events. then they're batched and represented by the parent event
Rob: we could even be explicit about "developers should either use all of the coalesced events, or the parents events, but not both"
Rob: having a summary sentence like that would help explain what it all means for developers
Olli: think this needs all of us to come up with more ideas to how to massage it into a proper spec change
Rob: we can just add comments to PR and iterate
ACTION: everybody to think again about best approach to solve https://
<smaug> https://
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
ACTION: review https://