Évolution de la propriété CSS position : la valeur sticky

**Bovino** · 19/09/2013, 17h43

Tous les développeurs Web sont supposés connaître la propriété CSS position.
Pour rappel, cette propriété permet de déterminer comment un élément HTML sera intégré dans le document.

Cette propriété accepte quatre valeurs :

static : c'est la valeur par défaut, un élément avec cette valeur sera intégré dans le flux normal ;
relative : permet de positionner l'élément en fonction de l'emplacement qu'il aurait dû avoir dans le flux ;
absolute : permet de positionner l'élément par rapport à son ancêtre positionné (dont la valeur de position est différente de static) le plus proche ;
fixed : permet de positionner l'élément à un emplacement fixe de la fenêtre d'affichage (l'élément ne se déplace pas lors du scroll).

Si ces quatre valeurs sont largement suffisantes pour la plupart des pages Web, certaines pratiques apparaissent et se généralisent qui justifieraient d'étendre les valeurs possibles.

Parmi ces pratiques, celle consistant à intégrer un élément dans la page qui suit le défilement tant qu'il est visible puis se bloque à une position limite est de plus en plus répandue (sticky elements). Pour en voir un exemple, regardez comment se comporte la table des matières dans les articles de developpez.com.
Pour réaliser cela, nous sommes actuellement obligés d'utiliser JavaScript et de modifier la propriété position en fonction de la valeur du scroll.

C'est pour cela que les développeurs de Chrome ont eu l'idée d'ajouter une valeur possible pour la propriété position, la valeur sticky.

Exemple :

Code css :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
#sticky_element{
  position: -webkit-sticky;
  position: -moz-sticky;
  position: -ms-sticky;
  position: -o-sticky;
  position: sticky;
  top: 15px;
}

Dans cet exemple, l'élément dont l'id est sticky_element va se déplacer en même temps que la page tant qu'il sera à plus de 15 pixels du haut de la page, puis se figera pour rester toujours visible.
Notez l'utilisation des préfixes vendeurs et leur ordre. Les préfixes vendeurs permettent d'utiliser des fonctionnalités (CSS ou JavaScript) qui sont encore expérimentales. Comme le comportement de ces fonctionnalités est susceptible d'évoluer en fonction de leur implémentation, on déclare toujours la propriété non préfixée (donc définitive et supposée conforme à la spécification) en dernier afin que celle-ci écrase les précédentes si elle est disponible.

Malheureusement, le support navigateur est quasiment inexistant à l'heure actuelle et elle ne fait pas partie des spécifications du W3C.
La propriété est bien reconnue en version préfixée pour Chrome et Safari sur iOS 6, mais pour le reste, elle n'est supportée que par les versions de développement de Chrome (Canary) et Firefox (Nightly).
Cependant, cela reste une belle perspective pour un futur relativement proche.

Que pensez-vous de cette évolution ?

S'agit-il selon vous d'un gadget ou d'une évolution intéressante ?

Quel autre type d'amélioration aimeriez-vous voir apparaitre ?

Sources : RedTeamDesign - HTML5Rocks

**Jarodd** · 19/09/2013, 19h18

Notez l'utilisation des préfixes vendeurs et leur ordre. Les préfixes vendeurs permettent d'utiliser des fonctionnalités (CSS ou JavaScript) qui sont encore expérimentales. Comme le comportement de ces fonctionnalités est susceptible d'évoluer en fonction de leur implémentation, on déclare toujours la propriété non préfixée (donc définitive et supposée conforme à la spécification) en dernier afin que celle-ci écrase les précédentes si elle est disponible.

Alors pourquoi la propriété non-préfixée n'apparaît pas dans l'exemple ?

**Bovino** · 19/09/2013, 19h21

Oh... la belle boulette !

Bonne remarque !

Je l'avais juste oubliée, je viens de la rajouter !

**rodolphebrd** · 19/09/2013, 21h27

Ce sera une évolution encourageante notamment pour résoudre les problèmes de sticky footer en fixant top à 100%.

Testé sur MAC depuis:

Safari 6 : NOK
~~Chrome 29 : NOK~~
~~Chrome Canary 31 : NOK~~
Nightly : OK

Ce lien permet de vérifier si votre navigateur supporte cette propriété (même préfixée).

Edit : Correction des tests suite à la remarque de Bovino (chrome:flags)

**sooprano** · 19/09/2013, 23h49

je vois que c'est une bonne initiative, vraiment dommage

que la plus part des navigateur ne connaissent pas cette propriété

**jv2759** · 20/09/2013, 10h51

Malheureusement, le support navigateur est quasiment inexistant à l'heure actuelle et elle ne fait pas partie des spécifications du W3C.

Que pensez-vous de cette évolution ?

Évolution ou régression, cela me rappel les grandes heure de IE ou chacun fait ce qu'il veux dans son coin. Officiellement pour apporter de nouvelle fonction, mais surtout pour forcer à développer pour un navigateur et donc pousser les utilisateur à utiliser ce navigateur.

**Bovino** · 20/09/2013, 11h03

Non, ce n'est pas exactement cela.

Quand je dis qu'elle ne fait pas partie des spécifications du W3C, cela ne veut pas dire que ce n'est pas envisagé. Cela a même été proposé dès juin 2012.
Ensuite, devenir une spécification demande un cheminement assez long ce qui n'empêche pas les navigateurs de commencer l'implémentation en parallèle, ce qui permet de faire remonter les retours d'expérience et d'affiner ce que sera la spécification. Donc ce n'est en rien le retour de la guerre des navigateurs des années 90 avec Netscape et IE.

**Guildem** · 20/09/2013, 11h18

comme jv2759 je ne sais pas si on peut voir ça comme une évolution positive, vu que c'est un navigateur (enfin, son moteur) qui l'implémente par envie...

le W3C est un escargot apathique, mais le respect d'une norme est important pour éviter de se retrouver avec des disparités entre navigateurs, comme à l'époque d'IE.

Edit: arf, j'ai pas vu ton message Bovino. une proposition ne veut pas dire grand chose tant qu'elle n'est pas validée par le W3C et qu'il n'y a pas au moins un draft de fait.

**Jean-Georges** · 20/09/2013, 12h16

Il n'y a rien de plus désagréable que les éléments fixes sur un site, surtout quand ils affichent une publicité. Très mauvaise idée.

**rodolphebrd** · 20/09/2013, 12h19

Il y a une différence entre Sticky et fixed et leur utilisation ne se limite heureusement pas à placer des messages publicitaires gênants.

**Bovino** · 20/09/2013, 14h46

Envoyé par rodolphebrd

Chrome : NOK

Pour Chrome, il faut aller dans chrome:flags et activer l'option Activer les fonctionnalités expérimentales de Web Platform.

**kOrt3x** · 20/09/2013, 15h43

Envoyé par rodolphebrd

Ce sera une évolution encourageante notamment pour résoudre les problèmes de sticky footer en fixant top à 100%.

Testé sur MAC depuis:

Safari 6 : NOK
Chrome 29 : NOK
Chrome Canary 31 : NOK
Nightly : OK

Ce lien permet de vérifier si votre navigateur supporte cette propriété (même préfixée).

Safari 7 le supporte déjà.

**rodolphebrd** · 20/09/2013, 16h36

Merci Bovino pour l'info, je ne connaissais pas.

Donc :

Chrome 29 : OK
Chrome Canary 31 : OK

kOrt3x : J'attends la mise à jour.

Invité · 20/09/2013, 17h51

ca reste quand même un simple effet c'est comprehensible que ça ne soit pas normalisé on n'est pas sur quelque chose de global au niveau du positionnement d’élément. et il est vrais que ca fait pensé a ie a sa grande époque

**Zefling** · 20/09/2013, 22h11

Envoyé par Jean-Georges

Il n'y a rien de plus désagréable que les éléments fixes sur un site, surtout quand ils affichent une publicité. Très mauvaise idée.

Actuellement c'est fait par JS et ça reste fixe dans un cadre, contrairement à fixed. D'ailleurs fixed est très utilepour faire de éléments d'interfaces : menu ou admin.

**LSMetag** · 21/09/2013, 12h24

Beurk ! J'imagine que la première utilisation qui en sera faite sera de coller des pubs gênantes. Ben oui, ils font ch... ces gens qui utilisent NoScript...

**Zefling** · 22/09/2013, 00h29

Envoyé par LSMetag

Beurk ! J'imagine que la première utilisation qui en sera faite sera de coller des pubs gênantes. Ben oui, ils font ch... ces gens qui utilisent NoScript...

Ça changera pas le fait que le pub sont appelé par un script d'un autre domaine. Adblock marche très bien pour ça.