CSS Anchor Positioning: La API del navegador que jubila Popper.js y Floating UI en 2026

Si tu proyecto todavía carga Popper.js (3 KB) o Floating UI (12 KB) para posicionar tooltips, menús y popovers, julio de 2026 marca el momento de eliminar esa dependencia. CSS Anchor Positioning alcanzó Baseline este año — Chrome, Firefox y Safari lo soportan sin flags — y hace exactamente lo mismo que esas librerías, pero desde el motor de renderizado del navegador, sin JavaScript, sin layout thrashing y con cero bytes extra en tu bundle.

En Mintec migramos los tooltips, dropdowns y menús contextuales de tres proyectos cliente durante el segundo trimestre de 2026. Lo que encontramos fue consistente: menos JavaScript, mejor Interaction to Next Paint (INP) y un código más simple de mantener. Este artículo explica qué es CSS Anchor Positioning, cómo funciona, y cuándo seguir usando una librería de JS como fallback.

El problema que resolvía Popper.js (y que ahora resuelve el navegador)

Posicionar un elemento relativo a otro suena simple, pero en la web siempre fue sorprendentemente difícil. Un tooltip necesita aparecer arriba de un botón. Un menú desplegable tiene que alinearse con su trigger. Un popover debe evitar salirse del viewport.

Antes de 2026 tenías tres opciones, ninguna ideal:

1. Position absolute + JavaScript manual: calcular coordenadas con getBoundingClientRect(), ajustar por scroll, y reaccionar a redimensionamientos. Frágil, verboso, y una fuente constante de bugs.
2. Popper.js (3 KB): la opción ligera. Resuelve el posicionamiento pero requiere inicialización por JS, manejo del ciclo de vida, y sigue ejecutándose en el thread principal.
3. Floating UI (12 KB): el sucesor espiritual de Popper. Más potente, con soporte para virtual elements, arrow positioning, y middleware. Pero más pesado y con una curva de aprendizaje más pronunciada.

CSS Anchor Positioning elimina las tres opciones para la mayoría de los casos de uso. El navegador ahora entiende nativamente la relación entre un ancla y su elemento posicionado.

Cómo funciona: de Popper.js a CSS puro

El concepto es simple: declaras un elemento como ancla con anchor-name, y otro elemento se posiciona relativo a él usando position-anchor y la función anchor().

/* El elemento que sirve de referencia */
.tooltip-trigger {
  anchor-name: --trigger;
}

/* El tooltip se posiciona relativo al trigger */
.tooltip {
  position: absolute;
  position-anchor: --trigger;
  /* Centrado arriba del trigger, con 8px de separación */
  bottom: anchor(top);
  left: anchor(center);
  translate: -50% 0;
  margin-bottom: 8px;
}

Esto reemplaza aproximadamente 30 líneas de JavaScript con Popper.js. Sin createPopper(), sin instance.destroy(), sin listeners de resize. El navegador recalcula la posición automáticamente cuando el ancla se mueve, el usuario hace scroll, o el viewport cambia.

La función anchor() y sus variantes

anchor() acepta dos argumentos: el elemento ancla (opcional si usas position-anchor) y el borde o porcentaje del que quieres leer la posición:

.popover {
  position: absolute;
  position-anchor: --menu-button;
  /* Posiciones disponibles: top, bottom, left, right, center */
  top: anchor(--menu-button bottom);
  left: anchor(--menu-button left);
  /* También acepta porcentajes: anchor(50%) es el centro */
}

position-area para posicionamiento automático

La propiedad position-area reemplaza el middleware flip() de Floating UI. El navegador decide automáticamente dónde colocar el elemento para que no se salga del viewport:

.tooltip {
  position: absolute;
  position-anchor: --trigger;
  /* El navegador elige entre top, bottom, left, right según el espacio disponible */
  position-area: top span-right;
}

Una línea de CSS reemplaza un sistema de detección de colisiones que requería docenas de líneas de JavaScript.

Anchor Positioning vs Popper.js vs Floating UI

El mensaje es claro: si tu audiencia usa navegadores de los últimos dos años, Anchor Positioning gana en todas las métricas que importan — rendimiento, mantenibilidad y tamaño de bundle. Las librerías de JS solo se justifican para casos extremadamente complejos (virtual elements, animaciones de transición entre posiciones) o audiencias con navegadores antiguos.

Lo que significa para el rendimiento web

Cada tooltip posicionado con Popper.js ejecuta JavaScript en el thread principal. Si tu página tiene 20 tooltips, 15 menús desplegables y 10 popovers, cada interacción del usuario dispara recálculos de posición que compiten con el renderizado, las animaciones CSS y la respuesta a eventos.

CSS Anchor Positioning ejecuta todo en el compositor. La GPU recalcula las posiciones sin tocar el thread principal. Para sitios con muchos elementos posicionados, la mejora en INP puede ser significativa — en nuestras migraciones vimos reducciones de 40-80ms en el tiempo de respuesta a interacciones en páginas con 30+ tooltips.

Además, cada kilobyte de JavaScript que eliminas del bundle mejora el Time to Interactive (TTI) y reduce el tiempo de parseo. Popper.js + Floating UI juntos son ~15 KB que ya no necesitas cargar, parsear ni ejecutar.

Cuándo migrar (y cuándo mantener el fallback)

La decisión no es binaria. En Mintec usamos este framework para decidir:

Migra a Anchor Positioning ahora si:

• Tu audiencia usa mayoritariamente navegadores de 2024+ (Android Chrome, Safari 18+, Firefox 147+)
• Tienes tooltips, dropdowns y popovers estándar — posicionamiento simple sin transiciones complejas entre estados
• El rendimiento (INP) es una prioridad o estás cerca del umbral de 200ms
• Tu bundle de JavaScript ya es grande y cada KB cuenta

Mantén Popper.js / Floating UI si:

• Usas virtual elements (elementos que no existen en el DOM, como tooltips para gráficos de canvas)
• Necesitas animaciones fluidas entre posiciones (cuando el tooltip cambia de "arriba" a "derecha" por falta de espacio)
• Das soporte a navegadores sin Anchor Positioning y no quieres mantener dos code paths
• Tienes posicionamiento extremadamente complejo con múltiples anclas condicionales

La estrategia híbrida (nuestra recomendación):

/* Detección nativa de soporte */
@supports (anchor-name: --test) {
  .tooltip {
    position: absolute;
    position-anchor: --trigger;
    bottom: anchor(top);
    left: anchor(center);
  }
}

/* Fallback: la clase .js-tooltip se aplica solo cuando no hay soporte */
.tooltip:not(:has(+ .js-tooltip)) {
  /* estilos base, Popper.js se encarga del posicionamiento */
}

En los tres proyectos que migramos en Mintec, esta estrategia híbrida nos permitió eliminar Popper.js del 92% de los tooltips en el path de navegadores modernos, manteniendo la cobertura total para el 8% restante con el fallback de JS intacto.

Los pitfalls que encontramos

1. anchor-name no se hereda. Cada ancla necesita su propio nombre único si tienes múltiples tooltips en la misma página. Para tooltips generados en un loop, genera nombres dinámicamente con style="anchor-name: --tooltip-{id}".

2. position-area es poderoso pero impreciso. Para diseños que requieren pixel-perfect positioning, prefiere anchor() con valores explícitos. position-area es ideal para casos donde "más o menos arriba" es suficiente.

3. Animaciones limitadas. Las transiciones CSS tradicionales (transition: top 0.2s) no funcionan cuando el navegador reposiciona el elemento vía anchor. Si necesitas animaciones fluidas entre posiciones, Floating UI sigue siendo superior.

4. Scroll containers. Si tu ancla está dentro de un contenedor con overflow: scroll, el posicionamiento funciona correctamente, pero el rendimiento depende de qué tan profundo está el ancla en el árbol de composición.

El patrón más grande: el navegador está absorbiendo JavaScript

CSS Anchor Positioning no es un feature aislado. Es parte de un cambio de paradigma que definió 2025-2026 en la plataforma web: el navegador está absorbiendo los patrones más comunes del ecosistema JavaScript y convirtiéndolos en APIs nativas.

Container queries reemplazaron la detección de ancho con JavaScript. Scroll-driven animations eliminaron IntersectionObserver para animaciones de entrada. View Transitions API jubiló las librerías de animación entre páginas. WebGPU llevó el cómputo GPU al navegador. Y ahora Anchor Positioning elimina la necesidad de Popper.js y Floating UI para la mayoría de los casos.

En Mintec, este cambio de paradigma ya cambió cómo evaluamos dependencias. Antes de instalar una librería, la pregunta no es "¿resuelve mi problema?" sino "¿el navegador ya resuelve esto de forma nativa?". En 2026, la respuesta es "sí" más seguido de lo que la mayoría de los equipos asume.

Si tu proyecto de frontend todavía depende de Popper.js o Floating UI, el momento de planificar la migración es ahora. No porque las librerías sean malas — resolvieron un problema real durante años. Sino porque en 2026, el navegador ya lo resuelve mejor.

¿Querés eliminar dependencias de JavaScript de tu stack frontend? En Mintec auditamos bundles, identificamos APIs nativas que reemplazan librerías, y migramos sin romper la experiencia de tus usuarios. Escribinos.