Entrevista de Frontend: ¿Cómo aislar anclas en componentes repetidos con CSS anchor-scope?

Planteamiento y alcance

Una lista contiene tarjetas repetidas. Cada tarjeta tiene un disparador y un tooltip posicionado de forma absoluta. El disparador utiliza el mismo anchor-name y el tooltip hace referencia a él con position-anchor; cada tooltip se alinea con la última ancla con el mismo nombre en el documento. Diseñe el alcance de nombres, los límites del componente, el fallback y las pruebas.

Enfóquese en cómo anchor-scope limita la búsqueda explícita de anclas con nombre. No se trata de un aislamiento de Shadow DOM y no todos los navegadores admiten aún esta característica Baseline 2026.

Qué está evaluando el entrevistador

• Explicar por qué un ancla sin alcance con el mismo nombre puede resolverse según el orden en el código fuente.
• Distinguir entre none, all y una lista de nombres dashed-ident.
• Gestionar anclas implícitas, shadow trees, fallback de desbordamiento (overflow) y navegadores no compatibles.
• Convertir la regla en un contrato de componente reutilizable, DOM comprobable y un fallback observable.

Preguntas aclaratorias

1. ¿Debe el tooltip sobrepasar al ancestro de la tarjeta o debe permanecer dentro del subárbol de la tarjeta?
2. ¿Pueden los componentes anidarse, usar Shadow DOM o renderizar el tooltip en otro lugar mediante portales (portal)?
3. ¿Qué experiencia deben preservar los navegadores más antiguos?
4. ¿Los nombres de anclas son generados por un sistema de diseño o escritos a mano por página?
5. ¿Qué casos de desbordamiento, foco de teclado y redimensionamiento se requieren?

Una respuesta de 30 segundos

“El mismo nombre de ancla no tiene un límite de visibilidad, por lo que un elemento posicionado puede resolver la última ancla coincidente en el orden del código fuente. Establezco un contenedor de tarjeta como la raíz del alcance y uso anchor-scope: --card-anchor, o all cuando se debe aislar cada nombre interno, de modo que el tooltip se resuelva dentro de ese subárbol. Envuelvo las reglas de mejora en @supports y recurro a un contenedor relativo junto con posicionamiento absoluto como fallback. Las pruebas cubren anidamiento, portales, desbordamiento, comportamiento del teclado y navegadores con distinto nivel de soporte. Documento el nombre y el límite del DOM como parte del contrato del componente.”

Diseño paso a paso

1. Diagnosticar la asociación incorrecta

anchor-name y position-anchor crean una asociación explícita. Con varias anclas con el mismo nombre y sin un alcance definido, un elemento posicionado puede resolver la última ancla coincidente en el orden del código fuente, por lo que los tooltips repetidos se apilan juntos. Inspeccione el ancla calculada, el orden en el DOM y el bloque contenedor en DevTools antes de atribuir el problema al tamaño o al contexto de apilamiento.

2. Elegir un límite de alcance

Establezca anchor-scope en cada contenedor de tarjeta para limitar la búsqueda de los nombres elegidos al subárbol de ese elemento. all cubre los nombres de ancla en el subárbol; --card-anchor limita solo ese nombre, dejando otros nombres disponibles para asociaciones entre componentes. El alcance no limita anclas implícitas ni actúa como un aislamiento general de estilos o herencia.

.card {
  anchor-scope: --card-anchor;
}

.card__trigger {
  anchor-name: --card-anchor;
}

.card__tip {
  position: absolute;
  position-anchor: --card-anchor;
  position-area: block-end;
}

3. Definir el contrato de nombrado del componente

Trate el nombre de un ancla como una interfaz interna del componente. La raíz, el ancla y el elemento posicionado deben permanecer en el subárbol esperado, y los ancestros arbitrarios no deben anular el alcance. Para el anidamiento, elija nombres por nivel o restablezca el alcance dentro del componente interno. Valide el contrato del DOM en pruebas de componentes o Storybook.

4. Añadir detección de capacidades y fallback

MDN marca anchor-scope como Baseline 2026, pero es posible que los navegadores más antiguos no lo implementen. Coloque las reglas de mejora detrás de @supports (anchor-scope: all). Sin soporte, utilice un contenedor relativo con coordenadas absolutas (insets), geometría mediante JavaScript o el componente de tooltip existente. Conserve el orden de foco, los nombres accesibles y el contenido no obstruido en el fallback.

5. Evaluar portales, Shadow DOM y anclas implícitas

El alcance de ancla afecta la asociación explícita de anclas con nombre. Si un tooltip se envía mediante un portal fuera de la tarjeta, puede salir del subárbol de alcance; en su lugar, use un nombre único, pase la geometría o mantenga la ruta de posicionamiento existente. Los shadow trees tienen su propio alcance de árbol y requieren pruebas de límites. No utilice anchor-scope como solución para todos los casos de anclas implícitas.

6. Probar y observar

Pruebe múltiples tarjetas, tarjetas anidadas, inserción dinámica, reordenamiento, redimensionamiento, desplazamiento (scroll), zoom, foco de teclado y portales. Valide la geometría de cada tooltip, el desbordamiento, el árbol de accesibilidad y la tasa de fallback. Registre la detección de capacidades y los errores de posicionamiento sin registrar la entrada del usuario.

Respuesta modelo de alta calidad

“Sin un alcance, un ancla con el mismo nombre puede resolverse hacia el último elemento en el orden del código fuente, por lo que los tooltips repetidos se superponen. Establezco anchor-scope: --card-anchor en la raíz de la tarjeta, anchor-name en el disparador y position-anchor en el tooltip para restringir la búsqueda explícita al subárbol de la tarjeta. Si todos los nombres internos deben aislarse, utilizo all; esto no afecta a las anclas implícitas ni a la herencia común de CSS. Los navegadores más antiguos reciben un fallback con @supports hacia el posicionamiento con contenedor relativo y la ruta de tooltip existente. Pruebo el anidamiento, portales, Shadow DOM, desbordamiento, redimensionamiento, foco de teclado y operaciones de reordenamiento, y documento el nombre y los límites del DOM en el contrato del componente.”

Errores comunes

• Dar a cada elemento un nombre de ancla diferente → el componente no se puede reutilizar limpiamente → definir el alcance del nombre repetido.
• Tratar all como Shadow DOM → la herencia, los portales y los alcances de árbol siguen siendo diferentes → probar los límites de búsqueda y estilo por separado.
• Ignorar el orden del código fuente → una prueba con una sola última tarjeta oculta el error → probar múltiples tarjetas y su reordenamiento.
• No proporcionar un fallback → los navegadores más antiguos pierden la ubicación del tooltip → utilizar @supports y la ruta existente absoluta o de JavaScript.
• Aplicar alcance a un ancla implícita → la regla no tiene el efecto deseado → confirmar si la asociación es explícita o implícita.

Preguntas de seguimiento y respuestas

¿Cuándo elige anchor-scope: all frente a un valor con nombre?

Utilice all cuando cada nombre de ancla dentro del componente deba resolverse solo dentro de esa tarjeta. Utilice --card-anchor cuando un nombre necesite aislamiento pero otros nombres deban permanecer disponibles a través de los límites. Pruebe ambos con el contrato de DOM del componente.

¿Debe el tooltip permanecer dentro del subárbol de la tarjeta?

No. Un portal o una superposición global puede salir del subárbol de alcance y perder el acceso al ancla de la tarjeta. Asigne a la superposición un nombre de ancla único, pase la geometría o mantenga el posicionamiento por JavaScript en lugar de forzar la superposición en la capa de DOM incorrecta.

¿Está esta propiedad lista para cualquier producto?

MDN la clasifica como Baseline 2026, mientras que W3C CSS Anchor Positioning Level 1 sigue siendo un Working Draft. Verifique la matriz de navegadores de destino y utilice @supports junto con pruebas de capacidad para la mejora progresiva.