Desde la salida del Retina Display, se duplicó la densidad de pixeles que utilizábamos para diseñar y construir sitios webs para iPhone. Aunque si seguías utilizando los acostumbrados 480x320px de las pantallas anteriores, se nota bastante el pixel en estos nuevos teléfonos. Pero si trabajas para la nueva resolución de 960x640px, ¿qué haces con los modelos anteriores?
Suele ser común el pensamiento que 1 pixel en CSS es 1 pixel en la pantalla del dispositivo. Cuando entramos al nuevo mundo de la alta definición un pixel en CSS termina siendo múltiples en la pantalla. Un ejemplo es si defino un zoom de 2x, entonces 1 pixel de CSS termina siendo 2×2 cuadrados de pixel en el dispositivo. Y eso es lo que está sucediendo desde el iPhone 4.
Entonces, la pregunta es sencilla: ¿Cómo trabajamos con Retina sin dejar de lado las resoluciones anteriores?
La respuesta viene de la mano del potente Mobile Safari y su capacidad de responder mediante CSS3 media queries. Podemos detectar si el dispositivo duplica la densidad del pixel, y si es así modificar el estilo reemplazando las imágenes por una de doble resolución:
<link rel="stylesheet" type="text/css" href="css/normal.css"> <link rel="stylesheet" type="text/css" href="css/retina.css" media="only screen and (-webkit-min-device-pixel-ratio: 2)" >
El secreto está en que definas las imágenes que querrás se vean de mejor calidad en un iPhone 4+ mediante background-image de CSS, por ejemplo:
#logo {
background-image: url('images/logo.png');
background-size: 100px 100px;
background-repeat: no-repeat;
}
#logo {
background-image: url('images/logo_hi.png');
}
Te recomiendo apreciar el ejemplo desde tu teléfono móvil, para que realmente veas los resultados:
Como el navegador va a leer sí o sí normal.css, y por gracia del media="only screen and (-webkit-min-device-pixel-ratio: 2) sólo los dispositivos que tengan duplicados su resolución leerán retina.css y sobreescribirán los estilos definidos en esta hoja de estilos por sobre la anterior. La idea es que sólo definas las propiedades que cambien, no es necesario que reescribas todo el código.
Otra manera es hacerlo mediante JavaScript, la cual encuentro innecesaria pero de todas maneras dejo la opción:
<script type="text/javascript">
if (window.devicePixelRatio >= 2) {
document.write("<link href='css/retina.css' rel='stylesheet' type='text/css' media='screen' />");
} else {
document.write("<link href='normal.css' rel='stylesheet' type='text/css' media='screen' />");
</script>
iPad, iPad, iPad… otro nuevo dispositivo para cautivar a los ávidos consumidores, pero que por lo menos trae interesantes nuevas tecnologías. Aparte de que crean que es un iPhone gigante, tiene varias innovaciones que permiten darle mucha rienda a la imaginación de los creadores de contenido específico para esta plataforma. Una de las que más me han interesados, corresponde a los eventos gestuales.
Este artículo abordará todos los eventos disponibles para iPad y que ocurren cuando el usuario interactúa con una página web en iOS. Aunque puedes visualizar los ejemplos con Safari 5 para escritorio o el mismo iPhone, la mejor interacción la puedes lograr desde un iPad mismo por la dimensión y calidad de su superficie táctil (o en su defecto con su simulador).

Puedes usar classes de eventos touch de tipo DOM en Javascript que ya están disponibles en iOS. Si quieres registrar estos eventos, el sistema envía objetos TouchEvent a aquellos elementos DOM mientras los dedos se mueven por sobre la superficie. Una secuencia multitouch comienza cuando un dedo toca por primera vez la superficie. La secuencia termina cuando el último de esos dedos se levanta de la misma superficie. Éstos eventos son similares a los usuales eventos de mouse, excepto que puedes tener toques simultáneos en la superficie en diferentes lugares de la misma. Un objeto de evento touch es utilizado para encapsular todos los toques que existen en un mismo momento en la pantalla. Cada dedo es representado por un objeto touch y las típicas propiedades que encuentras en un evento de mouse están en un evento touch, pero no el objeto mismo.
Cuatro son los principales eventos touch:
Para registrarlos con Javascript:
element.addEventListener("touchstart", touchStart, false);
element.addEventListener("touchmove", touchMove, false);
element.addEventListener("touchend", touchEnd, false);
element.addEventListener("touchcancel", touchCancel, false);
Y si lo quieres implementar como una función:
function touchStart(event) {
// tomemos las coordenadas del dedo cuando toca la pantalla
var x = event.touches[0].pageX;
var y = event.touches[0].pageY;
alert('X = '+x+',Y = '+y);
}
Un simple evento: arrastra un elemento cuando mueves el dedo:
function touchMove(event) {
event.preventDefault();
var touch = event.touches[0];
var node = touch.target;
node.style.position = "absolute";
node.style.left = touch.pageX + "px";
node.style.top = touch.pageY + "px";
}
![]()
Detalle: por defecto, si arrastras un dedo sobre la pantalla es probable que la página comience a moverse (peor si ésta tiene scroll). Por suerte agregaron la función preventDefault() que hace que la página se quede quieta si lo necesitamos.![]()
Las listas de eventos agrupan estos objetos, y contiene información para cada dedo que está tocando la pantalla. Además, contiene 2 otras listas: una que tiene información para los dedos que se originan del mismo elemento y otro que contiene sólo información para los dedos asociados al mismo evento. Estas listas están disponibles para cada evento touch, y son:
Las propiedades que contienen estas listas son:
Para entender mejor, veamos el siguiente caso:
Cuando pongo un dedo en la pantalla, las 3 listas tendrán la misma información en sus propiedades, pero changedTouches fue el que originó el evento.
Cuando pongo el segundo dedo, touches tendrá 2 items (uno para cada dedo); targetTouches tendrá 2 items sólo si el segundo dedo es posado en el mismo elemento del primero; changedTouches tendrá información relacionada al segundo dedo, porque fue lo que causó el evento.
Si pongo 2 dedos exactamente al mismo tiempo, tendré 2 items en changedTouches: uno para cada dedo.
Si muevo mis dedos, la única lista que cambiará es changedTouches y va a tener información relacionada a cada dedo que se vaya moviendo (al menos uno).
Cuando levanto un dedo, será eliminado de touches y targetTouches y aparecerá en changedTouches ya que fue el que originó el evento.
Si quito el último dedo se vaciarán touches y targetTouches, y changedTouches tendrá la información para ese ultimo dedo.
Eventos multitouch pueden ser combinados para crear eventos de gestos. Los objetos GestureEvent son enviados durante una secuencia multitouch y contienen información de dimensiones y rotaciones.
Para registrarlos en HTML:
<div ongesturestart="gestureStart(event);" ongesturechange="gestureChange(event);" ongestureend="gestureEnd(event);" >
Y mediante Javascript:
element.addEventListener("gesturestart", gestureStart, false);
element.addEventListener("gesturechange", gestureChange, false);
element.addEventListener("gestureend", gestureEnd, false);
Comencemos con un ejemplo simple:
function gestureStart(event) {
// tomamos el angulo y tamaño del elemento
var angle = event.rotation;
var scale = event.scale;
alert('angulo: '+angle+', dimension: '+scale);
}
Ahora escalamos y rotamos un elemento:
function gestureChange(event) {
event.preventDefault();
event.target.style.width = (200 * event.scale) + "px";
event.target.style.height = (200 * event.scale) + "px";
event.target.style.webkitTransform = 'rotate(' + event.rotation + 'deg)';
}
Creo que esto es un buen comienzo para que te interese esta plataforma, la que implementa un tipo de interacción háptica poco usual y con un gran potencial comercial.
En un campo de formulario, cuando lo seleccionas en iPhone/iPad para completarlo, automáticamente te muestra el teclado touch del aparato. Aparte del teclado QUERTY por defecto, existen 3 valores para type="" de <input /> que muestran diferentes tipos de teclados: numéricos, url y de e-mail:
<input type="text" /> (por defecto)

<input type="url" />

<input type="number" />

<input type="email" />

Los browsers que no soporten HTML5 lo obviarán y degradarán como si fuera un campo de tipo texto (type="text").
Se nota como un detalle menor pero seguro tus usuarios lo notarán y te diferenciarás con este tipo de detalles.
]]>Poner en práctica este tema me ha costado mucho tiempo de documentarme, de pruebas y errores. Si te vas a aventurar en este medio, creo importante que tengas claro algunos puntos y otros que se los transparentes al cliente, todo para evitar posteriores decepciones:
Desde que salió el iPhone, se abrió una nueva manera de tratar sitios web para móviles. Se pensaba que con el marcado WML y estilos básicos bastaban, pero Apple demostró que se puede hacer mucho más y mejor en tan poco espacio. Google ofrece mucho con su navegador basado en Webkit, Opera soporta XHTML en su Opera Mini. Es importante que sepas cómo y qué te ofrece cada dispositivo, y eso se lo traspasas a tu cliente.
Básicamente iPhone es el que tiene mayores diferencias en la manera de tratar el código fuente, así que es mejor hacer una versión del sitio sólo para este dispositivo. Agrupa los smartphones (Blackberry, Nokia) y crea una versión con buen HTML y estilos sobrios; cuida que el HTML sea sencillo para el resto de los browsers más limitados (Palm, Windows Mobile). Para detectarlos, te recomiendo un sencillo pero útil script en PHP que hace el trabajo por tí.
He tenido grandes decepciones con las versiones del browser de Blackberry y Nokia: suelen comportarse diferente entre modelos inmediatos, y esas diferencias son sustanciales. Lamentablemente, te recomiendo que uses HTML 4 y CSS1 para asegurarte con todos los modelos de estas marcas.
Si debes validar campos de formularios, déjaselo al servidor y no al browser. Al contrario de iPhone, muchos teléfonos traen Javascript deshabilitados por defecto. No esperes que el usuario los haya habilitado manualmente; si puedes, evítalo.
Una lástima, pero te recomiendo que le agregues a tu lista de amigos, el modelo y versión de teléfono celular que tiene cada uno para que te ayuden a probar tus desarrollos. Sólo así tendrás certeza del correcto funcionamiento que esperan tú y tu cliente.
Si crees que por ser sitios menores te será fácil, te decepcionarás: son muchas más las variables que debes tener presente, y probablemente el esfuerzo será mayor. Planifica muy bien con tu cliente lo que él espera ver e interactuar mediante un móvil, aterrízalo con las limitaciones que encuentres y lleguen a un acuerdo razonable para ambos.
Lo bueno es que iPhone usa Safari como browser (hasta ahora, único). Estoy muy acostumbrado con su uso y manejo, así que conozco bien sus potenciales. Para ser específico, el motor de iPhone es el WebKit 419.3, (el que correspondería al de Safari 2 para plataformas Mac OS X). Es posible crear sitios que sólo sean vistos por este Safari, tal como una hoja de estilos media="handheld" es leída sólo por dispositivos móviles; ya iPhone no lo interpreta, utiliza por defecto la hoja de estilos principales (sea media="all" ó media="screen").
Entonces ¿cómo lo hace?
Para crear estilos sólo para iPhone, podemos linkear una hoja de estilos externa pero con un cambio en el atributo media:
<link href="estilos_iphone.css" rel="stylesheet" media="only screen and (max-device-width: 480px)" />
Este cambio en media es propio de CSS3, una de las ventajas de Safari. Dice precisamente que para anchos de pantalla de hasta 480px (que es el ancho máximo del iPhone en apaisado) utilice tal hoja de estilos. Ahora, para los otros anchos (computadores personales):
<link href="estilos_iphone.css" rel="stylesheet" media="only screen and (min-device-width: 481px)" />
Nuevamente, esto sólo funcionará en Safari 2+ para Mac OS X ó Windows; para que se comporte debidamente en todos los browsers, recomiento primero linkear la hoja de estilos general como siempre lo han hecho (media="screen"), y a continuación la del iPhone con el media="only screen and (max-device-width: 480px)" que ya mostré.
La otra manera (que utilizaré en los ejemplos, los que podrás notar diferencia si los ves con un iPhone, claro) ya la había mencionado en un artículo anterior, y se usan juntos del mismo estilo:
@media screen {
// estilos para todos los browsers
}
@media screen and (max-device-width: 480px) {
// estilos sólo para iPhone
}
También puedes detectar si el sitio se está leyendo desde el iPhone y redireccionarlo a otra página mediante PHP (que fue lo q usé para CSSLab), como por ejemplo:
if (stristr($_SERVER['HTTP_USER_AGENT'], ‘iPhone’)) {
// redirecciona
}

Otro punto a tener en cuenta es la etiqueta <meta> y el valor viewport. Con él podemos manejar varias propiedades al momento de cargar la página en sus iPhone. Sus valores son:
<meta name="viewport" content="width=300, user-scalable=no" />
Otro punto es la capacidad de esconder la barra de URL que tiene Safari, y desplegar la página sin ella. A través de Javascript podemos hacer ese desplazamiento apenas la página cargue, de la siguiente manera:
setTimeout(function(){
window.scrollTo(0, 1);
});
Esto funciona sólo si el alto de la página es mayor al de la ventana al momento de cargarse.
Otro punto a considerar es la capacidad de interactuar con elementos propios de iPhone a través de simple HTML y enlaces, por ejemplo:
<a href="tel:6666666">Hacer llamado</a>
<a href="mailto:usuario@dominio.com">Envia un e-mail</a>
<a href="http://maps.google.com/maps?q=santiago+chile">Santiago, Chile</a>
El ultimo punto que mencionaré en este artículo, es el poder de Safari cuando hablamos de estilos. Principalmente, cuando queremos aplicar estilos para elementos de formulario. WebKit tiene propiedades propias que podemos finalmente utilizar sin vergüenza: radio, opacidad y sombras, entre otros:
Finalmente, algunos aspectos técnicos sobre Safari y la plataforma misma iPhone.
