Tres árboles que no son el mismo

Sobre un único árbol de DOM, el motor construye al menos tres estructuras independientes: el árbol de contextos de formato, que decide cómo se colocan las cajas; la cadena de bloques contenedores, que decide respecto a qué se resuelven los porcentajes y las posiciones; y el árbol de contextos de apilamiento, que decide quién se pinta encima de quién. La mayoría de la frustración con CSS viene de creer que son la misma cosa y de aplicar la intuición de una a las otras dos.

Tres preguntas, tres estructuras

Un contexto de formato responde a cómo se colocan estas cajas entre sí: dirección de apilado, colapso de márgenes, interacción con flotantes. Lo abre la lista cerrada del catálogo que ya conoces.

Un bloque contenedor responde a respecto a qué se mide esta caja: contra qué se resuelve un width: 50%, desde dónde cuenta un inset-block-start: 0. Para una caja en flujo normal es la caja de contenido del ancestro de bloque más cercano. Para una caja absolute, es el área de relleno del ancestro posicionado más cercano. Para una fixed, es el viewport, salvo excepción.

Un contexto de apilamiento responde a quién se pinta encima de quién: el orden de pintado y el ámbito en el que un z-index tiene sentido. Lo abre otra lista distinta: opacity menor que 1, transform, filter, will-change, isolation: isolate, un elemento posicionado con z-index numérico, un elemento flex o grid con z-index numérico.

Las tres listas se solapan sin coincidir, y ahí está la trampa. position: absolute abre las tres cosas. overflow: hidden abre un contexto de formato pero no un bloque contenedor ni un contexto de apilamiento. opacity: 0.99 abre un contexto de apilamiento y no abre ninguno de los otros dos. transform abre un contexto de apilamiento y además convierte al elemento en bloque contenedor de sus descendientes fixed, que es la causa del bug de la cabecera fija que deja de estar fija.

El mismo ancestro en tres papeles distintos

Este ejemplo produce tres respuestas diferentes para la misma pregunta “quién manda aquí”:

<div class="marco">
  <div class="panel">
    <div class="pieza">contenido</div>
  </div>
</div>

.marco { position: relative; }
.panel { overflow: auto; }
.pieza { position: absolute; inset-block-start: 0; inline-size: 50%; }

La caja .pieza está en el contexto de formato que abrió .panel, porque overflow: auto lo establece. Pero su bloque contenedor es .marco, porque es el ancestro posicionado más cercano y overflow no posiciona nada: ese 50% se mide contra .marco, no contra .panel, y ese inset-block-start: 0 la coloca en el techo de .marco aunque .panel esté desplazado por el scroll. Y no hay ningún contexto de apilamiento por medio, así que su z-index compite directamente con el de cualquier elemento del contexto raíz.

Tres ancestros distintos para tres preguntas distintas, y ni uno solo de los tres es “el padre”. Intentar razonar sobre esto con la intuición del árbol de DOM no funciona.

Los contextos de formato modernos y sus hijos

Flex y grid añaden un matiz que conviene tener presente. El contenedor establece un contexto de formato independiente para sus elementos, pero además cada elemento establece uno propio para su contenido. Eso significa que la cadena de colapsos de márgenes se rompe dos veces y que los flotantes internos de un elemento flex quedan encerrados en él sin que tengas que hacer nada.

También cambia el display de los hijos. Un elemento flex o grid sufre blockification: su display computado se convierte en el equivalente de bloque. Un span con display: inline dentro de un contenedor flex se comporta como block; un inline-flex se convierte en flex. Por eso las alturas y los márgenes verticales, que en un span no hacían nada, empiezan a funcionar en cuanto su padre es flex.

/* El span de dentro acepta block-size porque ha sido blockificado */
.barra { display: flex; }
.barra span { block-size: 3rem; }   /* funciona */

/* Fuera de flex, esto no hace nada */
.texto span { block-size: 3rem; }   /* ignorado, sigue siendo inline */

Hay una excepción que conviene conocer: display: contents en un hijo hace que su caja desaparezca y que sus hijos pasen a ser elementos del contenedor. No es blockification, es eliminación de la caja, y arrastra consecuencias que van más allá del layout.

Un procedimiento de diagnóstico

Cuando algo no cuadra, la primera decisión no es qué propiedad tocar, sino qué árbol mirar. El síntoma te lo dice.

Si el síntoma es de posición o de tamaño —un porcentaje que da un número inesperado, un absolute que aparece donde no debe, un fixed que se mueve con el scroll— el árbol es el de bloques contenedores. Sube buscando el primer ancestro posicionado, y si hay fixed de por medio, busca también transform, filter y contain.

Si el síntoma es de espaciado o de colocación relativa —márgenes que se funden, altura que ignora contenido, flotantes que sobresalen— el árbol es el de contextos de formato. Sube buscando el primer ancestro del catálogo del nivel 14.2.

Si el síntoma es de quién tapa a quién —un z-index que no obedece, un elemento que insiste en quedar debajo— el árbol es el de apilamiento. Sube buscando opacity, transform, filter, will-change e isolation.

Las DevTools ayudan en los tres casos, pero de formas distintas: el panel de caja calculada delata el colapso de márgenes, el resaltado del elemento al pasar el ratón delata el bloque contenedor equivocado, y el panel de capas delata los contextos de apilamiento inesperados.