Simplify/clarify coalesced and predicted events #377
Conversation
* clearly list out properly what properties the coalesced/predicted events should have (more closely matching the suggested structure from #215) * remove the "Populating and maintaining the coalesced and predicted event lists" part, which is more confusing than anything if the various steps (with the dirty flag etc) are essentially just browser-internal flags, and where it doesn't really matter where/when the targets are changed as authors can't observe this change. leave it up to implementations how they want to do it. they can just decide wholesale to set the target to the event where the `getCoalescedEvents`/`getPredictedEvents` methods are being called on - see #364 (comment) Closes #370 #215
|
Setting this to draft, as me ripping out the "Populating and maintaining..." https://w3c.github.io/pointerevents/#populating-and-maintaining-the-coalesced-and-predicted-event-lists section may have been premature. Admittedly, this may be due to me not grokking the central point the section tries to make. My most immediate questions are here #370 (comment) Beyond that, I think it would still be valuable to keep those bullet lists of the various properties of coalesced/predicted events in their respective sections though, as they outline what a JS author can expect from those events. But maybe the "Populating..." part should also be kept, for user agents. |
|
thanks to @smaug---- for taking time today to have a chat about this with me. I'll mull things over some more and propose some further changes that will hopefully steer this in a cleaner direction without losing anything |
|
@smaug---- i rejigged the sections with the "steps" for the UA, hopefully addressing what we discussed the other day about the need to explicitly say that the retargeting/setting the target needs to happen when the methods are called. also, tried to explain a bit better what the colloquial "parent" I used means there. let me know if this is better, then i can set this back to ready for review |
Rewrote them / returned them to the framing of "these are the steps that the user agent needs to follow". Clarified that this is in fact what the UA does (not something aimed at authors), and that these steps must be taken "when the ... method is called" (so any retargeting etc must happen at that point) Also, changed `coalesced event list` / `predicted event list` to plural `coalesced events list` / `predicted events list`. the use of singular `event` was a bit awkward from the start.
8bee474
to
96ee626
Compare
| <li>set <code>pointerId</code>, <code>pointerType</code>, <code>isPrimary</code>, | ||
| <a href="https://dom.spec.whatwg.org/#dom-event-istrusted"><code>isTrusted</code></a>, | ||
| and <a href="https://dom.spec.whatwg.org/#event-target"><code>target</code></a> to match the | ||
| dispatched "parent" pointer event that the <code>getCoalescedEvents()</code> method was called on</li> |
There was a problem hiding this comment.
In the points which are coalesced I think the only thing that could vary is the target (as the pointer moves over different targets). We should never coalesce events from other pointers into a different pointer's event. As such, I think we only need to call out target here.
There was a problem hiding this comment.
but then it would need to say somewhere (else?) that the coalesced / predicted events have the same id/type/etc as their "parent" event that the method was called on (otherwise authors don't know what those values would be set to?)
There was a problem hiding this comment.
adding here that, from what @smaug---- was saying, in the Gecko implementation the non-coalesced "raw" events are not stored as full-fledged pointer events internally, but some more general kind of event. only when getCoalescedEvents is called are they turned into pointer events for the list that is then returned. so probably from that point of view, these steps make more sense. if an engine instead already stores them up as if they were real pointer events, and then only needs to ensure that they're retargeted to the "parent" pointer event where the method is actually called, then yes only retargetting step here would be needed. but then we may need to split out somehting about all the other properties? a separate list that explains what authors can expect pointerId etc to be (that they'll also match the "parent" event)
There was a problem hiding this comment.
but then it would need to say somewhere (else?) that the coalesced / predicted events have the same id/type/etc as their "parent" event that the method was called on (otherwise authors don't know what those values would be set to?)
This seems reasonable to add. We already state that "The events in the coalesced event list will have increasing timeStamps," we could add to this that those other properties will be the same as the PointerEvent (the root one).
adding here that, from what @smaug---- was saying, in the Gecko implementation the non-coalesced "raw" events are not stored as full-fledged pointer events internally, but some more general kind of event. only when
getCoalescedEventsis called are they turned into pointer events for the list that is then returned. so probably from that point of view, these steps make more sense. if an engine instead already stores them up as if they were real pointer events, and then only needs to ensure that they're retargeted to the "parent" pointer event where the method is actually called, then yes only retargetting step here would be needed. but then we may need to split out somehting about all the other properties? a separate list that explains what authors can expectpointerIdetc to be (that they'll also match the "parent" event)
The spec already seems to imply that the PointerEvent keeps a list of full PointerEvents in the coalesced events list, "A PointerEvent has an associated coalesced event list (a list of zero or more PointerEvents)." Implementations can of course optimize and build this on the fly as long as the side effects (i.e. calls to getCoalescedEvents) return a list that is consistent with this assumption. That does raise the question of whether you should get the same list of events with multiple calls - I'd say the spec sort of implies that you should right now, but perhaps it shouldn't.
| zero or more <code>PointerEvent</code>s). If this event is a <code>pointermove</code> | ||
| or <code>pointerrawupdate</code> event, the list is a sequence of all <code>PointerEvent</code>s | ||
| that were coalesced into this event; otherwise it is an empty list.</p> | ||
|
|
||
| <p>The events in the coalesced event list will have increasing | ||
| <a href="https://dom.spec.whatwg.org/#dom-event-timestamp"><code>timeStamps</code></a> | ||
| <p>When the <code>getCoalescedEvents()</code> method is called, user agents MUST apply the following |
There was a problem hiding this comment.
I think it's easier if we "finalize" both lists at the moment the event was dispatched, instead of the moment when get*Events() is called. The target is known at dispatch time, so do we need to delay the target fixup step at all?
If there is a reason to delay it (performance?), then the first call to any of get*Events() can finalize both lists to avoid complications.
There was a problem hiding this comment.
I don't think the spec should say when this happens, and just say that the coalesced events will have the same target.
However, I think an implementation is free to do this whenever it chooses. It shouldn't be developer observable when this happens.
There was a problem hiding this comment.
Nevermind, per discussion it is observable when the target changes so we should retarget here.
happy to bash out some of this in a comment here as well if you're not inspired, and can then wordsmith it some more |
* use `{{Event/timeStamp}}` instead of just `<code>timestamp</code>`
* shorten the "Populating and maintaining..." section even further (and salvage some of the wording from #377)
* predicted events follow the event, not the coalesced events list events
|
As this has become too unwieldy and out of sync with other work that has happened since, closing this - superseded by #395 |
* Tweaks from #377 * use `{{Event/timeStamp}}` instead of just `<code>timestamp</code>` * shorten the "Populating and maintaining..." section even further (and salvage some of the wording from #377) * predicted events follow the event, not the coalesced events list events * Tweak the prose for trusted events, reintroduce list of what authors can expect from events in the coalesced/predicted lists * Make it clear that the "populating" section if for user agents and what they SHOULD do (assuming we want SHOULD here, and not MUST) * Add `()` to getCoalescedEvents/getPredictedEvents method mentions * Remove "dispatched" and clarify the sentences about matching the parent event * Change "events list" references back to "event list" after #394 is merged, change this back * Change "event list" to "events list" now that #394 was merged * Readability tweak for timestamps -> timestamp values * Make first bullet for coalesced events match structure of predicted events list bullet * Tweak trusted events/otherwise ambiguity. Consistent use of `—` em-dashes * Add "trusted" to the sanitisation steps for coalesced events list management * Add "or equal to" the constrainst for timestamps for coalesced and predicted events' timestamps
getCoalescedEvents/getPredictedEventsmethods are being called on - see Add new section explaining coalesced and predicted events #364 (comment)Closes #370, closes #215
Superseded by #395
Preview | Diff