do pointerrawupdate events also get predicted events?

[patrickhlauke]

For coalesced events, the spec states

A PointerEvent has an associated coalesced event list (a list of zero or more PointerEvents). If this event is a pointermove or pointerrawupdate event, the list is a sequence of all PointerEvents that were coalesced into this event; otherwise it is an empty list.

but for predicted events, it only mentions pointermove

A PointerEvent has an associated predicted event list (a list of zero or more PointerEvents). If this event is a pointermove event, it is a sequence of PointerEvents that the user agent predicts will follow the events in the coalesced event list in the future; otherwise it is an empty list.

So are pointerrawupdate events not getting a predicted events list? or is this just an oversight in the wording?

[patrickhlauke]

or maybe, conversely: do pointerrawupdate events really have a list of coalesced events? aren't they essentially the raw events that normally get coalesced into a full-on pointermove? or are they really the same as pointermove, just not RAF aligned?

[NavidZ]

Regarding the coalesced event list it was intentional. As pointerrawupdate might also be delayed not due to the rAF but due to the main thread being busy running js code. So potentially they could also get coalesced. Regarding the prediction we didn't see much of a need for that at the time based on the use cases. That was the reasion behind this at the time of writing the spec. Note that we can always go back and add prediction list as well to pointerrawupdate if the need rises.

[patrickhlauke]

Note that we can always go back and add prediction list as well to pointerrawupdate if the need rises.

naively, my preference would be to add prediction list even to pointerrawupdate purely for simplicity/consistency. or, failing that, adding a note explicitly mentioning that predicted events are NOT present for pointerrawupdate events for ... reasons (performance?)

[NavidZ]

I believe it would have a slight negative performance impact if we were do it for pointerrawupdates as well.
But again as far as I'm aware of the pointerrrawupdate usecases the prediction doesn't come in any use for those. So I'd still suggest to delay it and just add a note for now that prediction is not exposed on pointerrawupdate to call it out and wait for a concrete request from a developer for this.