overscroll-behavior: Modal-Scroll und Scroll-Chaining gezielt kontrollieren

1. Was Scroll-Chaining ist und warum es zu einem UX-Problem wird

Scroll-Chaining bezeichnet das Standardverhalten von Browsern, eine Scroll-Geste an den nächsten übergeordneten scrollbaren Container weiterzureichen, sobald der aktuell fokussierte Container sein Scroll-Ende erreicht hat. Scrollt ein Nutzer zum Beispiel in einer langen Produktbeschreibung innerhalb eines Modals nach unten und erreicht deren unteres Ende, übernimmt ohne Gegenmaßnahme plötzlich die dahinterliegende Seite die restliche Scroll-Bewegung, und der Hintergrund springt weiter, während der Nutzer eigentlich noch im Modal interagieren wollte.

Dieses Verhalten war ursprünglich als Komfortfunktion gedacht, etwa damit eine kurze verschachtelte Liste den Nutzer nicht in einer Scroll-Sackgasse gefangen hält. Bei Modals, Dropdowns, Off-Canvas-Menüs oder Bild-Slidern wirkt genau diese Weitergabe jedoch wie ein Kontrollverlust: Der Hintergrund bewegt sich unerwartet, während der Nutzer den Eindruck hat, weiterhin im Vordergrund-Element zu interagieren.

2. Die Werte von overscroll-behavior: auto, contain und none

overscroll-behavior kennt drei Werte, die das Verhalten an der Scroll-Grenze eines Containers steuern. auto ist der Standard und entspricht dem klassischen Scroll-Chaining, bei dem die Bewegung ungehindert an den nächsten Container weitergereicht wird. contain stoppt die Weitergabe an übergeordnete Container, erlaubt aber weiterhin visuelle Overscroll-Effekte wie das elastische Nachfedern (Rubber-Banding) am Ende des eigenen Containers. none geht noch einen Schritt weiter und unterdrückt sowohl das Weiterreichen als auch diese nativen Overscroll-Effekte komplett.

Für die meisten UI-Container wie Modals oder Dropdowns ist contain der richtige Wert, weil er das störende Scroll-Chaining beendet, dem Container selbst aber weiterhin ein natives, physikalisch wirkendes Scroll-Verhalten am Rand belässt. none eignet sich eher für sehr spezifische Fälle, in denen selbst das Rubber-Banding als störend empfunden wird, etwa bei einem Canvas-basierten Bildbetrachter mit eigener Zoom-Logik.

/* Scroll-Chaining im Modal-Body stoppen,
   Rubber-Banding am eigenen Rand bleibt erhalten */
.modal-body {
  overflow-y: auto;
  overscroll-behavior: contain;
  max-height: 70vh;
}

3. Einzelne Achsen steuern: overscroll-behavior-x und -y

Neben der zusammenfassenden overscroll-behavior-Kurzform erlauben overscroll-behavior-x und overscroll-behavior-y eine getrennte Steuerung pro Achse. Das ist besonders bei horizontal scrollenden Komponenten wie einem Bild-Slider oder einer Produktkarussell-Leiste relevant, bei denen nur die horizontale Weitergabe unterbunden werden soll, während vertikales Scrollen weiterhin ganz normal an die Seite durchgereicht wird, etwa wenn der Slider nicht die volle Bildschirmhöhe einnimmt.

Eine getrennte Steuerung verhindert außerdem ein häufiges Missverständnis: Wer overscroll-behavior: contain pauschal auf beide Achsen anwendet, obwohl der Container nur horizontal scrollt, ändert unnötig auch das vertikale Verhalten, was bei einem Container, der zufällig auch minimal vertikal überläuft, zu unerwarteten Effekten führen kann.

/* Nur horizontales Scroll-Chaining im Slider stoppen */
.product-carousel {
  overflow-x: auto;
  overscroll-behavior-x: contain;
}

4. Pull-to-Refresh auf Mobilgeräten gezielt verhindern

Auf mobilen Browsern wie Chrome für Android löst ein Ziehen nach unten am oberen Rand der Seite standardmäßig eine Pull-to-Refresh-Aktion aus, die die gesamte Seite neu lädt. Das wird zum Problem, sobald eine eigene UI-Komponente, etwa ein von oben nach unten ziehbares Sheet oder eine Pull-to-Refresh-Logik innerhalb einer Single-Page-Anwendung, dieselbe Geste für einen eigenen Zweck braucht, denn ohne Gegenmaßnahme interpretiert der Browser die Geste zuerst und lädt versehentlich die komplette Seite neu.

overscroll-behavior-y: contain auf dem html- oder body-Element unterbindet genau dieses browserseitige Pull-to-Refresh, sobald die Geste innerhalb eines Containers beginnt, der selbst scrollbar ist, ohne dass ein touchstart/touchmove-Listener mit manuellem preventDefault() in JavaScript nötig wäre. Das reduziert nicht nur den Code, sondern vermeidet auch die bekannten Performance-Nachteile von nicht-passiven Touch-Event-Listenern beim Scrollen.

/* Browser-eigenes Pull-to-Refresh auf der gesamten Seite verhindern */
html, body {
  overscroll-behavior-y: contain;
}

5. contain vs. none: wann welcher Wert die bessere Wahl ist

Der Unterschied zwischen contain und none betrifft ausschließlich das native, physikalisch anmutende Verhalten am Ende des eigenen Containers, nicht die Weitergabe an übergeordnete Elemente, die beide Werte gleichermaßen unterbinden. contain lässt dieses Nachfedern zu und wirkt dadurch auf den meisten Plattformen vertraut, weil es dem gewohnten nativen Scroll-Gefühl entspricht, das Nutzer aus anderen Apps kennen.

none unterdrückt dieses Nachfedern vollständig und eignet sich für Fälle, in denen ein eigenes, custom gebautes Scroll- oder Drag-Verhalten mit dem nativen Rubber-Banding kollidieren würde, etwa bei einem selbst implementierten, per Touch-Geste steuerbaren Bottom-Sheet, das eigene Physik-Berechnungen für das Federverhalten mitbringt. Für die überwiegende Mehrheit der Standard-UI-Fälle wie Modals, Dropdowns und Off-Canvas-Menüs bleibt contain jedoch die empfehlenswertere, weil natürlichere Wahl.

6. Praxisbeispiel: scrollbares Dropdown ohne Hintergrund-Sprung

Ein scrollbares Dropdown-Menü, etwa eine lange Ländervorwahl-Liste in einem Checkout-Formular, zeigt das Problem besonders deutlich: Scrollt der Nutzer bis zum letzten Eintrag der Liste und scrollt danach mit derselben Geste weiter, springt ohne Gegenmaßnahme die dahinterliegende Formularseite mit, obwohl der Nutzer erkennbar noch innerhalb der Dropdown-Liste interagieren wollte. Das wirkt gerade in einem sensiblen Formular-Kontext wie Checkout besonders störend, weil ein unerwarteter Sprung die Konzentration des Nutzers unterbricht.

Mit overscroll-behavior: contain direkt auf dem scrollbaren Dropdown-Container endet die Scroll-Bewegung sauber am letzten Listeneintrag, ohne dass die Formularseite dahinter reagiert. Diese eine Zeile CSS ersetzt zuverlässig ältere Lösungen, die mit event.stopPropagation() oder manuellem preventDefault() auf Wheel- und Touch-Events gearbeitet haben und dabei regelmäßig Rand- und Edge-Cases wie Trackpad-Gesten übersehen haben.

/* Dropdown scrollt eigenstaendig, ohne die Formularseite mitzuziehen */
.dropdown-list {
  max-height: 240px;
  overflow-y: auto;
  overscroll-behavior: contain;
}

7. Vergleich zur JavaScript-Lösung: warum CSS hier die bessere Wahl ist

Vor overscroll-behavior ließ sich Scroll-Chaining nur durch aufwändige JavaScript-Logik unterbinden, meist über einen wheel- oder touchmove-Listener, der die Scroll-Position des Containers prüft und bei Erreichen der Grenze event.preventDefault() aufruft. Diese Lösung funktioniert, bringt aber mehrere Nachteile mit: Nicht-passive Event-Listener blockieren das Rendering während des Scrollens, die Logik muss für Maus-, Trackpad- und Touch-Eingaben getrennt behandelt werden, und Randfälle wie diagonales Scrollen werden leicht übersehen.

overscroll-behavior löst dasselbe Problem deklarativ direkt im CSS, ohne einen einzigen Event-Listener, ohne Rendering-blockierende JavaScript-Ausführung während des Scrollens und ohne plattformspezifische Sonderfälle, weil der Browser die Eingabemethode bereits intern normalisiert. Für neue Projekte gibt es praktisch keinen Grund mehr, Scroll-Chaining über JavaScript zu unterbinden, sobald die Ziel-Browser overscroll-behavior unterstützen.

8. Browser-Unterstützung und ein risikofreier Fallback

Chrome, Edge und Firefox unterstützen overscroll-behavior bereits seit mehreren Jahren zuverlässig, Safari zog mit einer neueren Version nach, sodass die Eigenschaft heute in allen relevanten Browser-Engines ankommt. Ein Browser, der die Eigenschaft nicht kennt, ignoriert die Deklaration einfach und behält das klassische Scroll-Chaining bei, exakt das Verhalten, das ohnehin schon vor Einführung der Eigenschaft galt, ganz ohne Fehler oder sichtbaren Bruch.

Diese Eigenschaft als reine Verbesserung, nicht als Voraussetzung, macht den Einsatz in produktiven Projekten risikofrei: Es ist nicht nötig, auf ein Feature-Flag oder eine JavaScript-Erkennung zu warten, bevor overscroll-behavior: contain auf allen relevanten Containern eingesetzt wird. Nutzer eines nicht unterstützenden Browsers bemerken schlicht keinen Unterschied zum bisherigen Verhalten.

9. Praxis-Einsatz im Shop: Warenkorb-Drawer, Filter-Sheets und Bildergalerien

Im Hyvä-Kontext lohnt sich overscroll-behavior: contain auf jedem scrollbaren Alpine.js-gesteuerten Container mit eigenem Overflow, allen voran der Warenkorb-Drawer, das mobile Filter-Sheet in der Kategorienavigation und die Bildergalerie auf der Produktdetailseite. In allen drei Fällen verhindert die Eigenschaft, dass ein Scroll-Vorgang innerhalb der Komponente versehentlich die Hintergrundseite oder, auf Mobilgeräten, ein Pull-to-Refresh auslöst.

Die Kombination mit scrollbar-gutter aus einem verwandten Artikel ergibt ein vollständiges Bild: overscroll-behavior verhindert unerwünschte Scroll-Weitergabe zwischen Containern, während scrollbar-gutter Layout-Sprünge durch erscheinende Scrollbalken verhindert. Beide Eigenschaften zusammen sorgen dafür, dass scrollbare UI-Komponenten sich vorhersehbar verhalten, ohne dass dafür ein einziges Byte JavaScript nötig wäre.

10. Zusammenfassung

11. FAQ: overscroll-behavior: Das Wichtigste auf einen Blick