Affronta la tua posizione di atterraggio: appariscenti in WebKit

Eric Bidelman

position: sticky è un nuovo modo per posizionare gli elementi ed è concettualmente simile a position: fixed. La differenza è che un elemento con position: sticky si comporta come position: relative all'interno del suo elemento principale, fino a quando non viene raggiunta una determinata soglia di offset nell'area visibile.

Casi d'uso

Parafrasando la proposta originale di Edward O'Connor per questa funzionalità:

Nota: molti siti web hanno elementi che passano da in-flow a position: fixed, a seconda della posizione di scorrimento dell'utente. Questo viene spesso fatto per gli elementi di una barra laterale che l'autore della pagina vuole che siano sempre visibili mentre l'utente scorre, ma che si inseriscono in uno spazio della pagina quando si scorre verso l'alto. Alcuni esempi sono news.google.com (la barra laterale "Notizie principali") e yelp.com (mappa dei risultati di ricerca).

Introduzione al posizionamento fisso

LAUNCH DEMO

Aggiungendo semplicemente position: sticky (con prefisso del fornitore), possiamo indicare a un elemento di essere position: relative finché l'utente non scorre l'elemento (o il relativo elemento principale) fino a 15 pixel dalla parte superiore:

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

A top: 15px, l'elemento diventa fisso.

Per illustrare questa funzionalità in un contesto pratico, ho creato una DEMO che blocca i titoli dei blog mentre scorri.

Vecchio approccio: eventi di scorrimento

Finora, per ottenere l'effetto fisso, i siti configuravano gli ascoltatori di eventi scroll in JS. Utilizziamo questa tecnica anche nei tutorial di html5rocks. Su schermi di dimensioni inferiori a 1200 pixel, la barra laterale del sommario diventa position: fixed dopo un certo livello di scorrimento.

Ecco il metodo (ora obsoleto) per avere un'intestazione che si attacca alla parte superiore dell'area visibile quando l'utente scorre verso il basso e torna nella posizione originale quando l'utente scorre verso l'alto:

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

Provalo: http://output.jsbin.com/omanut/2/

È abbastanza facile, ma questo modello si rompe rapidamente se vuoi farlo per un insieme di nodi DOM, ad esempio ogni titolo <h1> di un blog mentre l'utente scorre.

Perché JS non è l'ideale

In generale, i gestori dello scorrimento non sono mai una buona idea. I clienti tendono a fare troppo lavoro e si chiedono perché la loro UI sia instabile.

Un altro aspetto da considerare è che sempre più browser stanno implementando lo scorrimento con accelerazione hardware per migliorare le prestazioni. Il problema è che, se sono attivi gli handler di scorrimento JS, i browser potrebbero passare a una modalità (software) più lenta. Ora non è più in esecuzione sulla GPU. Invece, torniamo alla CPU. Il risultato? Gli utenti percepiscono più scatti quando scorrono la pagina.

Pertanto, ha molto senso che questa funzionalità sia dichiarativa in CSS.

Assistenza

Purtroppo, non sono disponibili specifiche per questo problema. È stata proposta su www-style a giugno e ha appena fatto il suo debutto in WebKit. Ciò significa che non esiste una buona documentazione a cui fare riferimento. Tuttavia, tieni presente che, in base a questo bug, se vengono specificati sia left che right, left ha la precedenza. Analogamente, se vengono utilizzati contemporaneamente top e bottom, vince top.

Al momento è supportato Chrome 23.0.1247.0 e versioni successive (attuale Canary) e WebKit nightly.