Combien de projets embarquent encore Popper.js, Floating UI ou une lib maison de 200 lignes juste pour coller un tooltip au bon endroit ? Pendant des années, positionner un élément par rapport à un autre — dropdown, tooltip, popover, menu contextuel — obligeait à calculer soi-même les coordonnées en JavaScript, à écouter le scroll et le resize, et à gérer manuellement les collisions avec les bords du viewport.

CSS Anchor Positioning change ça. C'est du CSS pur qui permet d'« attacher » un élément à un autre — l'ancre — puis de définir sa position et des positions de repli quand ça déborde de l'écran. La fonctionnalité est aujourd'hui utilisable en production : elle est supportée par Chrome 125+, Edge 125+, Firefox 131+ et Safari 18.2+, ce qui couvre environ 88 à 91 % du trafic mondial mi-2026. Certaines fonctionnalités avancées (niveau 2 de la spec, notamment le comportement fin de position-try) restent pour l'instant limitées aux navigateurs Chromium.

Dans cet article, on regarde comment ça fonctionne concrètement, comment le combiner avec l'attribut popover natif pour se passer complètement d'une lib JS de positionnement, et comment le déployer dès maintenant avec un fallback propre pour les navigateurs qui ne suivent pas encore.

Le problème que ça résout

Avant Anchor Positioning, positionner un tooltip au-dessus d'un bouton demandait typiquement : un appel à getBoundingClientRect() sur le déclencheur, un calcul manuel des coordonnées, un position: fixed avec des top/left injectés en JS, des listeners sur scroll et resize pour repositionner en continu, et une logique de détection de collision pour retourner l'élément quand il sort de l'écran. C'est exactement ce que font Popper.js et son successeur Floating UI — des libs solides, mais qui ajoutent du poids au bundle et une dépendance à maintenir pour un problème que le navigateur peut désormais résoudre nativement.

L'attribut HTML popover, lui, réglait déjà une partie du problème : affichage/masquage, fermeture avec Échap, fermeture au clic extérieur (« light dismiss »), et rendu dans le « top layer » du navigateur pour éviter les soucis de z-index. Mais il ne disait rien sur où l'élément devait apparaître à l'écran. Anchor Positioning comble exactement ce vide.

La mécanique de base : anchor-name et position-anchor

Le principe tient en deux propriétés. On donne un nom d'ancre à l'élément déclencheur avec anchor-name (la valeur doit commencer par deux tirets, comme une variable CSS), puis on relie l'élément positionné à cette ancre avec position-anchor :

/* L'élément déclencheur devient une ancre */
.bouton-info {
  anchor-name: --ancre-info;
}

/* Le tooltip se positionne par rapport à l'ancre */
.tooltip {
  position: fixed;
  position-anchor: --ancre-info;
  top: anchor(bottom);
  left: anchor(center);
  translate: -50% 0;
  margin-top: 8px;
}

La fonction anchor() lit les bords de l'ancre (top, bottom, left, right, center...) et les injecte dans les propriétés d'inset du tooltip. Pas de getBoundingClientRect(), pas de listener de scroll : le navigateur recalcule automatiquement la position à chaque changement de layout.

position-area : le placement sans faire le calcul soi-même

Pour les cas courants (au-dessus, en dessous, à gauche, centré...), la propriété position-area évite même d'écrire la fonction anchor(). Elle fonctionne comme une grille de 3x3 autour de l'ancre, avec des mots-clés comme top, bottom, left, right et center :

.tooltip {
  position: fixed;
  position-anchor: --ancre-info;
  position-area: top center; /* au-dessus, centré horizontalement */
  margin-bottom: 8px;
}

C'est nettement plus lisible qu'une combinaison de anchor(), et ça suffit pour la grande majorité des tooltips, menus et popovers d'interface.

position-try-fallbacks : la gestion du débordement, gratuite

La vraie difficulté des libs de positionnement JS, c'est la gestion des collisions avec le viewport : que se passe-t-il quand le tooltip placé au-dessus du bouton n'a plus de place parce que le bouton est tout en haut de l'écran ? Floating UI appelle ça le « flip » et le « shift ». Anchor Positioning le fait nativement avec position-try-fallbacks :

.tooltip {
  position: fixed;
  position-anchor: --ancre-info;
  position-area: top center;
  position-try-fallbacks: flip-block, flip-inline;
}

Si le placement par défaut (au-dessus) fait sortir l'élément de l'écran, le navigateur essaie automatiquement flip-block (basculer en dessous), puis flip-inline (basculer latéralement) si nécessaire. On peut aussi définir des positions de repli personnalisées avec @position-try pour des cas plus spécifiques qu'un simple flip.

anchor-size() : dimensionner par rapport à l'ancre

Une quatrième fonction mérite d'être connue : anchor-size(). Elle permet de dimensionner l'élément positionné en fonction de la largeur ou de la hauteur de son ancre, plutôt que de sa position. Utile par exemple pour qu'un menu déroulant fasse exactement la même largeur que le champ de saisie auquel il est rattaché :

.menu-deroulant {
  position-anchor: --champ-recherche;
  position-area: bottom center;
  width: anchor-size(width);
}

Là encore, tout ça se met à jour tout seul si l'ancre change de taille — au redimensionnement de la fenêtre, par exemple — sans code JavaScript pour recalculer quoi que ce soit.

Le duo complet : anchor positioning + popover natif

C'est en combinant les deux API que le remplacement d'une lib JS devient réaliste. L'attribut popover gère le cycle de vie (ouverture, fermeture, accessibilité, top layer), Anchor Positioning gère le placement :

<button popovertarget="info-popover" style="anchor-name: --ancre-info">
  En savoir plus
</button>

<div id="info-popover" popover style="
  position-anchor: --ancre-info;
  position-area: top center;
  position-try-fallbacks: flip-block;
">
  Contenu du popover, positionné automatiquement
  au-dessus du bouton, avec repli si besoin.
</div>

Sur Chrome et Edge récents, l'association entre un bouton popovertarget et son popover crée même une ancre implicite automatiquement, sans avoir à écrire anchor-name à la main. C'est une commodité en plus, pas un prérequis — le code ci-dessus fonctionne partout où Anchor Positioning est supporté.

Adopter ça en prod aujourd'hui

Avec un support à 88-91 % du trafic mondial mi-2026, la question n'est plus « est-ce que je peux l'utiliser ? » mais « comment je gère les 10 % restants ? ». Deux approches raisonnables :

Détection de fonctionnalité avec @supports : on fournit un positionnement de secours simple (par exemple un position: absolute statique, moins précis mais fonctionnel) pour les navigateurs qui ne comprennent pas anchor-name.
Dégradation gracieuse plutôt que polyfill : pour un tooltip ou un popover d'aide, un léger décalage de position sur un navigateur minoritaire n'est pas un bug bloquant. Ça évite de charger un polyfill JS uniquement pour compenser un cas marginal.

.tooltip {
  position: fixed;
  top: 100%;
  left: 0;
}

@supports (anchor-name: --test) {
  .tooltip {
    position-anchor: --ancre-info;
    position-area: top center;
    position-try-fallbacks: flip-block;
  }
}

Attention à un point précis : le comportement de repli via @position-try et les fallbacks personnalisés demandent Safari 18.4+ pour un support complet, même si le placement de base fonctionne dès Safari 18.2 sur les trois moteurs principaux. Si ton produit a une part significative d'utilisateurs Safari, teste explicitement le comportement de flip sur les versions que tu cibles avant de retirer ta lib JS existante.

Par où commencer

Ne migre pas tout d'un coup. Les tooltips et popovers d'aide contextuelle sont le terrain le plus sûr pour commencer : l'impact d'un léger écart de positionnement y est minime. Les menus de navigation complexes ou les datepickers, plus sensibles au pixel près, peuvent attendre que le support des fallbacks personnalisés se stabilise sur tous les moteurs.

En résumé

Anchor Positioning + popover couvrent aujourd'hui ce qu'une lib comme Floating UI fait en JS : ancrage, placement relatif, gestion des débordements, et cycle de vie d'affichage — le tout nativement, sans bundle supplémentaire, recalculé automatiquement par le moteur de rendu à chaque changement de layout. Pour un nouveau composant de type tooltip ou popover, commence directement en CSS natif avec un fallback @supports ; pour un composant existant qui dépend d'une lib JS, mesure d'abord la part de ton trafic sur les navigateurs non supportés avant de décider si la migration vaut le coup dès maintenant.

CSS Anchor Positioning : la fin des libs JS de tooltips ?