Affronta la tua posizione di atterraggio: appariscenti in WebKit

Eric Bidelman

Twitter GitHub Homepage

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

Casi d'uso

Parafrasi tratta dalla proposta originale di Edward O'Connor riguardo a questa funzionalità:

Nota: molti siti web presentano elementi che si alternano tra flussi in entrata e position: fixed, a seconda della posizione di scorrimento dell'utente. Questa operazione viene spesso eseguita per gli elementi di una barra laterale che l'autore della pagina vuole essere sempre visibile mentre l'utente scorre, ma che si inserisce in uno spazio della pagina quando viene fatto scorrere verso l'alto. Esempi validi sono news.google.com (la barra laterale "Notizie principali") e yelp.com (mappa dei risultati di ricerca).

Introduzione del posizionamento fisso

DEMO DEL LANCIO

Se aggiungi semplicemente position: sticky (con prefisso del fornitore), possiamo impostare un elemento come position: relative finché l'utente non scorre l'elemento (o l'elemento principale) a 15 px dal bordo superiore:

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

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

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

Approccio precedente: eventi di scorrimento

Finora, per ottenere l'effetto persistente, i siti hanno configurato i listener di eventi scroll in JavaScript. In realtà utilizziamo questa tecnica anche nei tutorial HTML5rocks. Su schermi di dimensioni inferiori a 1200 px, la barra laterale del nostro sommario diventa position: fixed dopo un certo periodo di scorrimento.

Di seguito è riportato il metodo (che oggi si utilizza come metodo precedente) per avere un'intestazione fissata nella parte superiore dell'area visibile quando l'utente scorre verso il basso e riposizionata 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 semplice, ma questo modello si rompe rapidamente se vuoi eseguire questa operazione per un gruppo di nodi DOM, ad esempio ogni titolo <h1> di un blog mentre l'utente scorre.

Perché JS non è l'ideale

In generale, i gestori di scorrimento non sono mai una buona idea. Gli utenti tendono a lavorare troppo e si chiedono perché la loro interfaccia utente sia poco chiara.

Un altro fattore da considerare è che sempre più browser stanno implementando lo scorrimento con accelerazione hardware per migliorare le prestazioni. Il problema è che sui gestori di scorrimento JS sono in esecuzione, i browser potrebbero tornare in una modalità più lenta (software). Ora non utilizziamo più la GPU. Al contrario, siamo tornati sulla CPU. Risultato? L'utente percepisce più jank quando scorre la pagina.

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

Assistenza

Purtroppo non esistono specifiche per questo tipo di dispositivo. È stato proposto su www-style a giugno ed è appena approdato in WebKit. Ciò significa che non c'è una buona documentazione a cui puntare. Una cosa da notare tuttavia, in base a questo bug, se sono specificati sia left che right, vince left. Allo stesso modo, se top e bottom vengono utilizzati contemporaneamente, vince top.

Al momento il supporto è Chrome 23.0.1247.0 e versioni successive (versione canary attuale) e WebKit notturno.