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