Diseño responsivo: fundamentos que no pasan de moda
El diseño responsivo adapta una interfaz a cualquier pantalla con rejillas fluidas, imágenes flexibles y media queries. Sus fundamentos de 2010 siguen vigentes.
¿Qué es y de dónde viene?
Antes de 2010, muchos sitios tenían una versión de escritorio y otra para móvil. Marcotte propuso otra idea: una sola interfaz que responde al espacio disponible. En su artículo de A List Apart, publicado el 25 de mayo de 2010, lo describe como “tres ingredientes técnicos”: rejillas fluidas, imágenes flexibles y media queries.
Marcotte resume las media queries así: son, en esencia, “comentarios condicionales para el resto de nosotros”. Es decir, permiten aplicar estilos distintos según las condiciones del navegador, con el mismo HTML.
El término ya es tan común que parece obvio, pero la idea sigue exigiendo decisiones de diseño. Adaptar no es solo encoger: es decidir qué se muestra, en qué orden y con qué jerarquía en cada tamaño.
¿Por qué le importa a un diseñador?
Porque la pantalla no es una variable que controlas. Un diseño puede verse en un teléfono de 360 píxeles de ancho, en un portátil de 1440 o en un monitor vertical. Diseñar solo para un tamaño es diseñar para una minoría de situaciones.
El diseño responsivo también obliga a pensar en el contenido. Si un título largo rompe el layout a cierto ancho, el problema no es del CSS: es una decisión de diseño sobre cuánto texto cabe y cómo se resuelve.
¿Cuáles son los fundamentos?
Según web.dev, los fundamentos prácticos son estos:
- Viewport. Una etiqueta
metaconwidth=device-width, initial-scale=1le indica al navegador móvil que use el ancho real de la pantalla. Sin ella, según web.dev, la página se carga muy reducida y el texto cuesta leerlo. web.dev también desaconsejamaximum-scaleyuser-scalableen esa etiqueta, porque impiden que la persona haga zoom. - Rejillas fluidas. Medidas en porcentajes,
fren CSS Grid o unidades relativas, en lugar de anchos fijos en píxeles. - Imágenes flexibles. web.dev recomienda
max-width: 100%en todas las imágenes, para que se reduzcan al espacio disponible, y mantener los atributoswidthyheightpara que el navegador reserve el espacio antes de que carguen. - Layouts modernos. Flexbox y CSS Grid permiten muchas disposiciones sin media queries.
- Media queries. Se usan donde el layout realmente necesita cambiar, no antes.
MDN define las media queries como una forma de aplicar estilos CSS según el tipo de medio (por ejemplo, pantalla o impresión) o características como la resolución, la orientación o el ancho del viewport. Para características con rango, como el ancho, se pueden usar los prefijos min- y max- o la sintaxis de operadores: (width <= 1250px) equivale a (max-width: 1250px).
¿Mobile-first o desktop-first?
La discusión es antigua y sigue vigente. web.dev recomienda diseñar el contenido para caber primero en pantallas pequeñas y elegir los breakpoints principales empezando por el tamaño pequeño, ampliando hacia arriba hasta que haga falta un cambio. Es el enfoque que explica la nota sobre diseño mobile-first.
La razón práctica es que en pantalla pequeña cada decisión de prioridad se nota más. Si el contenido funciona en 360 píxeles, en pantallas grandes solo hay que añadir espacio, no quitar lo que sobra.
¿Qué breakpoints usar?
web.dev recomienda no definir breakpoints según clases de dispositivo, marcas o sistemas operativos. Los dispositivos cambian cada año; el contenido cambia cuando el texto deja de caber. Por eso, un buen breakpoint es el ancho en que el layout se rompe, no el ancho de un teléfono concreto.
Dos conceptos ayudan a decidirlo. Las consultas por contenedor (container queries) aplican estilos a un elemento según atributos de su contenedor, como su tamaño, y no según el viewport. Se activan con container-type: inline-size en el contenedor y se consultan con @container (width > 700px) { … }; MDN las presenta como alternativa a las media queries. Así una tarjeta se adapta al hueco donde está, esté en una columna estrecha o en la página completa. La comparación completa está en breakpoints frente a container queries. Y el dimensionamiento intrínseco deja que el navegador decida tamaños según el contenido, sin fijar valores en cada caso.
Ejemplo
Ejemplo ilustrativo: una tarjeta de producto con imagen, nombre, precio y botón. En pantalla pequeña, la tarjeta ocupa el ancho completo, la imagen se recorta a una proporción fija y el botón ocupa todo el ancho para que sea fácil de tocar. A partir de cierto ancho, dos tarjetas se colocan lado a lado. Al revisar, el equipo descubre que el nombre del producto puede tener tres líneas en una tarjeta estrecha y empuja el precio fuera del área visible. La solución no es un breakpoint nuevo: es limitar el nombre a dos líneas y mover el precio por encima del botón.
Para tu próximo diseño: prueba el mismo componente con su contenido más largo y más corto, a dos anchos distintos. Si algo se rompe, anota en qué ancho ocurre; ese es el punto donde necesitas decidir un cambio.
¿Cuándo NO conviene?
- Cuando la pieza no necesita adaptarse. Un documento para imprimir o una imagen fija con proporción controlada no requieren media queries, y forzarlos complica el mantenimiento.
- Cuando adaptar significa ocultar contenido. web.dev advierte que no se oculte contenido solo porque no cabe en la pantalla: el tamaño de la pantalla no indica qué necesita la persona. Ocultar información importante en pantallas pequeñas la deja fuera de su alcance.
- Cuando se diseñan cuatro layouts completos en lugar de uno que cambie por partes. Mantener cuatro versiones suele generar errores.
Errores comunes
- Olvidar la etiqueta viewport. Sin ella, la adaptación no funciona en móviles.
- Usar anchos fijos en píxeles para contenedores que deberían fluir.
- Definir breakpoints por marca de dispositivo en lugar de por contenido.
- Diseñar solo en escritorio y adaptar después.
- Ocultar contenido en pantallas pequeñas sin ofrecer otra forma de acceder a él.
- Probar solo a dos anchos. Los problemas aparecen en los anchos intermedios.
Relacionado en la wiki
Para la diferencia entre adaptar por pantalla y adaptar por componente, lee breakpoints frente a container queries. Si quieres ver las estrategias concretas de escalado, mira las estrategias de escalado responsivo. Y para entender cuándo una rejilla fija conviene más que una intrínseca, revisa rejilla frente a decisiones intrínsecas.