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à:
Introduzione al posizionamento fisso
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.