Un header fixé avec position: absolute ne scrolle pas avec la page. Un bouton sticky positionné en absolute se cale par rapport à son containing block, pas par rapport au viewport. Confondre ces deux mécanismes reste la source principale de bugs sur les barres de navigation et les call-to-action flottants.
Containing block et absolute positioning : la mécanique qui casse les headers
Un élément en position: absolute se positionne par rapport au premier ancêtre positionné (un parent déclaré en relative, absolute, fixed ou sticky), et non par rapport au parent direct dans le DOM. Quand aucun ancêtre n’est positionné, le containing block remonte jusqu’à l’élément racine.
A voir aussi : Quelle différence entre Google Drive et One Drive ?
Sur un header, cela produit un comportement trompeur. Le header semble fixé en haut de page au chargement, mais dès que l’utilisateur scrolle, il disparaît. Ce n’est pas un bug du navigateur : absolute retire l’élément du flux sans le lier au viewport.
Nous observons régulièrement ce problème en production quand un développeur ajoute un wrapper intermédiaire (un conteneur Grid ou Flex) avec position: relative sans réaliser que cela redéfinit le containing block du header. Le header se retrouve alors calé non plus par rapport au body, mais par rapport à ce wrapper, et son top: 0 ne correspond plus au haut de la fenêtre visible.
A lire également : Prix Wix : comparer coûts et avantages pour votre site internet!
Diagnostic rapide d’un containing block inattendu
- Ouvrir l’inspecteur, sélectionner l’élément absolute, et remonter les ancêtres jusqu’à trouver celui qui porte une valeur
positionautre questatic: c’est le containing block réel - Vérifier si un
transform,filterouwill-changeest appliqué sur un ancêtre, car ces propriétés créent aussi un nouveau containing block (comportement souvent ignoré) - Comparer les dimensions du containing block avec celles du viewport : si elles diffèrent, le positionnement
top/leftproduira un décalage
Position fixed et sticky : ce qui remplace absolute pour un header CSS persistant
position: fixed attache l’élément au viewport. Le header reste visible quel que soit le scroll, sans dépendre d’un ancêtre positionné. C’est le mécanisme adapté pour une barre de navigation persistante sur toute la page.
position: sticky combine le comportement statique et fixe. L’élément reste dans le flux jusqu’à ce que le scroll atteigne le seuil défini par top, puis il se colle. Nous recommandons sticky pour les headers de sections ou les sous-navigations contextuelles, et fixed pour le header principal.
Pourquoi sticky échoue silencieusement
Un élément sticky ne fonctionne que si son parent direct a une hauteur supérieure à celle de l’élément lui-même. Si le parent a overflow: hidden, overflow: auto ou overflow: scroll, le sticky est neutralisé sans aucun message d’erreur dans la console.
Un parent avec overflow autre que visible désactive le comportement sticky. Ce piège affecte particulièrement les layouts construits avec des conteneurs Grid ou Flex dont le scroll est géré au niveau d’un wrapper interne plutôt que du body.
Bouton sticky avec z-index : les collisions de stacking context en CSS Grid
Un bouton call-to-action flottant (type « Retour en haut » ou « Ajouter au panier ») nécessite un z-index suffisant pour rester au-dessus du contenu. Avec position: fixed, le z-index se résout dans le stacking context racine, ce qui simplifie la gestion.
Avec position: absolute, le z-index ne s’applique qu’au sein du stacking context créé par le containing block. Un bouton absolute avec z-index: 9999 peut se retrouver masqué par une section voisine qui crée son propre stacking context via opacity, transform ou isolation: isolate.
Stratégie de z-index pour les éléments persistants
La tendance actuelle consiste à combiner position fixed avec un z-index maîtrisé plutôt que de détourner absolute. En pratique, nous utilisons une échelle de z-index définie dans des custom properties CSS :
--z-header: 100pour le header principal--z-overlay: 200pour les modales et les drawers--z-sticky-btn: 150pour les boutons flottants, positionnés entre le header et les overlays--z-tooltip: 300pour les éléments éphémères de type tooltip ou toast
Cette approche évite les escalades de z-index et rend la hiérarchie visuelle explicite dans le code.
Accessibilité des boutons et headers fixés en CSS
Les éléments fixés avec absolute ou fixed créent des overlays partiels qui masquent du contenu interactif. Un bouton fixé peut recouvrir un lien ou un champ de formulaire sur les petits viewports, rendant ces éléments impossibles à atteindre au doigt ou au clavier.
Les recommandations récentes insistent sur la gestion du focus clavier pour les overlays : piéger la navigation Tab à l’intérieur d’un panneau ouvert, puis rendre le focus à l’élément déclencheur à la fermeture. Pour un bouton sticky simple, le point critique est de s’assurer qu’il ne masque pas le dernier élément focusable de la page.
Bonnes pratiques d’intégration accessible
Ajouter un padding-bottom au body (ou au conteneur principal) équivalent à la hauteur du bouton fixé évite que le contenu ne soit tronqué. Pour un header fixed, un padding-top sur le premier élément de contenu compense l’espace retiré du flux.
Utiliser aria-hidden="true" sur le contenu sous-jacent n’a de sens que pour les overlays modaux, pas pour un header persistant qui doit rester accessible en permanence. Confondre ces cas d’usage dégrade l’expérience des lecteurs d’écran.
Quand absolute reste le bon choix en CSS
Position absolute convient aux éléments qui ne doivent pas occuper d’espace dans le flux : badges de notification sur une icône, indicateurs visuels superposés, décorations graphiques. Pour ces cas, absolute est la réponse la plus propre, car l’élément se positionne précisément par rapport à un conteneur parent sans perturber le layout voisin.
Pour un header ou un bouton qui doit rester visible pendant le scroll, absolute est un détournement. Le fait que le header « fonctionne » au chargement initial masque un défaut structurel qui se révèle dès que la page scrolle ou que le layout se recalcule sur un viewport différent. Sticky et fixed existent précisément pour couvrir ces besoins, avec un modèle de positionnement prévisible et compatible avec les attentes des navigateurs modernes.
