You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It doesn't fire scrollend events. Instead scrollend events are defined to fire "Whenever scrolling is completed", which seems like it should fire sync, which is clearly wrong as it'd fire before the scroll events?
Per spec all current scrollsnapchanging events are dispatched before all other scroll events.
Per spec there's no difference between VisualViewport scroll event order and other scroll events.
Implementations disagree with this in various ways:
My read of the relevant Chromium code is that all these events are stored in a single queue and dispatched in one go. So scrollend / scroll / scrollsnap* events are just sorted in one queue.
The relevant Firefox code intends to dispatch regular scroll, then VisualViewport scroll, then scrollend (then VisualViewport scrollend). However it's bogus and right now it dispatches the scroll and scrollend on the same queue, and then VisualViewport scroll.
The relevant WebKit code dispatches scroll events, then VisualViewport scroll events. Note that WebKit doesn't support scrollend.
We should pick a model for this that makes sense, specially in presence of VisualViewport scrollend events and such.
The Chromium model is simple and makes sense to me: just queue all the scroll-related events in a frame into a single list and dispatch it in order. Any scroll-related event triggered by those gets dispatched on the next frame. But I wonder if people feel strongly about the event ordering.
An interesting thing to think about if we decide to use separate queues per event type, is whether we want to treat them "atomically" or not. E.g., whether the events triggered by earlier lists can affect later lists in the same frame. For example, the spec as written means that scrollsnapchanging events are always before scroll, and a scrollsnapchanging event listener triggering a scroll should fire in the same frame, but if the scroll event triggers snapping then that won't fire snap events until next frame which is a bit odd.
https://drafts.csswg.org/cssom-view/#document-run-the-scroll-steps has a few issues afaict:
scrollend
events. Insteadscrollend
events are defined to fire "Whenever scrolling is completed", which seems like it should fire sync, which is clearly wrong as it'd fire before thescroll
events?scrollsnapchanging
events are dispatched before all other scroll events.VisualViewport
scroll event order and other scroll events.Implementations disagree with this in various ways:
scrollend
/scroll
/scrollsnap*
events are just sorted in one queue.We should pick a model for this that makes sense, specially in presence of
VisualViewport
scrollend events and such.The Chromium model is simple and makes sense to me: just queue all the scroll-related events in a frame into a single list and dispatch it in order. Any scroll-related event triggered by those gets dispatched on the next frame. But I wonder if people feel strongly about the event ordering.
An interesting thing to think about if we decide to use separate queues per event type, is whether we want to treat them "atomically" or not. E.g., whether the events triggered by earlier lists can affect later lists in the same frame. For example, the spec as written means that
scrollsnapchanging
events are always beforescroll
, and ascrollsnapchanging
event listener triggering a scroll should fire in the same frame, but if the scroll event triggers snapping then that won't fire snap events until next frame which is a bit odd.Any strong opinions?
cc @dlrobertson @theres-waldo @lilles @smfr @flackr
The text was updated successfully, but these errors were encountered: