Scroll snapping after layout changes

Re-snapping after layout changes arrives in Chrome 81

CSS Scroll Snap lets developers build tidy, predictable scroll experiences by declaring where scroll containers should rest. But the spec had a notable blind spot: the behavior when layout shifts underneath a snapped scroller, for example on window resize or device rotation. In Chrome 81, that's no longer the case. Scrollers now re-evaluate their snap positions after layout changes and can even return to the same element they were snapped to before.

What was missing

A snapped scroller is nice until the viewport changes shape. Core use cases like paginated articles and image carousels hit a wall when a user resizes a window, rotates a phone, or opens DevTools. The scroller holds its pixel offset, but the visible content no longer matches a snap position. The user suddenly stares at a gap or the wrong slide, and must manually scroll to re-align.

Before Chrome 81, the common workaround was to attach event listeners for these layout-change triggers and execute a forced re-snap programmatically:

scroller.scrollBy(0,0);

That approach has a fundamental flaw: it doesn't guarantee the scroller returns to the same element it was on. It simply triggers the closest snap position, which might be a different item. Creating dynamic experiences where content is added, removed, or moved made this problem worse, forcing developers into increasingly complex JavaScript to preserve scroll context. At that point, the CSS feature stops feeling declarative.

Chrome 81 behavior: re-snap on layout change

Chrome 81 makes re-snapping automatic. After a layout change, the scroller is re-evaluated against its snap positions. If it still contains the element it was snapped to before the change, it will re-snap to that same element. The shift from portrait to landscape orientation, for example, will no longer leave you stranded on a blank area while the original content is out of view.

This behavior is not yet universal in the browser landscape. Chrome is currently the only browser with this support; both Firefox and Safari have open tickets to track re-snapping after content or layout changes. In the meantime, the explicit scroll workaround remains the fallback for other engines.

New possibilities: sticky scrollbars from CSS

With automatic re-snapping in place, developers get a new tool for UI patterns that previously required a lot of state-ful JavaScript. Sticky scrollbars are one example: a few lines of CSS are sufficient when the snap engine responds to layout changes.

/* Example omitted: sticky scrollbar implementation snippet */

A more fully realized demo in this space is a chat UI that relies on the same principle to keep relevant content pinned as new messages alter the scroll area.

What's next

The current implementation performs re-snapping instantly. A proposed extension is to animate that movement with smooth scrolling effects, but that remains future work. Ideas and progress are tracked in the CSSWG specification issue thread.

If you want to test re-snapping in Chrome 81 or later, Chromium engineers are accepting feedback on the implementation.