position: sticky est une nouvelle façon de positionner des éléments. Son concept est semblable à position: fixed. La différence réside dans le fait 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
Reformulation de la proposition initiale d'Edward O'Connor concernant cette fonctionnalité:
Présentation du positionnement persistant
En ajoutant simplement position: sticky (préfixé par le fournisseur), nous pouvons indiquer qu'un élément est position: relative jusqu'à ce que l'utilisateur fasse défiler l'élément (ou son parent) pour qu'il soit à 15 pixels du haut:
.sticky {
position: -webkit-sticky;
position: -moz-sticky;
position: -ms-sticky;
position: -o-sticky;
top: 15px;
}
À top: 15px, l'élément est fixe.
Pour illustrer cette fonctionnalité dans un contexte pratique, j'ai créé une DÉMO qui affiche les titres des blogs 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 JavaScript. Nous utilisons également cette technique dans les tutoriels html5rocks. Sur les écrans de moins de 1 200 pixels, la barre latérale de table des matières passe à position: fixed après un certain temps de défilement.
Voici l'ancienne méthode, qui permet de conserver un en-tête en haut de la fenêtre d'affichage lorsque l'utilisateur fait défiler la page vers le bas, et de revenir en place lorsqu'il 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>
Essayer: http://output.jsbin.com/omanut/2/
C'est assez facile, mais ce modèle se décompose rapidement si vous souhaitez effectuer cette opération pour un ensemble de nœuds DOM, par exemple, chaque titre <h1> d'un blog lorsque l'utilisateur fait défiler la page.
Pourquoi JavaScript n'est pas idéal
En général, les gestionnaires de défilement ne sont jamais une bonne idée. Les utilisateurs populaires ont tendance à effectuer trop de travail et se demandent pourquoi leur interface utilisateur est saccadée.
Notez également que de plus en plus de navigateurs implémentent le défilement accéléré par le matériel pour améliorer les performances. Le problème est que lorsque les gestionnaires de défilement JS sont en cours d'exécution, les navigateurs peuvent revenir à un mode (logiciel) plus lent. Désormais, l'exécution n'est plus exécutée sur le GPU. Au lieu de cela, nous sommes de retour sur le CPU. Le résultat ? L'utilisateur perçoit plus d'à-coups lorsqu'il fait défiler la page.
Il est donc très logique qu'une telle caractéristique soit déclarative en CSS.
Assistance
Malheureusement, il n'y a pas de spécification pour celui-ci. Il a été proposé sur le type "www" en juin et vient d'être intégré dans WebKit. Cela signifie qu'il n'y a pas de bonne
documentation à laquelle faire référence. Notez toutefois que, selon ce bug, si left et right sont tous les deux spécifiés, left l'emporte. De même, si top et bottom sont utilisés en même temps, top gagne.
Chrome 23.0.1247.0+ (version actuelle de Canary) et WebKit sont actuellement compatibles tous les soirs.