On pose un position: absolute sur un tooltip, on ajuste le z-index, et le tooltip passe derrière un bandeau qui n’a même pas de z-index déclaré. Le réflexe classique consiste à monter la valeur à 9999. Le vrai problème se situe ailleurs : dans le contexte d’empilement que le navigateur a créé sans qu’on le lui demande.
Contexte d’empilement invisible : la source réelle des conflits de z-index
Un z-index ne fonctionne qu’à l’intérieur du contexte d’empilement (stacking context) auquel l’élément appartient. Deux éléments situés dans des contextes différents ne se comparent jamais directement entre eux, quelle que soit la valeur numérique attribuée.
Lire également : Storiesig gratuit : jusqu'où peut-on aller sans payer pour voir les stories Insta ?
Le piège terrain le plus fréquent : un parent porte un transform, un filter ou un opacity inférieur à 1. Ces propriétés créent automatiquement un nouveau contexte d’empilement, même sans aucun z-index déclaré. Un simple transform: translateZ(0) appliqué pour forcer l’accélération GPU suffit à enfermer tous les enfants positionnés dans un contexte isolé.
Concrètement, si une modale en position: absolute avec z-index: 1000 est imbriquée dans un conteneur qui porte filter: blur(0), elle ne passera jamais devant un bandeau situé en dehors de ce conteneur, même avec un z-index à 1. C’est le contexte du parent qui est comparé, pas celui de l’enfant.
A lire aussi : Geckodesign.fr, un studio WordPress humain pour un site qui vous ressemble
Identifier un contexte parasite dans l’inspecteur
Dans les DevTools de Chrome ou Firefox, on sélectionne l’élément récalcitrant et on remonte l’arbre DOM en cherchant quel ancêtre porte une propriété génératrice de contexte. Les suspects habituels :
transformavec n’importe quelle valeur autre quenone, y compristranslate(0)ouscale(1)filter, même à valeur neutre commeblur(0)oudrop-shadow(0 0 0 transparent)opacitystrictement inférieur à 1, par exempleopacity: 0.99appliqué pour une transitionwill-changepointant surtransform,opacityoufilter
Une fois l’ancêtre identifié, on a deux options : retirer la propriété fautive si elle n’est pas nécessaire, ou sortir l’élément positionné de cette branche du DOM.
Absolute CSS positioning dans un layout flex ou grid : le containing block change
Les anciens tutoriels répètent la même règle : un élément en position: absolute se positionne par rapport au premier ancêtre portant position: relative (ou absolute, ou fixed). C’est vrai, mais incomplet dans les layouts modernes.
Depuis la clarification de CSS Positioned Layout Level 3, un item flex ou grid peut lui-même devenir le containing block d’un enfant en absolute. Si on place un position: relative sur un item de grille, l’enfant absolute se cale sur les limites de cet item, pas sur celles du conteneur grid parent.
Le cas terrain typique : on veut un badge en absolute dans le coin d’une carte affichée via CSS Grid. On ajoute position: relative sur la carte (l’item grid), puis position: absolute; top: 0; right: 0 sur le badge. Le badge respecte les limites de la carte. Sans le relative sur l’item, il remontera jusqu’au prochain ancêtre positionné, souvent le conteneur grid lui-même, et le badge se retrouvera dans un coin inattendu.
Piège du conteneur flex avec overflow hidden
Un conteneur flex avec overflow: hidden masquera visuellement un enfant absolute qui dépasse, même si cet enfant a un z-index élevé. Le z-index ne contourne pas le clipping. Si un tooltip ou un dropdown doit dépasser les limites de son conteneur flex, il faut soit retirer le overflow: hidden, soit rendre l’élément via un autre point du DOM.
Portals et découplage DOM pour les overlays complexes
Quand on travaille avec React, Vue ou un design system comme Material 3, les composants de superposition (modales, menus, tooltips) sont rendus via des portals, c’est-à-dire injectés à la racine du document plutôt qu’à l’endroit logique dans l’arbre des composants. Ce pattern existe précisément pour éviter les conflits de stacking context hérités des parents.
En vanilla CSS, on peut reproduire ce principe manuellement. On place le conteneur de la modale juste avant la fermeture du <body>, avec un position: fixed ou absolute relatif au viewport. Aucun ancêtre ne viendra créer un contexte d’empilement parasite puisque le seul parent positionné est le body lui-même.
Les retours varient sur ce point selon la complexité du projet : pour une page statique avec un seul overlay, déplacer le markup suffit. Pour une application dynamique avec plusieurs couches superposées (modale, puis tooltip à l’intérieur de la modale, puis menu contextuel), le portal côté framework reste la solution la plus fiable.
Propriété isolation : forcer un stacking context propre sans effet secondaire
Plutôt que d’ajouter un transform: translateZ(0) pour créer un contexte d’empilement (ce qui peut déclencher des effets de rendu indésirables sur les sous-pixels), on dispose de la propriété isolation: isolate.
isolation: isolate crée un stacking context sans aucun effet visuel collatéral. On l’applique sur un composant dont on veut que les z-index internes ne fuient pas vers l’extérieur. Par exemple, un carrousel d’images avec des flèches de navigation en absolute et des z-index locaux : en posant isolation: isolate sur le wrapper du carrousel, on garantit que ces z-index ne viendront jamais interférer avec le header fixe ou d’autres composants de la page.
Stratégie d’échelle de z-index par couche
Plutôt que d’attribuer des z-index au hasard, on découpe l’interface en couches logiques via des custom properties CSS :
--z-base: 1pour le contenu standard (cartes, sections)--z-dropdown: 100pour les menus et sélecteurs--z-overlay: 200pour les modales et les panneaux latéraux--z-tooltip: 300pour les infobulles contextuelles--z-toast: 400pour les notifications flottantes
On référence ensuite z-index: var(--z-dropdown) dans chaque composant. Toute l’échelle est lisible en un seul fichier, et les conflits disparaissent parce que chaque couche a sa plage réservée.
La majorité des bugs de superposition en CSS ne viennent pas du z-index lui-même, mais d’un contexte d’empilement créé par une propriété anodine sur un parent. Avant d’augmenter une valeur de z-index, remonter l’arbre DOM dans l’inspecteur reste le geste le plus rentable. Et quand le projet grossit, une échelle de z-index centralisée combinée à isolation: isolate sur les composants autonomes évite de rejouer ce diagnostic à chaque nouveau composant.
