Preparando nuestras webs para el Ipad

Que el Ipad está entre nosotros no es novedad y que llegó para quedarse tampoco así que todo esto no debe sorprender a nadie, ya dijimos algo breve sobre ella y es nota de tapa en todo el mundo (de hecho ya aparecieron infografías contando lo que está pasando con ella).

Hoy vamos a hablar de algo mucho más mundano y mucho más centrado en lo que a nosotros desarrolladores nos importa, cómo preparar nuestras webs para este nuevo chiche, tenemos que tener algo en claro?, bueno, si venimos haciendo las cosas bien, poco..., vamos por partes:

1. Revisar el viewport para el Ipad

Quienes desarrollan o desarrollaron para Iphone, seguramente escucharon hablar del "viewport", en resumen, cuando hablamos de él hablamos de la parte "visible" de una página dentro de un navegador, es decir, sacando scroll-bars, menúes, etc., cuánto espacio nos queda disponible para nuestro sitio?, bueno, en Iphone la respuesta es 320 x 356 pixels cuando trabajamos en vertical y 480 x 208 pixels cuando lo hacemos en horizontal. Con esto en mente muchas veces le indicamos al Safari del Iphone cómo "escalar" o como formatear el texto (donde va el "wrap") mediante una instrucción del estilo:

<meta name="viewport" content="width=320" />

Lo cual le indica al Safari que debe preparar la página para mostrarse a 320px de resolución, el tema es que el Ipad tiene otra resolución y no podemos poner varios viewports condicionales ni cosa por el estilo, asi que vamos a optar por lo correcto desde el primer momento:

<meta name="viewport" content="width=device-width" />

Lo cual le va a decir al Safari que utilice el ancho del dispositivo en cuestión para mostrar el contenido, simple y elegante.

2. Ojo con el posicionamiento

Si nos metimos a hacer posicionamientos raros con CSS vamos a tener que revisar esto también, sobre todo en el caso del posicionamiento "fixed", dos cosas:

1. No, no es el más usado y la verdad no lo recomiendo.
2. Si trabajan en Iphone ya saben para que lado va esto y seguramente no lo están usando.

Este posicionamiento ubica un elemento de acuerdo al viewport, en el caso de los desktops el viewport puede cambiar de tamaño con lo que este posicionamiento se usa a veces para ubicar cosas en un ángulo. Para ver el problema, sepamos que tanto Iphone como Ipad no tienen viewports que puedan cambiar de tamaño, y entendamos que en un desktop cuando nos movemos lo hacemos con las barras de scroll, moviendo el viewport dentro de la ventana, por lo tanto las coordenadas del viewport son estables.

Con esto en mente pensemos ahora que en el Ipad (y el Iphone) la navegación no es por scroll sino por zoom y por movimientos del viewport dentro de la ventana, así, lo que nos podría pasar entonces es que lo que posicionamos quedó fuera del espacio utilizable por estar atado a un viewport que cambia constantemente.

3. El nuevo UserAgent del Ipad

Los que me conocen saben que no soy un fan del uso del User-Agent pero a veces no nos queda otra alternativa, siendo así, hay que adaptarse a los tiempos que corren, el Ipad se presenta como:

Mozilla/5.0 (iPad; U; CPU OS 3_2 like Mac OS X; en-us) AppleWebKit/531.21.10
(KHTML, like Gecko) Version/4.0.4 Mobile/7B334b Safari/531.21.10

La mejor forma de probar nuestro código es configurando nuestro Safari de desarrollo para mostrar este UserAgent y así ver si estamos haciendo las cosas bien, esto lo hacemos desde "Develop -> User Agent -> Other"

4. Por si no lo saben a Steve Jobs no le gusta el Flash

O sea, no usen plugins, lo dicen todo el tiempo..., si quieren mostrar algo va a tener que ser mediante HTML5 con los tags audio o video.

5. Estándar sí, pero no tanto...

Si están pensando en desarrollar la aplicación de su vida hay que prestar mucha atención al estándar y su interpretación, por ejemplo los fanáticos de las interfaces ricas seguramente conocen al atributo contentEditable el cual fue inicialmente impulsado por Microsoft pero con el tiempo adoptado por todos. Este atributo convierte un campo de formulario en un editor WYSIWYG con todas las de la ley y sin necesidad de que nosotros debamos codificarlo, excelente, pero el Ipad no lo soporta, tenemos que volver al viejo y querido textarea.

6. Por supuesto, hay que manejar una interfaz táctil

De eso se trata todo esto no?, una interfaz táctil tiene eventos diferentes y movimientos diferentes, no hay mouse, no hay teclado, hay dedos.

Eventos de javascript como mousemove, mouseover y mouseout o pseudo-selectores de CSS como el hover no tienen sentido. Pero ahora tenemos touchstart, touchmove, touchend y touchcancel.

7. Manos a la obra!

Aparte de lo que brevemente les quise contar tenemos también extensiones al modelo DOM de las que podemos hablar en algún momento pero por ahora parece suficiente como para darles coraje a preparar nuestros sitios, sobre todo si ya trabajan para Iphone el cambio se puede resumir a unos cuantos caracteres.