Reconozco que tras más de una década dedicándome al diseño y desarrollo de páginas web me sorprende toparme con conceptos que desconocía, pero que al parecer venían tratándose en el mundillo desde hacía años. El último con el que me he cruzado ha sido el de diseño intrínseco cuando estaba buscando opciones más cómodas para implementar media queries en los bloques en WordPress. Por este motivo, me ha parecido buena idea hacer un artículo sobre este tema, sobre todo teniendo en cuenta la falta de información en español que he encontrado y que imagino que para algunos desarrolladores será de especial interés.
Esta entrada será para los muy cafeteros del diseño web, por lo que me saldré de la tónica habitual y además de explicar en qué consiste y cuál es la filosofía tras el diseño web intrínseco, trataré de reflexionar dando mi punto de vista sobre este asunto, con la intención no de sentar cátedra sino de intercambiar puntos de vista. De modo que te invito a que dejes tu comentario al final con tus impresiones sobre el tema, a fin de cuentas diseñadores, maquetadores y programadores forman parte de la misma maquinaria. El futuro de la creación de páginas web reside en nosotros como profesionales y un debate constructivo siempre es beneficioso para la comunidad.
¿Qué es el diseño intrínseco?
El concepto de diseño intrínseco, o Intrinsic Web Design, fue propuesto por Jen Simmons en 2018 para describir una nueva forma de abordar la creación de layouts que empezaba a ser posible gracias a la evolución de CSS. No se trata de una metodología con unas reglas que debamos seguir paso a paso, sino más bien de una filosofía a la hora de plantear cómo debe comportarse una página web.
Para entender de dónde surge, hay que echar la vista un poco atrás. Durante muchos años, buena parte del diseño responsive se ha basado en establecer diferentes puntos de ruptura mediante media queries. Creamos un diseño que funciona correctamente en determinadas dimensiones y, cuando deja de hacerlo o llegamos a una anchura que consideramos relevante, introducimos cambios.
Esta forma de trabajar nos ha llevado también a pensar habitualmente en varios estados de una misma página. Tenemos un diseño para escritorio, otro para tablet y otro para móvil, aunque en la práctica existan multitud de tamaños intermedios. No es algo que tenga necesariamente nada de malo y las media queries continúan siendo una herramienta fundamental de CSS, pero sí implica que somos nosotros quienes vamos tomando muchas de las decisiones sobre cómo debe comportarse el diseño a medida que cambia el espacio disponible.
El diseño intrínseco propone cambiar en cierta medida esta forma de pensar. En lugar de definir de antemano todos esos estados, podemos establecer unas reglas que permitan que los propios elementos se adapten al espacio que tienen disponible. El navegador deja de limitarse a ejecutar una serie de cambios que hemos previsto para determinadas anchuras y adquiere mayor capacidad para resolver cómo debe distribuirse el contenido en cada momento.
Esto tampoco significa que el diseño intrínseco venga a sustituir al diseño responsive. De hecho, entre los principios que planteaba Jen Simmons se encontraba el uso de media queries cuando fueran necesarias. Quizá sea más acertado entenderlo como una evolución en nuestra forma de trabajar con diseños adaptables, aprovechando capacidades de CSS que no existían, o no estaban suficientemente extendidas, cuando el responsive design comenzó a imponerse.
La diferencia puede parecer más teórica que práctica hasta que cambiamos la pregunta que nos hacemos al maquetar. En lugar de pensar qué debe ocurrir cuando una pantalla mida una determinada cantidad de píxeles, podemos empezar preguntándonos qué reglas necesita un elemento para comportarse correctamente independientemente del espacio que termine teniendo.
De controlar cada tamaño a establecer unas reglas
Durante mucho tiempo he trabajado con una forma de plantear el responsive que imagino que resultará familiar a cualquiera que se dedique a la maquetación web. Partes del diseño para escritorio, reduces el viewport y, cuando algo empieza a dejar de funcionar como esperabas, introduces un breakpoint y haces los ajustes necesarios. Sigues reduciendo y repites el proceso tantas veces como haga falta.
También los propios maquetadores visuales han contribuido a consolidar esta manera de trabajar. Es habitual que permitan seleccionar escritorio, tablet o móvil y modificar para cada dispositivo el tamaño de una tipografía, un margen, el número de columnas o prácticamente cualquier otro valor. Resulta cómodo y, sobre todo, proporciona una sensación de control muy directa sobre el resultado.
El problema es que una página web no existe realmente en tres tamaños. Entre un móvil de 390 píxeles y un monitor de 1920 hay una enorme cantidad de posibilidades, a las que hay que sumar que un elemento no siempre dispone de todo el ancho de la ventana. Puede estar dentro de una columna, de una cuadrícula o de cualquier otro contenedor que limite su espacio.
Aquí es donde el cambio de mentalidad que propone el diseño intrínseco empieza a resultar interesante. Pensemos, por ejemplo, en un conjunto de tarjetas que queremos distribuir en varias columnas. Podemos decidir que se muestren cuatro en escritorio, dos en tablet y una en móvil. Funciona, pero somos nosotros quienes estamos definiendo previamente tres posibles soluciones.
Otra posibilidad consiste en establecer cuánto puede reducirse razonablemente cada tarjeta y permitir que el navegador calcule cuántas caben en cada momento. Quizá en una determinada anchura entren cuatro, un poco más abajo tres, después dos y finalmente una. No hemos tenido que decidir en qué dispositivo ocurre cada cambio, porque lo importante ya no es el dispositivo sino el espacio que necesita el contenido para mostrarse correctamente.
Este matiz me parece importante. No estamos renunciando al control sobre el diseño, sino trasladándolo a otro lugar. Seguimos decidiendo cómo queremos que se comporte la composición, pero en vez de especificar todos sus posibles estados establecemos sus límites y dejamos que el navegador resuelva lo que ocurre entre ellos.
En cierto modo, pasamos de decirle qué tiene que hacer en cada situación a explicarle bajo qué reglas queremos que funcione.
Sobre el papel puede parecer incluso más complicado que seguir añadiendo media queries. La diferencia es que CSS ha evolucionado muchísimo y actualmente disponemos de herramientas pensadas precisamente para expresar este tipo de relaciones. Algunas llevan ya años entre nosotros y seguramente las hayas utilizado sin relacionarlas nunca con el concepto de diseño intrínseco. Son precisamente esas herramientas las que permiten llevar esta filosofía de la teoría a una forma real de trabajar.
El CSS que hizo posible este cambio
Hablar de diseño intrínseco habría sido bastante más difícil hace unos años porque, aunque la idea de crear diseños fluidos no es precisamente nueva, las herramientas de las que disponíamos nos obligaban a intervenir con mayor frecuencia. La evolución de CSS ha permitido que muchas decisiones que antes teníamos que especificar mediante breakpoints puedan resolverse ahora a partir del contenido y del espacio disponible.
CSS Grid es probablemente uno de los ejemplos más claros. Recuperando el caso anterior de las tarjetas, podemos crear una cuadrícula que determine por sí misma cuántas columnas puede mostrar:
.contenedor {
display: grid;
grid-template-columns: repeat(auto-fit, minmax(250px, 1fr));
}
En este ejemplo no hemos indicado que queremos cuatro columnas en escritorio, dos en tablet y una en móvil. Lo que estamos diciendo es que cada columna debe tener un mínimo de 250 píxeles y que, a partir de ahí, puede crecer para ocupar el espacio disponible. auto-fit se encarga de calcular cuántas columnas caben en cada momento.
El resultado puede terminar siendo visualmente muy parecido al que conseguiríamos utilizando varias media queries, pero la lógica que hay detrás es diferente. No hemos elegido los puntos en los que debe cambiar la composición. Hemos definido cuánto puede reducirse cada elemento antes de que resulte preferible reorganizar el contenido y es el navegador quien realiza ese cálculo.
Esta capacidad para expresar límites aparece en muchas otras partes del CSS actual. Valores como min-content, max-content o fit-content permiten tener en cuenta las dimensiones naturales del propio contenido, mientras que unidades flexibles como fr facilitan repartir el espacio que queda disponible. Flexbox, por su parte, lleva años permitiéndonos crear elementos que crecen, se reducen o saltan a una nueva línea dependiendo del espacio que encuentran a su alrededor.
No es necesario utilizar todas estas posibilidades para hacer diseño intrínseco, del mismo modo que utilizarlas tampoco convierte automáticamente una maquetación en intrínseca. Lo relevante es la intención con la que las usamos. En lugar de imponer dimensiones pensando en unos cuantos tamaños de pantalla, podemos definir relaciones entre los elementos y unos límites dentro de los cuales permitimos que el navegador trabaje.
Esta misma idea puede aplicarse incluso a propiedades que, a primera vista, no tienen demasiado que ver con la estructura de una página. Pensemos en el tamaño de un encabezado. Una solución responsive bastante habitual podría ser esta:
h1 {
font-size: 42px;
}
@media (max-width: 768px) {
h1 {
font-size: 30px;
}
}
Tenemos dos tamaños y hemos decidido exactamente cuándo pasar de uno al otro. Sin embargo, también podemos establecer un valor mínimo, uno máximo y permitir que la tipografía crezca de manera fluida entre ambos:
h1 {
font-size: clamp(1.875rem, 4vw, 2.625rem);
}
En este caso clamp() impide que el texto baje de 1.875rem o supere 2.625rem, mientras que entre esos dos extremos el valor basado en vw permite que su tamaño evolucione junto con el viewport.
De nuevo, lo interesante no es clamp() en sí mismo, sino la forma de plantear el problema. Seguimos tomando las decisiones importantes, ya que somos nosotros quienes establecemos los límites, pero dejamos de intentar controlar cada uno de los estados intermedios.
Esto tampoco significa que podamos eliminar las media queries de nuestras hojas de estilo. Hay cambios que no pueden resolverse simplemente haciendo que algo crezca, se reduzca o se reorganice de manera natural. En ocasiones queremos modificar deliberadamente una composición porque así lo requiere el diseño y, cuando eso ocurre, una media query sigue siendo una solución perfectamente válida.
El objetivo, al menos como yo lo entiendo, no es evitar los breakpoints a toda costa. Es dejar de recurrir a ellos de forma automática para resolver problemas que el propio CSS puede gestionar de una manera más natural.
Sin embargo, hasta aquí seguimos teniendo una limitación importante. Aunque hayamos conseguido que nuestros elementos sean mucho más flexibles, algunas decisiones responsive continúan dependiendo del tamaño de la ventana del navegador. Y esto resulta especialmente problemático cuando empezamos a pensar en componentes que pueden aparecer en lugares muy diferentes de una misma web.
Las container queries llevan la idea todavía más lejos
Hasta aquí seguimos teniendo una limitación importante. Aunque hayamos conseguido que nuestros elementos sean mucho más flexibles, algunas decisiones responsive continúan dependiendo del tamaño de la ventana del navegador. Y esto resulta especialmente problemático cuando empezamos a pensar en componentes que pueden aparecer en lugares muy diferentes de una misma web.
Imaginemos un bloque que muestra una imagen, un título y un pequeño texto. Ese mismo bloque puede ocupar todo el ancho de una página, formar parte de una cuadrícula de tres columnas o encontrarse dentro de una zona lateral bastante más estrecha.
Si utilizamos una media query convencional, las reglas que aplicamos dependen del tamaño del viewport. Podemos encontrarnos entonces con un monitor de 1920 píxeles en el que nuestro bloque apenas dispone de 350 porque está dentro de una columna. Para CSS seguimos estando en una pantalla grande, aunque para ese componente concreto el espacio sea muy reducido.
Las container queries permiten abordar el problema desde otra perspectiva. En lugar de preguntar cuánto mide la ventana podemos preguntar cuánto espacio tiene disponible el contenedor en el que se encuentra el elemento. El componente ya no necesita saber si está siendo mostrado en un móvil, una tablet o un ordenador. Su comportamiento puede depender del espacio que realmente tiene disponible allí donde ha sido colocado.
Esta diferencia resulta especialmente interesante cuando trabajamos con sistemas basados en componentes. Un elemento puede diseñarse una vez y utilizarse después en contextos muy distintos sin que tengamos que conocer de antemano todas las posiciones que terminará ocupando.
No voy a detenerme demasiado en su funcionamiento porque ya expliqué con más detalle las diferencias entre media queries y container queries, su sintaxis y algunos ejemplos de uso en mi artículo sobre consultas CSS basadas en tamaños. Lo importante aquí es que representan bastante bien ese cambio de mentalidad del que estamos hablando: el contexto inmediato del componente puede ser más importante que unas dimensiones globales de pantalla.
Y es precisamente aquí donde todo esto empezó a resultarme especialmente familiar al trasladarlo al editor de bloques de WordPress. Un bloque no sabe necesariamente dónde acabará utilizándose. Puede ocupar el ancho principal de una página, estar dentro de un grupo, compartir espacio con otros bloques o formar parte de una composición que ni siquiera existía cuando fue desarrollado.
Intentar controlar su comportamiento exclusivamente mediante los tamaños tradicionales de escritorio, tablet y móvil empieza entonces a parecer una solución un poco extraña. Lo verdaderamente relevante para ese bloque no siempre es el dispositivo desde el que se visita la web, sino el espacio del que dispone para hacer su trabajo.
Curiosamente, fue intentando conseguir precisamente un mayor control sobre esos tamaños como terminé descubriendo el diseño intrínseco.
Mi experiencia aplicándolo al editor de bloques de WordPress
Como comentaba al principio del artículo, no llegué al diseño intrínseco buscando información sobre nuevas tendencias de diseño web. Lo hice intentando resolver una limitación que encontraba al trabajar con el editor de bloques de WordPress.
Durante bastante tiempo había trabajado con maquetadores visuales como Elementor o Visual Composer, donde estamos acostumbrados a disponer de controles específicos para escritorio, tablet y móvil. Puedes cambiar tamaños, márgenes, alineaciones o incluso determinados comportamientos según el dispositivo. Cuando empecé a plantearme utilizar únicamente el editor de bloques para realizar maquetaciones profesionales, la ausencia de estos controles se hacía bastante evidente.
Mi primera reacción fue pensar que era una carencia del editor. WordPress había ido incorporando cada vez más herramientas relacionadas con la maquetación, pero seguía sin ofrecer una forma equivalente de controlar desde la interfaz cómo debía comportarse cada bloque en distintos tamaños de pantalla. Si vienes de un constructor que permite hacerlo prácticamente todo desde sus controles responsive, pasar al editor nativo puede dar la sensación de estar trabajando con una mano atada a la espalda.
Buscando información sobre esta cuestión terminé en los espacios de desarrollo de WordPress donde se discuten posibles mejoras del editor. Allí encontré precisamente lo que estaba buscando: otros usuarios proponían incorporar controles que permitiesen modificar los estilos de los bloques según el tamaño de pantalla.
Lo que me llamó la atención no fue tanto comprobar que había más gente echando de menos esta posibilidad, sino descubrir que la discusión iba bastante más allá de decidir cómo implementar esos controles. Una de las razones que se planteaban para no seguir ese camino era apostar por diseños capaces de adaptarse de una forma más natural, evitando trasladar al editor una colección cada vez mayor de ajustes específicos para diferentes breakpoints.
Fue siguiendo aquella conversación como acabé leyendo sobre diseño intrínseco.
Reconozco que inicialmente aquello no solucionaba exactamente el problema que tenía. Yo estaba buscando una herramienta que me proporcionase más control y la respuesta que encontraba venía a sugerir que quizá debía necesitar menos. Cuando llevas años acostumbrado a revisar una maquetación en diferentes anchuras e intervenir donde consideras necesario, el planteamiento puede resultar incluso un poco frustrante.
Sin embargo, con el tiempo he terminado incorporando buena parte de esa filosofía a mi manera de trabajar. Durante el último año he seguido profundizando en el editor de bloques y actualmente puedo realizar con él maquetaciones profesionales sin depender de un constructor visual adicional. Para llegar hasta ahí no solo he tenido que aprender mejor las posibilidades del propio editor, también he tenido que cambiar algunas ideas que tenía bastante interiorizadas sobre cómo debía abordar el responsive.
Mi criterio actual podría resumirse de una forma bastante sencilla: todo aquello que pueda adaptarse de manera natural, prefiero dejar que lo haga.
Si una cuadrícula puede reorganizar sus columnas según el espacio disponible, no necesito establecer manualmente cuántas debe mostrar en cada dispositivo. Si un tamaño puede crecer de forma fluida entre unos límites razonables, tampoco necesito definir varios valores intermedios. Y si un componente puede responder al contexto en el que se encuentra, tiene más sentido que hacerlo depender siempre de la anchura total de la pantalla.
Esto ha hecho que necesite intervenir bastante menos de lo que inicialmente pensaba. También tiene otra ventaja importante cuando trabajamos con WordPress: cuanto más conseguimos resolver utilizando las capacidades nativas del editor y del propio CSS, menos excepciones tenemos que mantener después.
Pero que necesite intervenir menos no significa que haya dejado de hacerlo. Hay situaciones en las que el comportamiento natural de los elementos no coincide con el resultado que quiero conseguir y otras en las que existe una decisión de diseño que CSS no puede deducir por mí. Cuando ocurre, sigo recurriendo a CSS personalizado y, si necesito una media query, la utilizo.
Después de todo, adoptar una filosofía no debería obligarnos a convertirla en una doctrina.
Diseño intrínseco sí, pero sin renunciar al control
Creo que este último matiz es importante porque, llevado al extremo, el diseño intrínseco podría interpretarse como una especie de renuncia del diseñador a decidir cómo debe comportarse una página. Después de ponerlo en práctica durante este tiempo, no es así como lo entiendo.
Para mí el cambio está más bien en decidir cuándo merece la pena intervenir.
Durante años hemos tenido buenas razones para controlar muchos estados de una maquetación porque las herramientas disponibles no podían resolverlos por sí solas. El CSS actual nos permite delegar una parte mucho mayor de ese trabajo. Podemos establecer límites, relaciones y comportamientos y dejar que el navegador encuentre la solución adecuada para cada espacio disponible.
Eso no elimina nuestro papel como diseñadores o maquetadores. Al contrario, seguimos siendo nosotros quienes decidimos cuáles son esos límites, qué relaciones deben existir entre los elementos y cuándo el comportamiento obtenido deja de responder a lo que buscamos.
Por eso, después de haber llegado al diseño intrínseco precisamente porque echaba de menos controles responsive en WordPress, mi postura actual resulta bastante diferente de la que tenía al comenzar este artículo. Sigo pensando que hay situaciones en las que disponer de mayor control desde el editor sería útil, pero también creo que intentar reproducir el funcionamiento de otros constructores añadiendo ajustes para escritorio, tablet y móvil a cada propiedad no tiene por qué ser la mejor solución.
Ahora prefiero partir de otra idea. Todo lo que pueda adaptarse de manera natural, que lo haga. Cuando necesito intervenir, intervengo.
Quizá esa sea también la razón por la que el término diseño intrínseco no ha alcanzado la popularidad de otros conceptos como responsive design o mobile first. Han pasado varios años desde que Jen Simmons utilizó aquella expresión y no parece que nos encontremos ante una nueva metodología que haya sustituido a las anteriores. Sin embargo, muchas de las ideas que intentaba reunir bajo ese nombre están presentes en la forma en la que CSS ha evolucionado y en las herramientas con las que trabajamos actualmente.
Grid, Flexbox, los tamaños intrínsecos, las funciones que permiten establecer límites o las container queries nos dan cada vez más posibilidades para describir cómo queremos que se comporte un diseño sin tener que especificar todas las situaciones en las que puede encontrarse.
Tal vez por eso me sorprendió tanto descubrir el concepto después de tantos años dedicándome al diseño y desarrollo web. No conocer su nombre no significaba estar completamente al margen de sus ideas. Algunas ya formaban parte de las herramientas que utilizaba y otras han terminado incorporándose a mi forma de trabajar desde entonces.
Lo que sí me proporcionó encontrar aquel debate fue una manera diferente de pensar sobre ellas. Y, un año después de comenzar a escribir este artículo, probablemente esa haya sido la parte más útil de todo este recorrido.
Deja una respuesta