Los desarrolladores web por lo general nos enfrentamos a una verdadera batalla campal visto en las peores escenas de WoW con un navegador en particular: Microsoft Internet Explorer. Por lo general, esta batalla campal implica tomar decisiones, y es así como muchas empresas terminan por hacer una página web funcional exclusivamente para Internet Explorer, olvidándose de los demás navegadores muchas veces porque la gerencia ocupa Internet Explorer.
Pero el mundo es variado, y el ser humano nunca perfecto. Ya con la introducción más masiva de los netbooks y por ende mayor libertad de optar por distintos navegadores, queda bastante claro que no todo el mundo ocupa Internet Explorer, lo cual hace que ciertas partes que sólo funcionan al modo de este último, no funcione en otros exploradores. Claro, existen formas de hacerlos compatibles, pero por lo general, requieren muchas más horas de testeo y de programación en general; lo cual contraviene las posibles utilidades de la empresa: “Si nosotros ocupamos Internet Explorer, ¿por qué no lo va a utilizar el resto del mundo también?”, o menos común: “Si funciona bien en Internet Explorer, dejémoslo así no más, total, funciona”.
Pero a simple vista, ¿cuáles son en efecto las causales de que la funcionalidad de una página se pueda ver reducida o no?
Básicamente, las páginas web por lo general son una combinación de diferentes lenguajes: El caso más común, es mezclar PHP, HTML, JavaScript y CSS, aunque por lo general también se pueden incluir otros elementos como Flash y su ActionScript.
Ahora bien, durante el desarrollo de una sitio, es de suma importancia saber dónde se ejecuta cada cosa: de los mencionados, el único que no va a afectar nuestra experiencia de navegación es PHP, ya que es ésta la que se comunica con la base de datos en caso de haber una y entrega diferentes resultados en HTML.
El HTML por su lado, se interpreta en el lado del cliente: Es decir; en el mismo PC en el que estás leyendo esto. Nótese que usé la palabra “Interpreta” en vez de “Ejecuta”, ya que el navegador lo que hace es tomar ese código HTML y renderearlo de manera que veamos texto e imágenes en un cierto formato. En otras palabras: dependiendo del navegador que se está ocupando, se mostrará de una u otra forma la página.
A su vez, JavaScript y CSS (dos temas sobre los cuales hablaremos más adelante) también se ejecutan en el lado del cliente, y por lo tanto, están afectos al navegador que se esté ocupando: mientras un navegador interpreta ciertas cosas de una manera, otro navegador puede interpretarlas de otro, causando desde pequeñas diferencias hasta la imposibilidad total o parcial de poder navegar a través del sitio.
Por último, casi como agregado, es importante destacar que muchas veces se hablará del “motor” que está detrás. Estos motores no son nada más que el Layout Engine, y que es la encargada de “dibujar” una página web en pantalla, considerando entre otros tanto el HTML como el CSS. Dentro de los navegadores más populares, los motores son los siguientes:
Mozilla -> Gecko
Konqueror -> KHTML
Safari, Google Chrome -> Webkit
Internet Explorer -> Trident
Opera -> Presto
Los tres primeros son en su mayoría open-source, mientras que los dos últimos son propietarios y el dato rosa del día es que Webkit es más bien reciente: la mayor parte de su código está basado en KHTML.
Estándares W3C
Los estándares W3C son dictaminados por la World Wide Web Consortium, y tiene como base definir qué es una sentencia HTML válida para que de esta manera, los navegadores puedan desplegar la página de manera correcta.
Actualmente, la W3C regula principalmente dos aspectos:
1.- HTML: Es la principal tarea de la W3C y dentro de esta actividad, determina cuáles son las sentencias a ocupar en un futuro. Por ejemplo: en 1998, definir una tabla era tan simple como encasillar TABLE en signos mayor y menor. Se le podían dar ciertos atributos a esa tabla, tales como el borde, el color de fondo y otros, pero en la actualidad, estos mismos atributos están obsoletos; ya que fueron cambiadas en su mayor parte por el CSS.
2.- CSS: La otra tarea de la W3C es definir cuáles serán los estándares en el CSS, así por ejemplo se puede definir un solo nombre para una cosa que va a funcionar de igual manera en cualquier navegador, bajo cualquier circunstancia.
Resumiendo, si nos dedicáramos a crear un motor para un navegador X y nos apegamos a los estándares de la W3C, nos estaríamos asegurando que no vamos a tener problemas tanto en la presentación como en la funcionalidad de la página con nuestro navegador: de igual manera, si creamos un navegador tomando como base alguna solución open-source compatible, tampoco tendríamos problemas, es por eso que Chrome y Safari muestran las páginas de igual forma: ambos ocupan el motor de Safari. (Con quizás algunos leves cambios debido a pequeñas alteraciones del código por parte de alguno de los implicados)
Tomando un ejemplo; nuestro sitio es compatible con la W3C tanto en el HTML como el CSS, con lo cual nos aseguramos que aquel que lea CHW ya sea con Lynx o con Firefox lo va a ver de todas formas, como se quiso que viera. Lo único que no es compatible son las propagandas de Google: según Google, si hacen su código compatible con la W3C se ve afectada la velocidad, razón que muchos consideran suficiente como para no hacerlo compatible, aunque personalmente, encuentro un poco difícil que alguien haya hecho las correspondientes pruebas para realmente comprobar si la velocidad se ve afectada o no.
Accesibilidad
Otra medida -considerada del 2004 en adelante- es el tema de accesibilidad a la página web. Esta accesibilidad no está medida en cuanto a recursos del servidor o la conexión de cada persona, sino que está relacionada en cuanto a que las personas ya sea sordos, sordo-mudos, ciegos; como también aquellas que no cuentan con los recursos informáticos “apropiados”; puedan disfrutar de igual manera de una página web que aquellas que no enfrentan estas desventajas.
Es así como una página web accedible debe responder afirmativamente a la gran mayoría de estas preguntas:
– ¿Puede el sitio ser visitado por personas con problemas de ceguera?
– ¿Puede ser visitado por personas con problemas auditivos?
– ¿Se considera aquellas personas con problemas de comprensión, aprendizaje o que tienen dificultad para leer?
– ¿Se considera aquellos que no pueden hablar o entender el lenguaje en que está escrito el documento?
– ¿Puede ser visitado por personas que no pueden usar un mouse?
– ¿Puede acceder a mi sitio una persona que usa un navegador sin opción gráfica?
– ¿Es accesible mi sitio para personas que navegan con una conexión muy lenta?
– ¿Puede acceder al sitio una persona que usa un dispositivo con pantalla pequeña?
– ¿Pueden acceder quienes usen una versión de navegador antigua, otro sistema operativo, un browser de voz?
– ¿Se considera aquellos que están en un ambiente desfavorable? (conduciendo, en un lugar ruidoso, en una habitación con poca luz, etc.)
Para comprobar si la página es compatible o no con estos estándares, hay un verificar en línea disponible haciendo clic aquí [link=”http://www.tawdis.net/taw3/cms/es/”], la cual le permite elegir entre tres niveles. Estos tres niveles no son nada más que una lista de prioridades, las cuales se definen de la siguiente manera:
Prioridad 1. Un desarrollador de contenidos de páginas web debe satisfacer este punto de verificación.
Prioridad 2. Un desarrolador de contenidos de páginas web debería satisfacer este punto de verificación.
Prioridad 3. Un desarrollador de contenidos de páginas web puede satisfacer este punto de verificación.
Y de acuerdo a esta prioridad, se tienen diferentes niveles:
Nivel A: Se satisfacen todos los puntos de verificación de prioridad 1.
Nivel AA: Se satisfacen todos los puntos de verificación de prioridad 1 y 2.
Nivel Triple AAA: Se satisfacen todos los puntos de verificación de prioridad 1, 2 y 3.
Es un poco complicado el sistema, pero una vez que uno se acostumbra a los principales conceptos y métodos de trabajo, resulta más fácil, pero no hay que olvidar que este tipo de estandarización es bastante nuevo: Actualmente, la W3C está trabajando recién en la segunda parte de estos estándares, la cual será conocida como la WCAG 2.0; por mientras sólo hay una versión 1.0 que sin lugar a dudas, será reemplazada ampliamente por el nuevo estándar.
Por mientras, sirve para aquellos casos donde por ejemplo se visite la página en un iPhone (que no tiene soporte para flash) o para los navegadores con voz: no necesitan desplegar la parte gráfica, pero tienen que informar de qué se trata cada foto, cada tabla y cada link. Si a eso le sumamos que todo aquel ciego que intenta ver la página no es necesariamente un experto en informática como para saltarse la descripción de las imágenes, ya se podrán imaginar el resto.
Opera 10 y otros navegadores
Doy una mención especial a Opera 10 (que, como leímos en CHW, fue lanzado recientemente), ya que es el primer navegador que oficialmente logra un 100/100 en el ACID Test.
Este ACID Test no es nada más ni nada menos que una prueba para los navegadores, de manera que podamos apreciar las diferencias entre uno y otro navegador, para revisar si éstos se apegan a los estándares que dictamina la W3C o no. Por supuesto que el ACID Test es compatible al 100% con la W3C tanto en el HTML como en el CSS, y de ahí la importancia del mismo.
Curiosamente, todos los navegadores modernos (exceptuando Opera 10) no alcanzan a sacar el puntaje máximo, todos fallan en mayor o menor medida en algo pero al menos la página se ve muy parecida a lo que debería verse.
Para resumir, Firefox 3.0.4, Opera 9.X y 10, Safari y Chrome sacan puntaje mayor a 70 puntos, lo cual es relativamente bueno. Sin embargo, Internet Explorer, tanto la versión 6 como la versión 7, no logran más de 12 puntos, haciendo en gran medida que ni siquiera se alcance a notar qué es la página, es decir: funcionalidad nula. Eso quiere decir que, en el peor de los casos, si tuviéramos que hacer un sitio, apenas el 12% del código sería compatible con Internet Explorer.
Internet Explorer: ¿Webkit?
Internet Explorer es quizás el navegador más famoso que existe, aunque; tal como quedó demostrado en la página anterior; también el menos compatible.
Hace cerca de un mes atrás, el mundo geek se remeció un poco al enterrarse de que quizás Internet Explorer se iba a cambiar de motor; lo cual, en pocas palabras, significaría que por fin se ajustaría a los estándares de la W3C. Muchas peleas, ideas, fanboys y trolls surgieron, pero la noticia fue rápidamente desmentida por parte de la misma Microsoft. Sucedía que en realidad se habían malinterpretado las palabras de Ballmer y con ello, la ilusión de muchos se apagó.
Aunque no totalmente descartado, existen unas cuantas razones del por qué Internet Explorer 8 no tendrá un motor que no sea el propietario:
1- IE8 ya está en etapas finales, lo cual significa que ya estando en una etapa tan tardía, nadie (y esto no excluye a Microsoft) desecharía todo el trabajo interno y empezaría prácticamente de nuevo con otro motor, teniendo además que hacerle grandes cambios a los sistemas operativos: la integración de Internet Explorer con Windows va mucho más allá que un simple programa, a tal punto que Windows sin Internet Explorer simplemente no funciona.
2- Las palabras de Ballmer fueron malinterpretadas: Literalmente, lo dicho por Ballmer fue que las alternativas open-source las encontró “interesantes” y que “a lo mejor necesitamos un servicio de rendereo”, lo cual deja ver claramente que, como toda empresa, podrían llegar a ocupar algunas partes o sacar ideas de cierto software, pero no adaptar Internet Explorer completamente a Webkit.
Talón de aquiles N° 1: JavaScript
En primer lugar tenemos a JavaScript. Para aquellos que no están acostumbrados a programar páginas web completas, es; tal como indica su nombre; un script que permite ejecutar diferentes acciones de acuerdo a las variables que se le introduzca (Por ejemplo: Si una letra está en mayúscula, convertirla a minúscula o vice-versa, como también cosas más complicadas como verificar que un e-mail esté bien escrito o no). Resulta especialmente confrontacional debido a que, como ya fue dicho en la introducción, depende netamente de cómo la procese el navegador.
Ok, estamos de acuerdo: no existe un solo método de programar en JavaScript, pero lamentablemente hay algunas cosas que son sólo compatibles con un navegador o con otro. Es así como JavaScript (corriendo en Internet Explorer) permite diferenciar entre una versión y otra, justamente para aplicar esas pequeñas diferencias. Curiosamente, los demás navegadores simplemente ignoran estas sentencias y simplemente aplican aquella función más compatible o bien la última ingresada, lo cual produciría muchísima más carga tanto en el servidor como en el ancho de banda del servidor, ya que en vez de transferir una cosa una sola vez, va a tener que hacerlo hasta 10 veces, lo cual no ayuda mucho en reducir tráfico.
Talón de aquiles N° 2: CSS
Quizás el talón más grande de Internet Explorer ha sido el CSS: mal que mal, es la nota de presentación de una página ya que ella regula toda la parte gráfica, sólo cambiando el CSS se puede cambiar un sitio completo, sin (necesariamente) afectar el contenido.
Sólo por poner un ejemplo, hace poco gMail permitió poner skins al correo. Básicamente, lo que se hace, es preguntar por cuál skin el usuario prefiere ver la página, y de acuerdo a eso, carga uno u otro archivo CSS. Este archivo CSS controla absolutamente toda la parte gráfica de la página: El fondo, si uno desea ver ciertas cosas destacado en negrita o en cursiva (o incluso ninguna de las dos) y hasta de dónde uno desea ver los botones “Salir” u “Opciones”. El contenido de la página será exactamente el mismo: tendremos los mismos mails no importando cuál skin elijamos y en todas ellas vamos a poder revisar satisfactoriamente nuestro mail, lo único que cambia es la presentación de la página. Es realmente una herramienta muy poderosa ya que con un poco de imaginación y buen gusto podremos personalizar al 100% nuestra página o sitio completo.
Sin embargo, no todo podía ser tan bonito: un CSS que funciona en Opera, Firefox o Chrome y que cumple con los estándares no garantiza y no será compatible con Internet Explorer. Internet Explorer es incapaz de renderear de forma correcta un menú hecho en CSS y que no tiene muchas complicaciones, mientras que cualquier otro navegador lo despliega de forma correcta y sin problemas. Sin embargo, en cualquier otro navegador no hay ningún inconveniente y se ve tal cual como en la primera imagen.
Las tendencias de los navegadores
Con la entrada de Google Chrome, cambiaron muchas cosas. El equipo detrás de Firefox se empezó a preocupar más por la velocidad de JavaScript, y Opera, aunque con menor participación, ya estaba trabajando de forma secreta en lograr un puntaje 100/100 en el ACID Test. ¿A qué apunta todo esto? ¿Los distintos equipos detrás del software realmente estará trabajando en lograr mayor compatibilidad y menores problemas para los programadores?
Al parecer, la dirección realmente va hacia lograr una estandarización efectiva, sin discriminar entre los distintos motores que hay actualmente y asegurando que las páginas funcionen en cualquier ambiente. No por nada es que Linux ya tiene una participación del 30% en los netbooks, por lo que se podría llegar a decir que esto ya podría representar una cifra significativa que ya no forma una parte minoritaria que simplemente se puede ignorar: cada día se está prefiriendo más el uso de navegadores alternativos; ya sea por comodidad, por obligación o compatibilidad; y si la carrera sigue, pronto tendremos muchas empresas que al tratar de abaratar costos, instalarán Linux con lo cual ya no podrán correr nativamente Internet Explorer, con lo cual su plataforma interna (cada vez más basado en la web) deberá correr bien con esos navegadores alternativos.
Si bien es cierto esos son apenas dos de los miles de escenarios posibles, esto ya se podría vislumbrar en un futuro cercano. Sin ir más lejos, las estadísticas de CHW indican que una gran parte de los navegantes está prefiriendo exploradores alternativos, donde Mozilla Firefox se lleva el 44.25% de los visitantes, mientras que Opera el 4.91%: juntos suman el 49,16% de las visitas, lo cual ya es superior a la participación de Internet Explorer: un 48.74% de los visitantes navega con este último navegador.
Ahora bien, hay que pensar que CHW es un sitio de noticias por y para geeks, pero esta tendencia se ha visto reflejada de igual manera a nivel mundial: casi el 30% de los navegantes prefiere un explorador alternativo.
Mirando estas estadísticas, ¿será necesario respetar o no los estándares que dictamina la W3C? Como conclusión: si lanzo mi aplicación web y ésta no es compatible, hay al menos un 30% de visitantes que no podrán acceder, lo cual no deja de ser un numero importante. Juzguen ustedes mismos.
Conclusiones
Rescatando lo dicho anteriormente sobre Internet Explorer y Webkit, existe otra razón aún más fuerte para no realizar el cambio: Realizar una modificación tan drástica haría incompatible todas aquellas páginas que actualmente funcionan bien en Internet Explorer y esto no es algo que Microsoft se pueda permitir: Claro, todos los desarrolladores se lo agradecerían, pero lamentablemente hay mucho público al cual no le gustaría la idea de visitar su sitio web favorito con su flamante nuevo Internet Explorer y darse cuenta que no funciona.
Teniendo esto en cuenta, ¿creerán que Internet Explorer realmente se arriesge a cambiar su motor, por lo menos en el corto o mediano plazo?
Lamentablemente la realidad nos dice otra cosa: seguirán habiendo páginas exclusivamente compatibles con Internet Explorer, y peor aún: mientras más versiones de Internet Explorer habrán, más cambios se van a tener que realizar de manera que quede compatible con todas las versiones. Pero por lo menos una noticia buena: si tenemos un poco de suerte y nos toca un jefe que ocupa tanto Internet Explorer como Mozilla, tendremos doble pega y más importante aún: doble paga. Si tenemos suerte.
