Internet Explorer 10 es un navegador rápido, con una serie de estándares ya incluidos y la versión de Internet Explorer 10 para Windows 8 no es la excepción: es prácticamente idéntica a su primo en la computadora de escritorio. Pero IE10 tiene un problema: los desarrolladores web no esperan que aparezca en el mercado móvil. La web en dispositivos móviles está dominada por navegadores basados en WebKit y los sitios móviles tienden a ser desarrollados, y probados exclusivamente sobre los navegadores que usan este estándar.
Frecuentemente el desarrollo se hace más limitado incluso, aunque ambos, Android e iOS usan navegadores basados en WebKit, iOS es quien domina el mercado y domina las pruebas y los resultados obtenidos. La situación de hecho es familiar: WebKit, especualmente sobre iOS, ocupa una posición similar a la que tuviese IE6 en las máquinas de escritorio, donde el contenido web “se veía mejor con Internet Explorer 6”. Los otros navegadores en ese entonces batallaban por hacerse de más usuarios.
En una especie de súplica para no quedar fuera, Microsoft está literalmente implorando a los desarrolladores web que adapten sus sitios. En un artículo en su blog, el gigante de las ventanas explica una variedad de maneras en la que los desarrolladores pueden actualizar sus sitios de manera que no requieran del WebKit. La clave de todo esto es el manejo apropiado de las características incompatibles.
De hecho, hay muchas fuentes de incompatibilidad. El caso más complicado es aquel que simplemente es propiedad del WebKit. Los otros casos son el resultado de un proceso de estandarización para las especificaciones web. Cuando una especificación CSS o Javascript está bajo desarrollo y aún sujeta a cambio, los navegadores que las implementan se supone, añaden un prefijo a la propia especificación del navegador a los elementos CSS y Javascript que usan. Por ejemplo, mientras está aún en desarrollo, la implementación del Webkit del CSS de los bordes redondeados debería usar propiedades como webkit-border-radius. Una vez que el estándar se vuelve estable y un navegador lo implementa como un estándar estable, la propiedad solamente debería renombrarse a simplemente border-radius.
En alguno estándares, ambos navegadores implementan la versión estable, sin siquiera usar el prefijo requerido. Sin embargo, los desarrolladres frecuentemente no actualizan sus páginas para acomodarse a las mejoras que se van haciendo en los estándares, dejando a sus páginas con los prefijos, pero sin incluir el equivalente del código ya sin el prefijo. En este caso, la solución es simplemente quitar los prefijos. Algunas veces la especificación no es estable y los diferentes navegadores implementan versiones incompatibles de la especificación, cada una con su propio prefijo. En este caso, las propiedades deben traducirse de un dialecto a otro, por decirlo de alguna manera.
Hay otros casos en los que la traducción es aún más compleja, particularmente cuando se trata de usar la interfaz táctil. Apple es pionero en este campo con Safari, y uana especificación llamada Touch Events basada en Safari, pero creada sin que Apple se haya involucrado, es actualmente la recomendación candidata para el Consorcio WWW (W3C), el organismo que trabaja en producir estándares web. Microsoft ha propuesto una alternativa llamada Pointer Events que no sólo manejaría la parte táctil, sino entradas por ratón o pluma de una forma consistente. Por razones técnicas y legales, el W3C ha deciudido que en lugar de trabajar en una versióin 2 de Touch Events 2, todos los futuros desarrollos en esta área serán con Pointer Events.
Y entonces surge la dificultad: Los desarrolladores de WebKit soportan Touch Events mientras que IE10 soporta una versión con prefijo de Pointer Events. Traducir entre ambas suena posible, pero no resulta sencillo, considerando que no es un caso simplemente de buscar y reemplazar.
Referencias: