Los límites del layout intrínseco
Qué no puede resolver un layout que reacciona al contenido, en qué cuatro casos la media query sigue siendo la herramienta correcta, y cómo se reparten hoy el trabajo las tres estrategias de adaptación.
Un discurso demasiado entusiasta sobre el diseño intrínseco acaba en una regla igual de rígida que la que quería sustituir: “nunca uses media queries”. Es falsa. Hay decisiones que dependen genuinamente del dispositivo o del usuario y que ninguna cantidad de minmax() puede deducir, y hay cambios de layout que no son un ajuste de proporciones sino un rediseño. Saber dónde está la frontera es lo que separa a quien ha leído sobre esto de quien lo ha llevado a producción.
- Identificar los cuatro tipos de decisión que el layout intrínseco no puede tomar.
- Distinguir un cambio de proporciones de un cambio de estructura.
- Repartir el trabajo entre layout intrínseco, consultas de contenedor y media queries.
- Detectar el antipatrón de forzar aritmética retorcida para evitar una condición legítima.
Lo que el contenido no sabe
El layout intrínseco resuelve preguntas de la forma “¿cuánto espacio hay y cuánto necesita esto?”. Hay cuatro familias de preguntas que no tienen esa forma y que por tanto quedan fuera de su alcance.
Preferencias del usuario. Si alguien ha pedido menos movimiento, un esquema oscuro o más contraste, esa información no está en ninguna dimensión. Solo llega por consulta de preferencia, y no hay alternativa ni la habrá.
Capacidades del dispositivo de entrada. Si el puntero principal es grueso, los objetivos táctiles deben ser mayores. El ancho disponible no correlaciona con eso: hay tabletas anchas con dedo y portátiles estrechos con ratón.
El propio viewport, cuando la pregunta es realmente sobre el viewport. Una cabecera fija que ocupa un porcentaje de la altura de la ventana, un menú que debe caber en pantalla sin desplazamiento, la decisión de mostrar u ocultar un panel a pantalla completa: todo eso son preguntas sobre la ventana, y responderlas con una media query es correcto, no una derrota.
El medio. @media print sigue siendo la forma de decir que en papel no hay barra lateral ni botones.
Cambio de proporciones frente a cambio de estructura
El layout intrínseco es excelente reproporcionando: más o menos columnas, más o menos ancho, apilado o en fila. Es incapaz de reestructurar, y es importante no confundir las dos cosas.
Una navegación que en escritorio es una fila de ocho enlaces y en móvil un botón que abre un panel no es el mismo layout con otras proporciones: es otro componente, con otro marcado, otro estado y otras necesidades de accesibilidad. Ninguna combinación de flex-wrap y minmax() va a convertir una lista en un menú desplegable, y el intento —esconder cosas con overflow, mover elementos con order, colapsar con max-height— produce interfaces que dejan contenido inalcanzable para el teclado.
El criterio es sencillo: si el cambio se puede describir como “lo mismo, distribuido de otra forma”, el layout intrínseco lo hace. Si hay que describirlo como “esto se convierte en aquello”, hace falta una condición explícita y, muy probablemente, JavaScript para gestionar el estado.
display: none en un breakpoint es la forma más rápida de crear una interfaz que funciona distinto según el dispositivo sin que nadie lo haya decidido conscientemente. Si un contenido no cabe, la pregunta es si el contenido sobra o si el layout es el equivocado, no cuál es el ancho a partir del cual desaparece. Y si de verdad sobra en pantallas pequeñas, sobra también en las grandes.
Las tres estrategias y su reparto
En 2026 tienes tres herramientas de adaptación y no compiten: se ordenan de la más general a la más específica.
| Estrategia | Pregunta que responde | Coste de mantenimiento |
|---|---|---|
| Layout intrínseco | ¿Cuánto necesita el contenido y cuánto espacio hay? | Nulo: no hay condiciones que sincronizar |
| Container query | ¿Cuánto mide el contenedor de este componente? | Bajo: la condición vive junto al componente |
| Media query | ¿Cómo es el dispositivo o qué prefiere el usuario? | Alto: es estado global compartido |
El orden de preferencia se deduce de la tercera columna. Intenta primero que el layout se resuelva solo; si necesitas un cambio cualitativo, hazlo depender del contenedor; deja la media query para lo que de verdad es del dispositivo o del usuario.
Una consecuencia práctica interesante: cuando aplicas este orden, el número de media queries de un proyecto no baja a cero, baja a un puñado, y ese puñado se concentra en la plantilla de página y en la hoja de preferencias. Los componentes dejan de tener ninguna.
El antipatrón de la aritmética heroica
Existe un exceso simétrico al de los breakpoints: resolver con calc(), clamp() y trucos de flex-basis cosas que se dirían en una línea con una condición. El síntoma es un calc() anidado que nadie del equipo sabe leer y que resulta ser una condición mal disimulada.
/* heroico e ilegible: una condicion escrita en aritmetica sin necesidad */
.panel { padding: calc(1rem + (2rem - 1rem) * ((100vw - 20rem) / (60rem - 20rem))); }
/* lo mismo, legible y con topes correctos */
.panel { padding: clamp(1rem, 0.5rem + 2.5vw, 2rem); }La aritmética está justificada cuando expresa una relación continua, como una escala de espaciado o una tipografía fluida. Deja de estarlo cuando lo que expresa es un cambio discreto entre dos estados: eso es una condición, y una condición se escribe como condición. El switcher de la lección anterior es la excepción que confirma la regla —codifica una condición en aritmética a propósito, porque a cambio obtiene un umbral relativo al contenedor que en su momento no había otra forma de conseguir—, y hoy conviene medirlo contra la alternativa de una container query antes de elegirlo por costumbre.
El error conceptual que sostiene tanto el fanatismo de los breakpoints como el fanatismo contrario es tratar estas herramientas como alternativas para el mismo trabajo. No lo son: cada una opera en un alcance distinto, y el criterio de elección no es la elegancia sino cuál es el alcance mínimo que contiene la información necesaria para tomar la decisión. Si la información es “cuánto mide este texto”, el alcance es el propio elemento y la decisión debe tomarla el algoritmo de layout. Si es “cuánto espacio le han dado a este componente”, el alcance es el contenedor. Si es “el usuario prefiere no ver movimiento”, el alcance es el documento entero, porque la preferencia lo es. Tomar una decisión en un alcance mayor del necesario es exactamente el mismo error que declarar una variable global en un lenguaje de programación: funciona, y a cambio hace que cualquier cambio futuro tenga un radio de impacto imposible de acotar. La versión madura de todo este nivel se resume en una frase: decide siempre en el alcance más pequeño que tenga los datos.