position: sticky est une nouvelle façon de positionner des éléments. Il est conceptuellement semblable à position: fixed. La différence est qu'un élément avec position: sticky se comporte comme position: relative dans son parent, jusqu'à ce qu'un seuil de décalage donné soit atteint dans la fenêtre d'affichage.
Cas d'utilisation
Pour paraphraser la proposition d'origine d'Edward O'Connor pour cette fonctionnalité:
Présentation du positionnement persistant
En ajoutant simplement position: sticky (préfixe du fournisseur), nous pouvons indiquer à un élément d'être position: relative jusqu'à ce que l'utilisateur fasse défiler l'élément (ou son parent) à 15 pixels du haut:
.sticky {
position: -webkit-sticky;
position: -moz-sticky;
position: -ms-sticky;
position: -o-sticky;
top: 15px;
}
À top: 15px, l'élément devient fixe.
Pour illustrer cette fonctionnalité dans un contexte pratique, j'ai créé une DEMONSTRATION qui maintient les titres de blog lorsque vous faites défiler la page.
Ancienne approche: événements de défilement
Jusqu'à présent, pour obtenir l'effet persistant, les sites configuraient des écouteurs d'événements scroll en JS. Nous utilisons également cette technique dans les tutoriels html5rocks. Sur les écrans de moins de 1 200 px, la barre latérale de la table des matières est remplacée par position: fixed après un certain temps de défilement.
Voici l'ancienne méthode (désormais obsolète) permettant d'avoir un en-tête qui reste en haut de la fenêtre d'affichage lorsque l'utilisateur fait défiler la page vers le bas et qui revient à sa place lorsque l'utilisateur fait défiler la page vers le haut:
<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>
Essayez: http://output.jsbin.com/omanut/2/
C'est assez simple, mais ce modèle échoue rapidement si vous souhaitez le faire pour un grand nombre de nœuds DOM, par exemple pour chaque titre <h1> d'un blog lorsque l'utilisateur fait défiler la page.
Pourquoi le code JavaScript n'est-il pas idéal ?
En général, les gestionnaires de défilement ne sont jamais une bonne idée. Les gens ont tendance à faire trop de travail et à se demander pourquoi leur interface utilisateur est bancale.
Sachez également que de plus en plus de navigateurs implémentent le défilement accéléré par matériel pour améliorer les performances. Le problème est que, lorsque les gestionnaires de défilement JS sont en jeu, les navigateurs peuvent passer à un mode (logiciel) plus lent. Nous n'exécutons plus le code sur le GPU. Nous revenons au processeur. Résultat : Les utilisateurs perçoivent plus de saccades lors du défilement de votre page.
Il est donc tout à fait logique que cette fonctionnalité soit déclarative en CSS.
Assistance
Malheureusement, il n'existe pas de spécifications pour ce cas. Il a été proposé sur www-style en juin et vient tout juste d'arriver dans WebKit. Cela signifie qu'il n'existe pas de bonne documentation à laquelle faire référence. Notez toutefois que, selon ce bug, si left et right sont spécifiés, left prévaut. De même, si top et bottom sont utilisés en même temps, top l'emporte.
Chrome 23.0.1247.0 ou version ultérieure (Canary actuel) et WebKit nightly sont actuellement compatibles.