Summary

  • Erreicht ein innerer Scrollbereich seinen Rand, kann die restliche Bewegung an einen äußeren Bereich übergehen. Das Chatfenster bleibt stehen, während der Artikel dahinter loszieht.
  • contain unterbindet die Übergabe nach außen, erlaubt aber eine lokale Reaktion am Rand; none unterbindet auch diese. Die Entscheidung betrifft das Gefühl einer Grenze, nicht bloß die Bewegung von Pixeln.

Ein Leser scrollt durch eine Unterhaltung am Rand eines langen Textes. Nach der letzten Nachricht dreht er das Mausrad noch einmal. Das Chatfenster steht, der Artikel verschwindet nach oben. Der erste öffentliche W3C-Arbeitsentwurf von 2019 nennt das Scroll Chaining: Ein Scrollvorgang beginnt in einem Container und kann an dessen Grenze zu einem Vorfahren weiterwandern. Für den Browser ist das ein geordneter Ablauf. Für den Leser hat der Chat einen Fahrstuhlknopf gedrückt, ohne zu fragen.

Websites konnten den Vorgang mit JavaScript abfangen. Ein Listener beobachtete Rad- oder Berührungsereignisse und rief am Rand preventDefault() auf. Der Entwurf erklärt, weshalb dieser Wachposten teuer ist. Bei einem nicht passiven Listener muss der Browser die Antwort des Skripts abwarten; der Scrollvorgang kann stocken. Das Abbrechen kann außerdem schon die normale Bewegung bis zur Kante stoppen, obwohl nur die Weitergabe an der Kante unerwünscht war. Vielleicht sollte im Chat ein leichtes Nachfedern sichtbar bleiben, während der Artikel ruhig steht. Ein pauschales Nein zum Ereignis trennt diese beiden Wünsche schlecht.

In den Sitzungsnotizen vom Dezember 2016 hieß der Vorschlag noch scroll-boundary-behavior. Er knüpfte an eine ältere Microsoft-Idee zur Scroll-Weitergabe an. Tab Atkins stellte die handfeste Frage: Wenn der obere oder untere Rand erreicht ist, darf die Scrollabsicht entkommen? Simon Fraser brachte das Festhalten eines Scrollziels während einer Geste zur Sprache und warnte davor, Nutzer in einer Seite einzusperren. Ein Chatfenster am Ende seiner Nachrichten war ausdrücklich ein Beispiel. Die Arbeitsgruppe sah Sinn in einer Spezifikation, vertagte aber die genaue Entscheidung. Selbst die Namen waren noch Baustelle.

Im Januar 2018 bat Herausgeber Majid Valipour darum, das beim WICG entwickelte overscroll-behavior in die Entwürfe der CSS-Arbeitsgruppe zu übernehmen. Sein Antrag hält damalige Browserfortschritte fest. Entscheidend ist die neue Verhandlungsebene: Aus einem Kniff für ein einzelnes Widget wurde eine gemeinsame Anweisung darüber, wann ein Browser eine Bewegung weiterreichen darf. Der Seitenautor setzt die Grenze; die Bewegungsphysik bleibt beim Browser.

Die W3C-Veröffentlichungschronik datiert den ersten öffentlichen Entwurf auf den 6. Juni 2019. Er unterscheidet zwischen lokalen Randaktionen, etwa einem sichtbaren Nachfedern im Chat, und nicht lokalen Aktionen, etwa dem Scrollen eines Vorfahren oder einer Navigation. auto belässt das gewohnte Verhalten. contain sperrt die nicht lokalen Aktionen und kann das lokale Signal erhalten. none nimmt auch dieses Signal weg. Für einen Chat kann das kleine Nachfedern ein höfliches „Hier endet es“ sein; eine endlos nachladende Liste mag einen stillen Rand bevorzugen. Beides unter denselben Schalter zu zwingen wäre eine seltsame Sparmaßnahme.

Es gibt noch eine zweite Grenze: die Richtung. Physische x- und y-Achsen passen nicht zwangsläufig zur logischen Laufrichtung jedes Textes. Bei der Berliner Sitzung im April 2018 beschloss die Arbeitsgruppe zusätzliche block- und inline-Eigenschaften. Damit kann die Regel der Schreibrichtung folgen. Wer eine Seite in mehreren Schriftkulturen veröffentlicht, merkt schnell, wie kurzsichtig eine nur auf eine Bildschirmrichtung zugeschnittene Lösung wäre.

Der Entwurf zeigt eine feste Seitennavigation, einen eigenen Pull-to-Refresh-Mechanismus und eine unendlich wachsende Liste. Jeder Rand hat einen anderen Auftrag. Beim Chat aus unserem Beispiel ist der Auftrag angenehm schlicht: Die letzte Nachricht darf die letzte sein, ohne dass gleich der ganze Artikel die Flucht ergreift.