- From: Emilio Cobos Álvarez via GitHub <sysbot+gh@w3.org>
- Date: Thu, 07 Nov 2024 13:28:38 +0000
- To: public-css-archive@w3.org
emilio has just created a new issue for https://github.com/w3c/csswg-drafts: == [cssom-view] Scroll steps don't match implementations == 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](https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/page/page_animator.cc;l=260-265;drc=0afc9ac9afcaab79fc54299039f4d27abf3a086d) 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](https://searchfox.org/mozilla-central/rev/113b09cdd5282b39db65b2f62abe843558b9471a/layout/base/nsRefreshDriver.cpp#2733-2736) intends to dispatch regular scroll, then VisualViewport scroll, then scrollend (then VisualViewport scrollend). However [it's bogus](https://bugzilla.mozilla.org/show_bug.cgi?id=1929707) and right now it dispatches the scroll and scrollend on the same queue, and then VisualViewport scroll. * The relevant [WebKit code](https://searchfox.org/wubkat/rev/d45649fa32a499702c30474e94bd6843c4c67849/Source/WebCore/dom/Document.cpp#5230-5243) 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 Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11164 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 7 November 2024 13:28:39 UTC