- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Wed, 13 Apr 2022 17:05:53 +0100
- To: Pointer Events Working Group <public-pointer-events@w3.org>
Dear all, the minutes from today's meeting are at https://www.w3.org/2022/04/13-pointerevents-minutes.html and copied below PEWG 13 April 2022 Agenda https://www.w3.org/events/meetings/0d3af70c-0054-43dc-9c15-c60c5b9c3f3c/20220413T110000 Attendees: flackr, mustaq, smaug Chair: Patrick H. Lauke Scribe: Patrick H. Lauke * Relationship between main pointer event and coalesced events https://github.com/w3c/pointerevents/issues/409 # 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://github.com/w3c/pointerevents/pull/436 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://w3c.github.io/pointerlock/#dom-mouseevent-movementx 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://w3c.github.io/pointerlock/#extensions-to-the-mouseevent-interface for coalesced events like this: blah" [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://github.com/w3c/pointerevents/pull/436/commits/de94e446bce36198006af52649f9f2a9c80ab17e [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://github.com/w3c/pointerevents/pull/436 <smaug> https://github.com/w3c/pointerevents/issues/356 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://github.com/w3c/pointerevents/issues/356 -- 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 Wednesday, 13 April 2022 16:06:09 UTC