El origen de responive web design, para adaptar webs a teléfonos móviles principalmente, es un artículo aparecido en A List Apart con el título de tachán... responsive web design. La técnica consiste en usar:

• rejilla flexible
• CSS3 Media Query
• Imágenes flexibles (ver fluid images)

En el fondo no hay nada nuevo: Media Query es una potente evolución de media types presente en CSS2, y el uso de rejilla e imágenes flexibles ya era conocido desde hace tiempo.

Hispanizando el término

Parece sencillo traducir el término original responsive design por diseño responsivo. Pero consultando el diccionario de la RAE, me ha costado encontrar uno buena traducción que respete el espíritu del término original. Gracias a la buena gente en twitter encuentro buenas alternativas:

• diseño web adaptable (@1984), con la puntualización de @isbl (diseño web adaptable a cualquier resolución de pantalla).
• diseño web adaptativo (@iagor)
• diseño web autoadaptable (@ala_747)

A mí personalmente me parece mejor la opción diseño web adaptativo, si hacemos caso al diccionario (definición de adaptativo en la RAE):

adaptativo

Perteneciente o relativo a la adaptación o a la capacidad de adaptación.

Esa capacidad de adaptación es lo que me parece más apropiado. Pero bueno, cuestión de opiniones: todas las argumentadas son bienvenidas.

¿Cómo funciona?

Tenemos una típica web con su código HTML, CSS, javascript (imprescindible una librería, como jquery y sus correspondientes plugins) y un buen puñado de imágenes. Todo ese código es el que se envía al navegador y le toca al potente ordenador de sobremesa (o al no tan sobrado de potencia teléfono móvil) procesarlo. Lo cuál equivale a descargarse todo, filtrar los estilos que le corresponden, ocultar los elementos invisibles (pero descargados) y mostrarlo en las pantallas de nuestros cacharros, ya sean grandes o pequeños, potentes o justitos. Siempre y cuando sepan interpretar el código...

Ahí hay un problema: se confía demasiado en el dispositivo de destino (velocidad de conexión y procesador, memoria, capacidad de comprender el código), y en ocasiones se le envía demasiados recursos, aunque no los muestre (y es una pérdida de tiempo y recursos que en ocasiones puede ser exagerado).

¿Es la mejor forma de crear una web móvil?

En palabras del que puso nombre a la técnica...

I think of responsive design as an alternative to mobile sites.

Ethan Marcotte — Ethan Marcotte on responsive web design

Lo considera una alternativa al diseño de una web específica para móviles. Y yo añado que no es la mejor alternativa. Sigo pensando que un buen trabajo de desarrollo en el servidor, con detección de dispositivos (mediante WURLF por ejemplo) y envío de contenido optimizado para dicho dispositivo, obtiene resultados mucho mejores que la técnica de diseño web adaptativo. Una muy buena explicación, la puedes encontrar en la presentación Why responsive design actually begins on the server a partir de la página 83.

¿Existen ocasiones en las que el diseño web adaptativo puede ser una alternativa razonable para ciertos proyectos web? Por supuesto, depende del tipo de web, de los recursos disponibles, del contenido que se muestra,... Una web ligera (no como esas de 5 megas), con pocos elementos multimedia, pocas imágenes, sobre todo texto, pocos recursos de tiempo y dinero, personal con conocimiento front pero no de lenguajes de servidor... es un proyecto ideal para poner en práctica la técnica de diseño web adaptativo. Al menos es algo.

Pero seamos sinceros: el diseño web adaptativo no deja de ser un truco de maquetadores con más o menos conocimiento de CSS y HTML para intentar que una web no se vea demasiado mal en ciertos teléfonos móviles. Es mejor que nada, pero dependiendo de la web, puede ser una chapuza o algo brillante.

Me permito recomendar dar un vistazo a la presentación Pragmatic responsive design. Me parece muy completa y un trabajo más que correcto. Un buen ejemplo a seguir.

Algunos consejos para diseño web adaptativo

Bueno, hablo en concreto de CSS3 Media Query.

• Para teléfonos móviles no tiene sentido usar handheld o screen. Desde que el iPhone dejó de considerarse un dispisitivo handheld desde el punto de vista del CSS, ha sido el primero de una larga lista de dispositivos en considerarse similares a, por ejemplo, un iMac de 27". Y no es lo mismo una pantalla de 3,5" que una de 27".
• No tiene sentido tampoco tener en cuenta exclusivamente la resolución de pantalla. El teléfono móvil Samsung Galaxy Nexus tiene una resolución de 1280x720 px. Muchos netbooks tienen resoluciones de 1024x600. Es uno de los muchos factores a valorar.
• Algo que casi nadie ha utilizado, que sepa, y que puede ser muy útil: tener en cuenta, no la resolución de pantalla, sino el tamaño de la pantalla en pulgadas. Ahí va una clasificación discutible: móviles menos de 6", tablets entre 6" y 10", ordenadores... más de 10" (la pena es que la resolución de 10" es usada por tablets y ordenadores). Tras estar haciendo pruebas, creo que es un punto de partida razonable. Además, funciona. Con un extra importante...
• Usar la resolución —desde el punto de vista de la densidad de pixels— para diferenciar la calidad de las pantallas. Ver donde se explica en Media Queries 4.11. resolution y en DPI Calculator / PPI Calculator para ver la resolución de pantalla de diversos dispositivos y una práctica calculadora.
• Recuerda las televisiones: muchas pulgadas de pantalla pero forzosamente tienen que usar un tamaño de texto más grande: el móvil, la tablet o el ordenador lo tenemos como mucho a medio metro de distancia. Un televisor puede estar a dos, tres o más metros.

El contexto

Aunque ya está muy visto, es obligado recordar que cada proyecto se desarrolla en un contexto y factores como el presupuesto, el objetivo de la web, conocimientos técnicos, el contenido, los dispositivos,... y los teóricos usuarios de la web. Un sitio para ver estadísticas de internet es statcounter, por continentes, países, sistemas operativos, móviles,... Ignoro su fiabilidad, pero debería abrir los ojos a más de uno.

El factor Be Cool

Un par de asuntos recurrentes. Por decirlo de una manera suave, empiezo a estar bastante hasta las narices, de que en la teoría y en la práctica, los únicos dispositivos que se utilizan para hablar o aplicar el responsive design (o para esos dos o tres lectores de xposible "diseño web adaptativo"), son los de Apple. Vale que queda muy vistoso utilizar imágenes de los cacharros de Apple y optimizar el CSS para el iPhone y el iPad en vertical y apaisado, pero hay más dispositivos. No les fastidies.
Pero el colmo es suponer que todos los cacharros que se conectan a internet tienen el núcleo webkit. Usar prefijos "beta" e ignorar los equivalentes de otros núcleos (-moz, -khtml, -ms, -o) o directamente las recomendaciones del W3C cuando funcionan. Una falta de profesionalidad preocupante. Luego pasa lo que pasa: Is the fat lady singing for Vendor Prefixes?.

Un gran poder conlleva una gran responsabilidad.

Ben, tío de Peter Parker.

La versión larga la puedes encontrar en [CSSWG] Minutes and Resolutions Paris F2F Monday Morning 2012-02-06: Administrivia, Vendor Prefixes, Property/Value Alias OM apartado Vendor Prefixes (sólo conozco a una persona que la lee por iniciativa propia). Una versión digerida en WebKit Isn’t Breaking the Web. You Are y la llamada a la acción en CALL FOR ACTION: THE OPEN WEB NEEDS YOU *NOW*.

Confieso que soy tengo tendencia conservadora con respecto a las tecnologías webs: prefiero utilizar las novedades cuando están bien asentadas. He de confesar también que mis conocimientos en CSS3 son más bien limitados, por no hablar de HTML5.

¿Tiene sentido ser un desarrollador web y no estar al tanto de las últimas tecnologías? Probablemente no.

¿Tiene lógica esperar a usar en producción algo que todavía está en fase alfa o beta y se desconoce si al final se implementará o no? Desde mi punto de vista sí. Y más teniendo en cuenta lo que sabemos con el ritmo de actualización de ciertos navegadores.

¿De qué hablo? El abuso inconsciente de característcas en fase alfa-beta de implementaciones de CSS que publica webkit (sí esas que empiezan con -webkit-) por parte de los desarrolladores webs.

¿Por qué? Porque en numerosos sitios se está provocando que la web sólo funcione en los navegadores con webkit (Safari, y navegadores por defecto de iOS y Android). Se está rompiendo la web. Y un gran perjudicado es Opera, hoy por hoy el navegador más usado en los teléfonos móviles en el mundo (ver el gráfico Top 9 Mobile Browsers from Jan 2011 to Jan 2012 ahora mismo, Opera es el número uno con un porcentaje de casi un 24%) por no hablar de otros navegadores, como Firefox, que tienen problemas con webs específica para móviles. No tiene sentido.

El asunto tiene muchos puntos de vista: por un lado está la posibilidad de que los navegadores mejoren (y los prefijos propietarios de los navegadores en CSS no deja de ser innovación), por otro lado el mercado de los navegadores, los desarrolladores, los clientes, las especificaciones del W3C (ahora documentos vivos en constante evolución),... y los usuarios.

Estaremos de acuerdo en que la velocidad a la que avanzan las especificaciones del W3C  es demasiado lenta. Pero abusar de características "beta" que implementan algunos navegadores puede ser una temeridad. Y si no nos fijamos si existen alternativas a otros navegadores (más líneas de CSS para implementar características en otros navegadores) rozamos peligrosamente la falta de profesionalidad. Por último, si con el uso de los prefijos de CSS estamos consiguiendo que la web no se visualice correctamente en otros navegadores, o incluso falle de forma escandalosa, entonces deberíamos tener una orden de alejamiento de un editor de código.

CSS-based responsive web design is a great tool for adapting a layout to different screens, period. It is a tool, not an end. In some cases, where a site’s content should be the same from device to device (a blog, for example), responsive web design is enough for the job. More complex services, though, may need much more, including different content, tools, and services.

Yes, friends: it depends.

What’s it depend on? Certainly the needs of the audience. But as with so many things, it often depends a great deal on business considerations, too.

Josh Clark - Responsive Web Design or Separate Mobile Site? Eh. It Depends.

Cita extraída de un artículo que resume una animada discusión entre los partidarios del responsive web design (muy resumido, el uso de Media Query para adaptar la presentación de una web a los diferentes dispositivos) y los que van más allá de la mera presentación de contenidos: optimizar las experiencias según el contexto de uso y de usuarios.

Nada nuevo, en definitiva. Aunque técnicamente ahora es posible obtener mejores resultados que hace no muchos años: hay ejemplos más o menos elaborados en mediaqueri.

Ya puestos, otro artículo que nos puede ayudar a ampliar nuestra perspectiva histórica es New to Mobile? Welcome to the One Web Debate.

Se puede hacer una aplicación web para iOS con HTML, CSS y Javascript, y se indica mediante algunos elementos meta. Aquí va un pequeño resumen:

• <meta name="apple-mobile-web-app-capable" content="yes" /> Da la opción al dispositivo iOS añadir a la pantalla de inicio, junto con el resto de las aplicaciones, un acceso directo a una aplicación web. Ojo que no es lo mismo que un acceso directo que abre Safari con la interfaz habitual del navegador.
• <meta name="apple-mobile-web-app-status-bar-style" content="black" /> Permite quitar de la interfaz los elementos propios del navegador (la barra de la dirección y el buscador arriba, y la barra de navegación, favoritos e historial abajo). Sólo deja visible la barra de estado (cobertura, hora y batería). Tiene tres posibles valores default (de azul iOS), black y black-translucent.
• <link rel="apple-touch-icon" href="touch-icon-iphone.png" /> permite elegir el icono (57x57 en formato PNG) para la pantalla de inicio. Sirve tanto para aplicaciones web como para simples accesos directos a una página web.
• <link rel="apple-touch-startup-image" href="/startup.png" /> incluye una imagen previa a la aplicación web.

No hablo del famoso viewport, aunque personalmente echo de menos la posibilidad de usar una etiqueta para que mantenga la proporción en las vistas vertical y apaisada.

Bueno, siguiendo estas claras instrucciones - risas de fondo - tenemos los primeros elementos para hacer una aplicación web. Qué modernos.

Y ahora viene una curiosidad, que puede tener su sentido, pero resulta chocante: cuando tocamos un vínculo, abre una nueva instancia del navegador, pero esta vez aparece los elementos de la interfaz "normal" (barra de estado, además de la barra de la dirección y la de navegación-favoritos). ¿Qué ocurre? ¿Qué hemos hecho mal?

La respuesta es... nada. Simplemente los vínculos no funcionan como tales en una aplicación web dentro de iOS. Actúan como una especie de window.open. ¿Solución? Un poco de javascript. Aquí va un ejemplo de jquery:

$(document).ready(function() {
	var deviceAgent = navigator.userAgent.toLowerCase();
	var ios = deviceAgent.match(/(iphone|ipod|ipad)/);
	if (ios) {
		$("a").click(function(event) {
			event.preventDefault();
			var direccion=$(this).attr("href");
			location.href=direccion;
		});
	};
});

Por si el código no resulta demasiado trivial, mediante el agente de usuario discriminamos a los dispositivos con sistema operativo iOS, eliminamos el comportamiento por defecto de los vínculo, y le añadimos la url del href a un location.href de javascript que sí funciona. En este caso podríamos tener una aplicación web compuesta por varias páginas HTML.

Teniendo en cuenta lo anterior, cabría preguntarse:

• ¿Quieres un acceso directo a la página de inicio definiendo la imagen tú mismo (y que no salga un pantallazo)? Usa apple-touch-icon.
• ¿Quieres que no se vea la barra de la dirección inicialmente? Prueba con window.scrollTo(0,1); e inicialmente no se verá (aunque estará presente).
• ¿Quieres reutilizar una web como una aplicación web en iOS (más cool) con su imagen de bienvenida - tan útil ella -, y sin elementos de la interfaz en el navegador? Pues mucho cuidado con los vínculos, y recuerda el código anterior para los vínculos internos de la aplicación web. No quedaría bien que al tocar un vínculo, se abra una nueva ventana. Nada bien.

Cambiando un poco de tema, ya hay bastantes voces (con más o menos autoridad) que dicen que las aplicaciones desarrolladas específicamente para un sistema operativo (Android, iOS, Blackberry, Symbian, Windows Phone,...) están viviendo su momento de gloria ahora, y en unos años, será sustituído por aplicaciones webs (teoricamente menos tiempo de desarrollo, y actualizaciones más rápidas). Todo depende de los avances en las aplicaciones web móviles y su implementación (ver Standards for Web Applications on Mobile: February 2011 current state and roadmap).Ya veremos.

El debate, los conflictos y la colisión es inevitable. Sobre todo cuando  no se juega limpio (¿alguien ha hablado de la seguridad?).

Volviendo al W3C: el documento publicado, en estado de Working Group Note (una especie de "informe técnico") es el siguiente: W3C Guidelines for Web Content Transformation Proxies 1.0.

Para ir abriendo boca, aquí va un pequeño extracto de la introducción:

Content Transformation proxies alter requests sent by user agents to servers and responses returned by servers so that the appearance, structure or control flow of Web applications are modified. Content Transformation proxies are mostly used to convert Web sites designed for desktop computers to a form suitable for mobile devices.

Based on current practice and standards, this document specifies mechanisms with which Content Transformation proxies should make their presence known to other parties, present the outcome of alterations performed on HTTP traffic, and react to indications set by clients or servers to constrain these alterations.

The objective is to reduce undesirable effects on Web applications, especially mobile-ready ones, and to limit the diversity in the modes of operation of Content Transformation proxies, while at the same time allowing proxies to alter content that would otherwise not display successfully on mobile devices.

Important considerations regarding the impact on security are highlighted.

Guidelines for Web Content Transformation Proxies 1.0

Hay que darle un vistacillo.