Jetzt landen! Position – fixierte Elemente in WebKit

Eric Bidelman

position: sticky ist eine neue Möglichkeit, Elemente zu positionieren, und ähnelt konzeptionell position: fixed. Der Unterschied besteht darin, dass sich ein Element mit position: sticky innerhalb seines übergeordneten Elements wie position: relative verhält, bis ein bestimmter Offset-Grenzwert im Darstellungsbereich erreicht wird.

Anwendungsfälle

Paraphrasierung des ursprünglichen Vorschlags von Edward O'Connor zu dieser Funktion:

Hinweis:Viele Websites haben Elemente, die je nach Scrollposition des Nutzers zwischen „in-flow“ und position: fixed wechseln. Dies wird häufig für Elemente in einer Seitenleiste verwendet, die beim Scrollen des Nutzers immer sichtbar sein sollen, sich aber in einen Bereich auf der Seite einfügen, wenn nach oben gescrollt wird. Gute Beispiele sind news.google.com (die Seitenleiste „Top-Nachrichten“) und yelp.com (Suchergebnissenkarte).

Einführung der fixierten Positionierung

DEMO DER MARKTEINFÜHRUNG

Durch einfaches Hinzufügen von position: sticky (Anfangszeichen des Anbieters) können wir festlegen, dass ein Element position: relative sein soll, bis der Nutzer das Element (oder sein übergeordnetes Element) so scrollt, dass es 15 Pixel vom oberen Bildschirmrand entfernt ist:

.sticky {
    position: -webkit-sticky;
    position: -moz-sticky;
    position: -ms-sticky;
    position: -o-sticky;
    top: 15px;
}

Bei top: 15px wird das Element fixiert.

Um diese Funktion in der Praxis zu veranschaulichen, habe ich eine DEMO zusammengestellt, in der Blogtitel beim Scrollen fixiert bleiben.

Alter Ansatz: Scroll-Ereignisse

Bisher wurde für den fixierten Effekt in JS ein scroll-Ereignis-Listener eingerichtet. Diese Technik verwenden wir auch in den html5rocks-Anleitungen. Auf Bildschirmen mit einer Größe von weniger als 1.200 px wird die Seitenleiste des Inhaltsverzeichnisses nach einem bestimmten Scrollen in position: fixed geändert.

Hier ist die (jetzt veraltete) Methode, um eine Überschrift zu erstellen, die oben im Darstellungsbereich bleibt, wenn der Nutzer nach unten scrollt, und wieder an ihre Position zurückkehrt, wenn der Nutzer nach oben scrollt:

<div class="header"></div>

<script>
var header = document.querySelector('.header');
var origOffsetY = header.offsetTop;

function onScroll(e) {
    window.scrollY >= origOffsetY ? header.classList.add('sticky') :
                                    header.classList.remove('sticky');
}

document.addEventListener('scroll', onScroll);
</script>

Jetzt ausprobieren: http://output.jsbin.com/omanut/2/

Das ist einfach genug, aber dieses Modell bricht schnell zusammen, wenn Sie dies für eine Reihe von DOM-Knoten tun möchten, z. B. für jeden <h1> Titel eines Blogs, während der Nutzer scrollt.

Warum JS nicht ideal ist

Scroll-Handler sind im Allgemeinen keine gute Idee. Die Leute neigen dazu, zu viel zu tun und sich dann zu fragen, warum ihre Benutzeroberfläche hakelig ist.

Außerdem wird in immer mehr Browsern das hardwaregestützte Scrollen implementiert, um die Leistung zu verbessern. Das Problem dabei ist, dass bei JS-Scroll-Handlern Browser in einen langsameren (Software-)Modus wechseln können. Jetzt wird die GPU nicht mehr verwendet. Stattdessen konzentrieren wir uns wieder auf die CPU. Das Ergebnis: Nutzer nehmen beim Scrollen auf Ihrer Seite mehr Ruckler wahr.

Daher ist es sinnvoll, diese Funktion in CSS deklarativ zu gestalten.

Support

Leider gibt es dafür keine Spezifikation. Sie wurde bereits im Juni auf www-style vorgeschlagen und ist jetzt in WebKit angekommen. Das bedeutet, dass es keine gute Dokumentation gibt, auf die verwiesen werden kann. Hinweis: Gemäß diesem Fehler hat left Vorrang, wenn sowohl left als auch right angegeben sind. Wenn top und bottom gleichzeitig verwendet werden, hat top Vorrang.

Derzeit wird Chrome 23.0.1247.0 und höher (aktuelle Canary-Version) sowie WebKit Nightly unterstützt.