[cssom-view] Scroll steps don't match implementations

[emilio]

https://drafts.csswg.org/cssom-view/#document-run-the-scroll-steps has a few issues afaict:

• 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.

Any strong opinions?

cc @dlrobertson @theres-waldo @lilles @smfr @flackr

[dbaron]

cc @flackr (again) and @skobes-chromium for an opinion if this makes sense from the Chromium side

[css-meeting-bot]

The CSS Working Group just discussed [cssom-view] Scroll steps don't match implementations, and agreed to the following:

• RESOLVED: Fix up the spec to put all scroll-related events in a single queue

The full IRC log of that discussion

<TabAtkins> emilio: the cssom-view spec has a bunch of issues, it doesn't match impls in several parts and are just wrong in several
<TabAtkins> emilio: scroll events aren't fired at a specific time, scroll-snap are fired before other scroll events, there's no distinction between visual viewport and others
<TabAtkins> emilio: i posted my research on how browser behave in this regard
<TabAtkins> emilio: webkit and gecko order visual viewport and regular scroll events consistently
<TabAtkins> emilio: with addition of scrollEnd and scorllSnap, the chromium appraoch of just having them on the same separate queue and fire them in order makes sense, i think
<TabAtkins> emilio: in aprticular, i don't see a reason why scroll triggered by some events should fire on the same frame vs another
<TabAtkins> emilio: so having all scroll events in one queue, fired in order
<TabAtkins> emilio: and side effects firing in next frame. seems fine
<TabAtkins> emilio: i have a patch to fix all this, but wondered if people have strong opinions
<TabAtkins> astearns: did you do any looking back thru commit history to see why scrollsnap is sbefore all other events?
<TabAtkins> emilio: no, they were the last added and i think they were just put in the wrong place
<TabAtkins> TabAtkins: i defer to flackr, so as long as he's looked at it i'm happy to accept emilio's opinion
<TabAtkins> astearns: everyone was pinged, no comments in a few months
<TabAtkins> dbaron: flackr or skobes, i'll ping them both
<TabAtkins> astearns: do people want to wait on a positive response? i'm happy to just change the spec
<TabAtkins> TabAtkins: i think the spec is messy enough that we can just merge what we have and quibble over the details
<TabAtkins> ntim: should i ping Simon?
<TabAtkins> emilio: yes plz
<TabAtkins> astearns: do you think we should wait on resolution?
<TabAtkins> ntim: dunno
<TabAtkins> dbaron: i guess i dont' feel like we have to wait. would be nice to get thru to them at some point, but it can be post resolution
<TabAtkins> astearns: so proposed: Fix up the spec to put all scroll-related events in a single queue
<TabAtkins> ntim: one argument for waiting for simon is he's co-editor
<TabAtkins> emilio: that means he can revert my change
<TabAtkins> astearns: yeah, it's been months and i'd like to move things along
<TabAtkins> astearns: objections to the proposed resolution?
<TabAtkins> RESOLVED: Fix up the spec to put all scroll-related events in a single queue

[flackr]

I support the resolution - all of the events should be put in a single queue, fired on the next frame with specified ordering associated events - e.g. scrollend occurs after the last scroll.