Pozycja przyklejona – elementy docelowe w WebKit

Eric Bidelman

Twitter GitHub Strona główna

position: sticky to nowy sposób pozycjonowania elementów i podobny koncepcyjnie do position: fixed. Różnica polega na tym, że element z atrybutem position: sticky zachowuje się w elemencie nadrzędnym tak jak position: relative, dopóki w widocznym obszarze nie zostanie osiągnięty określony próg przesunięcia.

Przypadki użycia

Parafrazowanie z oryginalnej propozycji tej funkcji Edwarda O’Connora:

Uwaga: wiele witryn zawiera elementy, które naprzemienne są „w tekście” i „position: fixed” w zależności od pozycji przewijania. Często zdarza się to w przypadku elementów na pasku bocznym, które autor strony chce być zawsze widoczny podczas przewijania, ale których boks znajduje się w miejscu na stronie po przewinięciu do góry. Dobre przykłady to news.google.com (pasek boczny „Najważniejsze artykuły”) i yelp.com (mapa wyników wyszukiwania).

Przedstawiamy pozycjonowanie przyklejone

URUCHOM PREZENTACJĘ

Wystarczy, że dodasz position: sticky (z prefiksem dostawcy) element, który ma mieć wartość position: relative, dopóki użytkownik nie przewinie elementu (lub jego elementu nadrzędnego) tak, aby znajdował się 15 pikseli od góry:

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

W momencie top: 15px element zostaje ustalony.

Aby zilustrować tę funkcję w praktyce, przygotowaliśmy DEMO, który zapamiętuje tytuły bloga podczas przewijania.

Stare podejście: zdarzenia przewijania

Aby uzyskać efekt przyklejenia, witryny konfiguruje na razie odbiorniki zdarzeń scroll w języku JS. Używamy tej techniki również w samouczkach poświęconych html5rocks. Na ekranach mniejszych niż 1200 pikseli pasek boczny spisu treści zmienia się na position: fixed po pewnym czasie przewijania.

Oto (obecnie stary sposób) nagłówek, który przykleja się do górnej części widocznego obszaru, gdy użytkownik przewija stronę w dół, a potem wróci na miejsce, gdy użytkownik przewinie w górę:

<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>

Wypróbuj: http://output.jsbin.com/omanut/2/

To dość proste, ale ten model szybko się rozkłada, jeśli ma to zastosowanie w przypadku kilku węzłów DOM, na przykład każdego tytułu bloga <h1> podczas przewijania.

Dlaczego JS nie jest idealny

Ogólnie moduły obsługi przewijania nigdy nie są dobrym pomysłem. Folksy zwykle wykonują zbyt wiele pracy i zastanawiają się, dlaczego ich interfejs użytkownika jest zbyt dziwny.

Warto też wziąć pod uwagę fakt, że coraz więcej przeglądarek stosuje sprzętowe przyspieszanie przewijania, by poprawić wydajność. Problem polega na tym, że w trakcie działania modułów obsługi przewijania JS przeglądarki mogą przełączyć się w wolniejszy tryb (oprogramowanie). Nie korzystamy już z GPU. Wracamy do procesora. Efekt? Użytkownicy zauważają więcej bałaganu podczas przewijania strony.

Z tego względu bardzo sensowne jest, by taka funkcja była deklaracyjna w CSS.

Pomoc

Niestety nie ma takiej specyfikacji. Została zaproponowana w stylu www w czerwcu i właśnie trafiła do WebKit. To oznacza, że nie ma odpowiedniej dokumentacji, do której można by wskazać dany problem. Trzeba jednak pamiętać, że według tego błędu jeśli określono zarówno left, jak i right, wygrywa left. Podobnie, jeśli używane są zasady top i bottom w tym samym czasie, wygrywa top.

Obecnie obsługiwane są przeglądarki Chrome 23.0.1247.0 (wersja Canary) i WebKit w nocy.