Ces effets fonctionnent très bien avec les navigateurs ou les scroll est fait de manière synchrone sur le thread principal du navigateur. Toutefois, la plupart des navigateurs supportent actuellement une sorte de scroll asynchrone afin de prroposer une expérience cohérente en 60 images par secondes à l'utilisateur. In the asynchronous scrolling model, the visual scroll position is updated in the compositor thread and is visible to the user before the scroll event is updated in the DOM and fired on the main thread. This means that the effects implemented will lag a little bit behind what the user sees the scroll position to be. This can cause the effect to be laggy, janky, or jittery — in short, something we want to avoid.

Below are a couple of examples of effects that would not work well with asynchronous scrolling, along with equivalent versions that would work well:

Example 1: Sticky positioning

Here is an implementation of a sticky-positioning effect, where the "toolbar" div will stick to the top of the screen as you scroll down.

This implementation of sticky positioning relies on the scroll event listener to reposition the "toolbar" div. As the scroll event listener runs in the JavaScript on the browser's main thread, it will be asynchronous relative to the user-visible scrolling. Therefore, with asynchronous scrolling, the event handler will be delayed relative to the user-visible scroll, and so the div will not stay visually fixed as intended. Instead, it will move with the user's scrolling, and then "snap" back into position when the scroll event handler runs. This constant moving and snapping will result in a jittery visual effect. One way to implement this without the scroll event listener is to use the CSS property designed for this purpose:

In this example, there is a scroll event listener which detects if the scroll position is within 200 pixels of the top of the "snaptarget" div. If it is, then it triggers an animation to "snap" the scroll position to the top of the div. As this animation is driven by JavaScript on the browser's main thread, it can be interrupted by other JavaScript running in other tabs or other windows. Therefore, the animation can end up looking janky and not as smooth as intended. Instead, using the CSS snap-points property will allow the browser to run the animation asynchronously, providing a smooth visual effect to the user.

This version can work smoothly in the browser even if there is slow-running Javascript on the browser's main thread.

Other effects

In many cases, scroll-linked effects can be reimplemented using CSS and made to run on the compositor thread. However, in some cases the current APIs offered by the browser do not allow this. In all cases, however, Firefox will display a warning to the developer console (starting in version 46) if it detects the presence of a scroll-linked effect on a page. Pages that use scrolling effects without listening for scroll events in JavaScript will not get this warning. See the Asynchronous scrolling in Firefox blog post for some more examples of effects that can be implemented using CSS to avoid jank.

Future improvements

Going forward, we would like to support more effects in the compositor. In order to do so, we need you (yes, you!) to tell us more about the kinds of scroll-linked effects you are trying to implement, so that we can find good ways to support them in the compositor. Currently there are a few proposals for APIs that would allow such effects, and they all have their advantages and disadvantages. The proposals currently under consideration are:

Web Animations: A new API for precisely controlling web animations in JavaScript, with an additional proposal to map scroll position to time and use that as a timeline for the animation.

CompositorWorker: Allows JavaScript to be run on the compositor thread in small chunks, provided it doesn't cause the framerate to drop.

Scroll Customization: Introduces a new API for content to dictate how a scroll delta is applied and consumed. As of this writing, Mozilla does not plan to support this proposal, but it is included for completeness.

Call to action

If you have thoughts or opinions on:

Any of the above proposals in the context of scroll-linked effects.

Scroll-linked effects you are trying to implement.

Any other related issues or ideas.

Please get in touch with us! You can join the discussion on the public-houdini mailing list.