IPad y iPhone: consideraciones para desarrollo web

Consideraciones específicas que debemos tener en cuenta en páginas web orientadas al navegador Safari en dispositivos iPhone OS e IPAD.Traducción libre de la nota técnica TN2262 de Apple.

Preparados para Safari en IPAD 1. Pruebe su sitio web en el IPAD, y actualizar el código de detección de agente de usuario si es necesario Simulando peticiones HTTP de Safari en IPAD 2. Utilizar estándares del W3C Web en lugar de plug-ins Prueba sin plug-ins en Safari en el escritorio 3. Compruebe la configuración de etiqueta viewport 4. Modificar el código que se basa en el posicionamiento CSS fija 5. Prepárese para una interfaz táctil 6. Usar áreas de texto en lugar de elementos contentEditable

Aspectos que debemos tener en cuenta

1. Probar nuestro sitio web en el IPAD y actualizar el código de detección de agente de usuario si es necesario

Muchos sitios web realizan controles en el servidor para la detección del User Agent utilizado por el navegador del usuario. En función de este este parámetro determinan, por ejemplo,  si deben o no servir una versión nóvil de la página web. Si tenemos una versión de nuestro sitio web optimizada para dispositivos móviles con pantallas pequeñas, no debemos servir esta versión móvil a usuarios de IPAD. Esta cadena muestra el User Agent de Safari en IPAD ( IPAD iPhone OS 3.2 beta 3 SDK):

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

Se debe tener en cuenta que en la cadena del User Agent de Safari en IPAD aparece el valor “mobile”, pero no contiene la palabra “iPhone”. Si actualmente estamos sirviendo el contenido optimizado para dispositivos nóviles a cualquier navegador que identifica a sí mismo como “Mobile”, debemos modificar los controles del User Agent para adecuarlos al IPAD. Los números de versión de esta cadena están sujetos a cambios en el tiempo en función de que las nuevas versiones de Safari en IPAD estén disponibles, por lo que cualquier código que comprueba la cadena de agente de usuario no debe confiar en los números de versión.

Simulando peticiones HTTP de Safari en IPAD

Si no tenemos a nuestra disposición un IPAD o un iPhone, podemos simular las peticiones de los navegadores Safari desde otras plataformas. Para ello podemos descargar el navegador a nuestro PC y, a continuación, habilitar la casilla junto a “Show Develop menu in menu bar” en el panel de preferencias avanzadas:

Figura 1: Habilitar nuestro navegador Safari para simular las peticiones de un IPAD o un iPhone

A continuación, seleccionamos Desarrollar – Agente de usuario> -> Otros en el menú. Cuando nos pida que introduzcamos una cadena para el User Agent copiamos la cadena de arriba:

Figura 2: Personalización de la cadena de agente de usuario.

Al hacer clic en “Aceptar”, el campo User-Agent en las cabeceras de petición HTTP se establece con la cadena que acabamos de introducir, y la página se actualizará automáticamente. Cuando recargemos las páginas, debemos comprobar que NO estamos sirviendo la versión de las mismas para dispositivos móviles. Para verificarlo, podemos inspeccionar las cabeceras HTTP en el panel de recursos del  Web Inspector de Safari.

Figura 3: Inspección de las cabeceras HTTP en Safari con Web Inspector

Volver al principio

2. Utilizar estándares del W3C Web en lugar de plug-ins

Los Plug-ins no son compatibles con Safari en IPAD e iPhone.
Si estamos utilizando un plug-in para mostrar elementos de la interfaz web, como menús de navegación u otros elementos en su sitio web, estos elementos no serán accesibles para Safari en IPAD o Safari para los usuarios de iPhone.
Si estamos utilizando un plug-in para integrar audio o vídeo en una página web, puede utilizar las etiquetas HTML5 y para entregar el contenido de audio y vídeo al navegador Safari en IPAD y el iPhone. Estas etiquetas funcionan a la perfección con HTTP Live Streaming, siendo fácil de estructurar el código HTML para devolver el plug-a los navegadores que si los soportan. Para obtener más información sobre el uso de las etiquetas HTML5 y etiquetas, consulte la Guía de Safari de HTML5 para audio y vídeo, las referencias a HTMLMediaElement, HTMLVideoElement,  HTMLAudioElement en la  Guía de referencia de Extensiones DOM para Safari.
Si utilizamos algún plug-in para dibujar animaciones en nuestras páginas web, podemos utilizar una combinación de JavaScript y CSS 3 para crear animaciones en Safari en el iPhone OS. Para obtener más información sobre cómo utilizar CSS para crear animaciones en páginas web, podemos acceder a  Safari CSS, la Guía Visual de efectos en Safari o los códigos de ejemplo que aparecen en Safari Dev Center.

Como comprobar nuestras páginas en Safari deshabilitando los plug-ins

Podemos comprobar como quedan nuestras páginas para IPAD o iPhone deshabilitando los plugins del navegador Safari en Windows o Mac OS. Para ello, desactivamos la casilla “Enable plug-ins” del panel de Preferencias de Seguridad del navegador:

Figura 4: Desactivación de plug-ins en Safari

Despues de recargar nuestras páginas, los elementos que basan su funcionamiento en algún plug-in serán sustituidos por mensajes de aviso. En Safari en IPAD, estas áreas pueden estar en blanco.

Volver al principio

3. Comprobar la configuración de etiqueta viewport

Si estamos utilizando la etiqueta viewport en nuestra página web en su versión para iPhone, debemos comprobar que sus valores son adecuados para Safari en IPAD. En concreto, si deseamos ajustar el ancho de la página para que coincida con la anchura del dispositivo, debemos utilizar la contsante device-width en lugar de un valor en pixeles. Aquí tenemos dos ejemplos de uso incorrecto y correcto del atributo width:

Incorrecto: El uso de un valor en píxeles de ancho de ventana.

name=”viewport”

Correcto: El uso de una constante para el ancho de ventana.

name=”viewport”

Volver al principio

4. Modificar el código que se basa en el posicionamiento fijo mediante CSS

En Safari para iPhone y el IPAD funcionan los selectores CSS para fijar el posicionamiento de los elementos en nuestras páginas web, pero no como se podría esperar. Para las plataformas Mac OS y Windows, los elementos con posición fija apareceran en los lugares desados, el problema viene cuando lo utilizamos para IPAD o iPhone, ya que estos objetos pueden quedar fuera de la pantalla.
Por definición, el bloque de contenido de un elemento en una página web que utiliza el selector CSS de posicionamiento fijo es el viewport. Por ejemplo, cuando se establece position: fixed con valores para los atributos bottom y right de 20px, se “fijado” la posición del elemento 20 píxeles por encima del borde inferior de la ventana y píxeles 20 desde el borde derecho del viewport.

Uso de CSS position: fixed.

#fixed {
position: fixed;
right: 20px;
bottom: 20px;
height: 100px;
width: 100px;
background-color: purple;
}

En Safari para plataforma Mac OS o Windows, el concepto de viewport es análogo al de la ventana del navegador, de forma que si cambiamos el tamaño de esta, se modifica, de igual manera, el del viewpor y el elemento con el selector fixed siempre permanece en la pantalla.
En Safari para IPAD e iPhone no se dispone de ventanas de tamaño ajustable. El tamaño de la ventana viene dado por el tamaño de la pantalla del dispositivo y no puede ser modificado por el usuario. Para desplazarse por una página web, el usuario cambia el nivel de zoom y la posición del viewport utilizando los controles táctiles. Cuando un usuario cambia el nivel de zoom y la posición del siewport lo está realizando dentro de un área de contenido visible de tamaño fijo (es decir, la ventana). Esto significa que los elementos de página web que tienen su posición “fija” para el viewport puede acabar fuera del área de contenido visible, fuera de la pantalla.

Volver al principio

5. Prepárese para la interfaz táctil

A pesar de que se puede utilizar teclado externo con el IPAD, el principal medio de interacción con los contenidos web en Safari en IPAD es a través de la pantalla táctil. El teclado software aparece en Safari en IPAD y en iPhone, cuando, por ejemplo, se requiere la introducción de texto en un formulario — como en elementos o </code> —. En este caso, los usuarios no deberían verse obligados a contar con un teclado externo para interactuar con nuestra página web.</p> <p>En el caso de  <strong>Safari en el iPhone OS</strong>, los usuarios puden interactuar con el contenido directamente con los dedos, en lugar de utilizar un ratón. Esto origina nuevas tareas de adaptación de nuestros interfaces web. Por ejemplo, mediante el movimiento del puntero del ratón en un dispositivo “estándar” se puede activar un evento al flotar sobre un objeto de la página. Esto no se puede llevar a cabo si nos encontramos con una pantalla tactil y, en lugar de utilziar un ratón, estamos utilizando nuestro dedo. Como resultado, los elementos que se basan sólo en <code>mousemove</code>, <code>mouseover</code>, <code>mouseout</code> o la pseudo-clase CSS <code>: Hover</code> no siempre se comportan como se espera en un dispositivo de pantalla táctil como el iPhone o el IPAD.</p> <p>Esto se puede controlar en Safari en el iPhone OS, utilizando los <strong>eventos DOM Touch</strong> (<code>touchstart</code>, <code>touchmove</code>, <code>touchend</code>, y <code>touchcancel)</code>. Los eventos DOM Touch están específicamente diseñados para trabajar con interfaces táctiles, por lo que su comportamiento es fiable y ofrecen el resultado esperado. Para obtener más información sobre su uso se puede consultar la <a rel="nofollow" target="_blank" title="Guia de contenidos web para safari" href="http://developer.apple.com/safari/library/documentation/AppleApplications/Reference/SafariWebContent/CreatingContentforSafarioniPhone/CreatingContentforSafarioniPhone.html#//apple_ref/doc/uid/TP40006482">Guía de contenidos web para Safari</a>, la referencia a las clases  <code>Touch</code>, <code>TouchEvent</code>, <code>yTouchList</code> en la <a rel="nofollow" target="_blank" title="Guia de referencia para extensiones DOM para safari" href="http://developer.apple.com/safari/library/documentation/AppleApplications/Reference/SafariJSRef/index.html#//apple_ref/doc/uid/TP40001482">Guía de referencia de extensiones DOM para Safari</a>, y los códigos de ejemplo en <a rel="nofollow" target="_blank" title="Codigos de ejemplo para safari" href="http://developer.apple.com/safari/library/samplecode/SlideMe/index.html">SlideMe.</a></p> <p>Otro problema surge del uso de los <strong>eventos “pulsar” y “mantener pulsado”</strong> un elemento de la página web. En Safari para iPhone OS el resultado es que nos aparecen los controles para Cortar / Copiar / Pegar, que, por otra parte, pueden ser desactivados mediante la opción <code>-webkit-user-select: none</code>. Esto únicamente debería ser aplicado para elementos concretos, y no de forma global para todos los elementos de la página.</p> <p style="margin-top: -5px;"><a rel="nofollow" target="_blank" href="http://desarrollowebaws.com/diseno-web/600/ipad-e-iphone-consideraciones-de-desarrollo-web/#top">Volver al principio </a></p> <h3>6. <a name="Usar áreas de texto en lugar de elementos contentEditable"></a>Usar áreas de texto en lugar de elementos contentEditable</h3> <p><strong><code>contentEditable</code> no es compatible con Safari en el iPhone OS</strong>. Si estamos utilizando <code>contentEditable</code> para permitir la inclusión de texto dentro de un elemento  (por ejemplo,<code><p contenteditable></code><code> o</code> <code><div contentediable></code>), se puede sustituir por un elemento <code><textarea></code>. En Safari para IPAD, iPhone, Mac OS X y Windows,se puede personalizar la apariencia de <code><textarea></code> mediante elementos CSS. Si es necesario, incluso se puede desactivar cualquier elemento específico de un elemento <code><textarea></code> especificando  <code>-webkit-appearance: none</code>.</p>

Fuente: desarrollowebaws.com