Diseño Responsive con HTML y CSS
En este punto nos centraremos en el diseño responsive adaptativo, más conocido en inglés por sus siglas RWD (Responsive Web Design). El concepto de responsive web design fue introducido en la escena del desarrollo web por Ethan Marcotte en mayo del 2010. Desde la introducción del concepto ha sido uno de los aspectos del desarrollo frontend sobre los que más se ha escrito y comentado, como demuestra el hecho de que desde el 2012 ha estado siempre en los primeros puestos de los ránquines de tendencias en diseño web.
index.html
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Document</title>
<link rel="stylesheet" href="styles.css">
</head>
<body>
<ul class="menu">
<li><a href="#">Elemento 1</a></li>
<li><a href="#">Elemento 2</a></li>
<li><a href="#">Elemento 3</a></li>
</ul>
</body>
</html>
style.css
ul.menu {
width: 180px;
list-style: none;
margin: 0;
padding: 0;
border: 1px solid #3A3A3A;
}
ul.menu li {
border-bottom: 1px solid #3A3A3A;
border-top: 1px solid #BBB;
background: #F4F4F4;
}
ul.menu li a {
padding: 0.2em 0 0.2em 0.5em;
display: block;
text-decoration: none;
color: #222;
}
Existen varias definiciones para RWD, algunas muy centradas en el tamaño de visualización del dispositivo y otras que abarcan conceptos mucho más generales y complejos. Todas ellas nos llevan a una definición más completa del término:
Se puede entender RWD como la combinación de enfoque, estrategia y técnicas que tienen como objetivo crear una experiencia unificada y consistente para los usuarios que acceden a los contenidos, independientemente del dispositivo con el que acceden, y más allá aún del dispositivo,del escenario o contexto en el que acceden.
Etiqueta Meta viewport
La etiqueta meta «viewport» es un elemento fundamental para el correcto renderizado de una web realizada con RWD, o específicamente creada para dispositivos, en dispositivos móviles reales. Este viewport representa el área física que el navegador interpretará como necesaria para visualizar el contenido que está mostrando.
El viewport en el escritorio y en los dispositivos se comporta de manera notablemente diferente. En el escritorio es el área visible de la página, por lo que, cambiando el tamaño de la ventana, estamos cambiando el tamaño del viewport. En cambio, en los dispositivos el viewport puede ser más grande o más pequeño que el área visible, ya no coinciden.
Cada navegador móvil puede tener un valor por defecto diferente para el viewport, lo que implica que si queremos que estos navegadores interpreten correctamente cómo funciona nuestro contenido en diferentes anchos, tenemos que especificar esta etiqueta. De otra forma, el navegador móvil aplicará lo que él supone como viewport por defecto, y el resultado más habitual será encontrarnos con que el contenido se muestra completo en la pantalla del dispositivo, pero a consecuencia de aplicar una reducción de zoom importante.
A continuación se muestra un esquema de esta situación que acabamos de describir:
Paso A – B
El contenido se escala de los «interpretados» 980 px a los 320 px (aprox. escalándolo al 32 %) para que pueda mostrarse completo en el ancho del espacio visible del dispositivo.
Paso B – C
Esto provoca la clásica vista en miniatura que requiere interacciones de zoom in y zoom out, y que se suele producir en sitios web que no han definido el viewport de forma explícita o lo han definido a un tamaño de escritorio. En el esquema se puede apreciar que la imagen, a pesar de medir originalmente lo mismo que el área visible, se muestra mucho más reducida (al 32 %) para lograr mostrar todo un documento de unos supuestos 980 px de ancho.
Apple fue el creador de esta etiqueta (que no forma parte del estándar y que han adoptado muchos otros navegadores), que introdujo en la versión para móviles de Safari, para responder a la realidad de los navegadores móviles que muestran las páginas en una «ventana virtual» denominada viewport, y que generalmente es más ancha que la pantalla del dispositivo (actualmente existen multitud de tamaños de viewport). De esta manera, se muestra el contenido escalando el conjunto del viewport hasta que encaje con el tamaño físico real de la pantalla del dispositivo.
Esta mecánica es la que posteriormente permite al usuario manejar los sitios web creados para pantallas de escritorio en dispositivos, mediante zoom y desplazamiento en las diferentes áreas de la página.
Con el meta viewport los desarrolladores tienen la posibilidad de indicar al navegador el tamaño de esa «ventana virtual» y, por tanto, gestionar correctamente este comportamiento, tanto en tamaño como en escalado.
El uso habitual y recomendado para compatibilizarlo correctamente con RWD es el siguiente:
<meta name="viewport" content="width=device-width, initial-scale=1">
Como podemos ver, los diferentes atributos van separados por comas, y es importante que sea este carácter, ya que algunos navegadores no interpretan bien otros. Algunos desarrolladores añaden un «maximum-scale=1», pero al igual que «user-scalable=no» no es una decisión recomendable, ya que implica que el usuario pierde la posibilidad de modificar la escala de la vista y por tanto perdemos en accesibilidad. Existe un bug reconocido en iOS frente a los cambios de orientación con esta configuración, para el que también existe una solución o fix.
Finalmente, es importante tener en cuenta que IE10 ha elegido otro camino para dar solución a este comportamiento mediante el denominado CSS Device Adaption, que va acorde con lo propuesto por el W3C.
Media queries
Las media queries (incluidas en la especificación CSS3) son probablemente el componente más comúnmente asociado al RWD (y con un buen soporte en navegadores además de polyfills para IE6-8), y nos permiten aplicar diferentes reglas en las hojas de estilo en función de unas condiciones que se definen a través de ellas tales como anchos, altos, orientaciones, aspect ratios, etc. Por lo tanto, mediante éstas podemos ajustar el layout y elementos visibles en nuestro contenido en función de dichos factores.
Las media queries se pueden aplicar (hablando de su sintaxis) a la hora de definir la etiqueta HTML de una hoja de estilos (a), como parte de una regla import en un fichero CSS (b), o como regla directa dentro de nuestra hoja de estilos (c).
(a) <link rel="stylesheet" media="screen and (max-width: 480px)" href="extra.css" />
(b) @import url(extra.css) screen and (max-width: 480px);
(c) @media screen and (max-width: 480px) { ... }
En todos los casos lo que se hace es aplicar las reglas que incluyen, ya sea como fichero en los casos a y b o como estilos directamente en el caso c, de manera que tienen efecto solamente bajo las condiciones especificadas en la/s condición/es.
La diferencia entre -width y -device-width es sutil, pero importante… -width hace referencia al ancho de la ventana, mientras que -device-width al ancho de la pantalla, por lo que, aunque en un dispositivo móvil esto no tiene efecto al no poder redimensionar la ventana (a día de hoy), en el escritorio sí que es una diferencia importante y, por lo tanto, se recomienda no emplear -device-width como atributo selector.
En el ejemplo existen dos elementos de la media query: el tipo y el atributo.
El tipo en el ejemplo es «screen», que define el escenario en el que se aplicaría, y el atributo sería «max-device-width», que en este caso establece un ancho máximo del dispositivo en 480 px. La combinación de ambas es la que permite o no aplicar los estilos que contiene.
Como vemos en el propio ejemplo, se pueden combinar varias reglas mediante «and» para lograr una regla más elaborada.
En RWD ha sido muy común hasta hace relativamente poco tiempo establecer un conjunto de puntos de corte (breakpoints) en determinadas medidas de ancho, como referencia para los cambios de layout. Si bien es una alternativa, hoy en día y sobre todo tras la aceptación como buen enfoque de la filosofía mobile first, existen puntos de vista que no defienden la existencia de tales puntos de corte de forma absoluta, sino que los relativizan en función de cada diseño / escenario, los difuminan evitando siempre emplear medidas absolutas en las estructuras mediante la aplicación de un layout completamente fluido, o defienden incluirlos en cada componente del diseño de forma separada, ya que todos los elementos de la web no tienen por qué seguir un mismo criterio en cuanto a espacios y layout.
Tomando como referencia el framework frontend más popular en la actualidad (Bootstrap en su versión 3), los puntos de corte que establece en su versión estándar son los siguientes:
/* Dispositivos especialmente pequeños (phones, menores que 768px) */
/* Estilos principales, ya que es el contexto por defecto en Bootstrap */
@media (min-width: 768px) {
/* Dispositivos pequeños (tablets, 768px y superiores) */
}
@media (min-width: 992px) {
/* Dispositivos medios (escritorio, 992px y superiores) */
}
@media (min-width: 1200px) {
/* Dispositivos grandes (escritorios grandes, 1200px y superiores) */
}
No obstante, hoy en día es muy común que los frameworks frontend permitan al usuario personalizar estas características, precisamente asumiendo que, efectivamente, los puntos de corte generalmente no deben ser una decisión aislada del contexto del diseño, contenidos y de cada caso particular.
Modelo de caja: border-box
Como decíamos, el RWD no debería aplicar layouts fijos en cuanto a estructuras en diferentes contextos, sino que entre los diferentes puntos de corte debería tener suficiente flexibilidad como para continuar con ese criterio de adaptación, para lo cual, se hace imprescindible el uso de valores porcentuales o mediante medidas relativas (em por ejemplo) para definir los anchos de las estructuras.
Esta característica ha hecho que se haya popularizado el uso del modelo de caja aplicado mediante la propiedad CSS «box-sizing» (a ampliar con prefijos -mox- y -webkit-) y su valor «border-box», que hoy en día está muy bien soportado por los navegadores.
Este modelo de caja hace que la propiedad «width» incluya el «padding» y el «border», de manera que los valores de estos se descuenten al total, para que el «width» sea siempre el que manda con su valor, independientemente de los cambios de «padding» y «border».
Sistema de rejilla o grid systems
Siguiendo las consideraciones que hemos realizado tanto en el ejemplo de aplicación de media queries como las del modelo de caja, nos toca hablar ahora de los sistemas de rejilla (grid systems).
La experiencia y análisis de la aplicación del RWD a proyectos web ha llevado a muchos desarrolladores a constatar cierto comportamiento deseable y habitual a la hora de gestionar la adaptación de las principales estructuras de contenidos de una web, que ha propiciado que existan en la actualidad multitud de estos sistemas de rejilla.
La base de estas rejillas es el ajuste de los contenidos alrededor de un sistema de filas que contienen columnas que dividen el espacio horizontal disponible, de manera que se puedan trabajar los cambios en los diferentes contextos contemplados en términos de columna en lugar de en medidas concretas. Además, estos sistemas de columnas se han terminado creando con un comportamiento fluido, por lo que no solamente los elementos pueden reajustar su estructura a diferentes columnas en cada contexto, sino que pueden acompañar de forma fluida los posibles escenarios intermedios entre puntos de corte. En la actualidad existen incluso herramientas que nos facilitan la tarea a la hora de crear estas rejillas responsive.
Estos sistemas de rejilla son prácticamente la base de todos los frameworks frontend que aplican la técnica de RWD, de manera que analizando el más extendido de ellos –Bootstrap– se puede encontrar una rejilla por defecto de 12 columnas, que permite gestionar no solamente los cambios de tamaño de los contenidos en sus cuatro contextos responsive (xs, sm, md y lg), sino aspectos como la ordenación (push y pull), visibilidad (visible y hidden) y espaciado entre ellos (offset).
Precisamente en estructuras como estas rejillas flexibles y fluidas es donde el modelo de caja visto con anterioridad cobra más sentido, ya que las columnas que los conforman pueden tener un width porcentual (sin «margin») y jugar tanto como se quiera con el padding o el borde sin que afecte al conjunto de las columnas… logrando por ejemplo tener un padding en «px» en una columna con un ancho en «%».
Frameworks que incorporan el diseño responsive
Prácticamente todos los frameworks frontend hoy en día abrazan el RWD como técnica de desarrollo web, partiendo como hemos dicho de un sistema flexible y fluido de rejilla.
Dentro de estos frameworks podríamos catalogar los que son estrictamente estructurales y centrados en dicha rejilla, y los que tienen un carácter más completo y que habitualmente engloban estilos adicionales, utilidades, componentes e incluso JavaScript.
De entre los principales existentes, destacamos tres como referentes o bien por su potencia y reconocimiento, o bien por su sencillez:
Bootstrap
El framework frontend completo más popular en la actualidad: mobile first en esta última versión, RWD, con soporte para LESS y SASS, personalizable y complementado con un gran conjunto de estilos adicionales, icon-font, componentes, comportamientos en JavaScript…
Foundation
Otro de los frameworks frontend completos mejor valorados por los desarrolladores: filosofía mobile first, RWD, con soporte para SASS, personalizable y complementado con plantillas, iconos, componentes, JavaScript…
Unsemantic
La versión sucesora con RWD del conocidísimo grid960, uno de los sistemas de rejilla más interesantes para comprender su funcionamiento y aislarse de todo lo que no es estrictamente necesario.
Nota:
El código anterior es un ejemplo de formulario de registro HTML. En este caso se pide un nombre, un correo electrónico, una contraseña y un botón para enviar el formulario.