ESTUDIO SOBRE INTERNET EXPLORER 9 Y LOS NUEVOS ESTÁNDARES WEB

Transcripción

1 ESTUDIO SOBRE INTERNET EXPLORER 9 Y LOS NUEVOS ESTÁNDARES WEB Javier Holguera Blanco Payvision 9 de Mayo de 2005

2 INTRODUCCIÓN... 4 LOS ESTÁNDARES... 9 QUÉ ES UN ESTÁNDAR... 9 ORGANISMOS ESTANDARIZADORES OTROS GRUPOS ETAPAS EN LA ESTANDARIZACIÓN RIESGOS DE LOS ESTÁNDARES INMADUROS Web Sockets Indexed DB VENDOR PREFIXES LIDERAZGO DE MICROSOFT COMPROMISO CON LOS ESTÁNDARES Same markup APIs estables HTML5 Labs HTML Tests del W3C ACID Html5Test.com Caniuse.com Tests en profundidad Codecs Etiqueta <header> Etiqueta <nav> Etiqueta <footer> Etiqueta <article> Etiqueta <aside> Etiqueta <section> LA MARCA HTML5 TESTEANDO HTML5 LA ETIQUETA <VIDEO> LA ETIQUETA <AUDIO> CANVAS NUEVAS ETIQUETAS SEMÁNTICAS Otras etiquetas CSS CSS Level 2 y Level CSS Colors Selectors CSS Level 2 Revision CSS Namespaces CSS Background and borders MÓDULOS COMPLETADOS MÓDULOS DE ALTA PRIORIDAD 2

3 CSS Multi-column Layout CSS Media Queries CSS Values and Units CSS Fonts WOFF CSS3 2D Transforms CSSOM View OTROS MÓDULOS DOM Mejoras internas Mejoras de interoperabilidad Mejoras de parseo y serialización DOM Traversal y Element Traversal DOM Range DOM Core L2 y L DOM Events L2 y L Otros estándares DOM implementados MEJORAS EN DOM SOPORTE A ESTÁNDARES OTROS ESTÁNDARES GEOLOCALIZACIÓN SVG SVG y Canvas ECMASCRIPT Cambios de comportamiento Novedades NAVIGATION TIMING La API OTRAS NOVEDADES RENDIMIENTO SITIOS ANCLADOS Anclado básico JumpLists Barra Thumbnail Notificaciones Descubrimiento Los beneficios DEVELOPER TOOLS CONCLUSIONES BIBLIOGRAFÍA

4 INTRODUCCIÓN En 1936 Francia concluyó la construcción de la línea Maginot, la mayor línea de defensa militar construida en el mundo moderno. Los franceses habían sufrido un gran número de bajas durante la I Guerra Mundial debido a la cruenta guerra de trincheras que libraron. Con base en esta experiencia pasada plantearon la creación de una línea defensiva que les ayudaría a sostener grandes frentes estáticos, en caso de producirse un nuevo conflicto con Alemania. Este conflicto llegó con la II Guerra Mundial, pero para desgracia francesa la guerra no se desarrolló del mismo modo que la anterior. Alemania utilizó las mismas nuevas tácticas bélicas que había puesto a prueba durante la Guerra Civil española y en la invasión a Polonia. El resultado: tras apenas 2 meses de conflicto, París firmaba el armisticio en Junio de La Línea Maginot se había convertido en uno de los mayores fracasos militares que se recuerdan. Los franceses habían cometido uno de los errores favoritos del ser humano: planificar el futuro pensando que el pasado se repetiría. Aun cuando a muchos les gusta decir que la historia está condenada a repetirse, son innumerables los fracasos históricos ligados en esta falsa creencia; basados en planificar el futuro tomando el pasado como único parámetro. La toma de decisiones informadas no puede basarse sólo en lo acaecido con anterioridad. El proceso de revisión de la información disponible y la obtención de nuevos datos son imprescindibles si se quiere minimizar los errores en este proceso de decisión. La industria de la Informática no es ajena a estos parámetros. Muy al contrario, la velocidad a la que avanza esta disciplina intensifica la necesidad de renovar permanentemente la información disponible antes de tomar una decisión. En Informática un principio comúnmente aceptado puede tornarse, en pocos años, en práctica abandonada. Al final, después de años inmersos en este proceso revisionista, los profesionales del sector hemos terminado por asumir que sólo un permanente esfuerzo por adquirir los últimos conocimientos nos puede ayudar a minimizar errores en la toma de decisiones. En HTML podemos encontrar uno de estos principios que parecían inmutables. No en vano la última revisión del popular lenguaje de marcado data de Más de una década después, todo un mundo cuando se trata de esta industria, una nueva versión de este estándar empieza a asomarse con inusitada fuerza en las vidas de los desarrolladores web. Con ella, bajo la denominación de HTML5, nuevas versiones de los demás estándares sobre los que se asienta la Web: CSS, DOM, etc. Esta pequeña revolución en el dominio de los estándares web a la que estamos asistiendo en estos días promete sacudir los cimientos de la Web tal como la concebimos hoy en día. HTML5 no es sólo un conjunto de nuevas versiones de los estándares de siempre, es un paso más allá en la programación web, buscando dotar a los sitios web de capacidades que, hasta ahora, sólo estaban disponibles en forma de plugins o en aplicaciones de escritorio. Microsoft ha decidido sumarse a esta revolución desde dos frentes: liderando el desarrollo de estos estándares y facilitando su implantación ofreciendo una nueva versión de Internet Explorer con un excelente soporte a los mismos. A lo largo de este documento se ofrecerá información y datos que soporten ambas afirmaciones. El primer capítulo gira en torno al concepto de estándar. Gracias a los estándares los desarrolladores pueden crear aplicaciones que funcionan en distintos navegadores, así como asumir una base sólida sobre la que construir dichas aplicaciones. En este primer capítulo entraremos también en detalles 4

5 sobre el W3C, el organismo responsable de los estándares web, como HTML, DOM, CSS o SVG. Explicaremos también porqué el W3C logra con éxito establecer estándares donde otros grupos, como WHATWG, no han conseguido obtener el respaldo unánime de la industria a sus propuestas. Describiremos también las distintas etapas de madurez por las que pasa un estándar W3C y el porqué de que, hasta su pronunciamiento como Candidate Recommendation, los desarrolladores deban tener cuidado al hacer uso de él por ser susceptible de sufrir cambios importantes. El liderazgo de Microsoft en el desarrollo de estándares es un principio de la compañía que se extiende varios años atrás en el tiempo. Si en el pasado reciente ayudaron a la estandarización de CSS 2.1 aportando más de 7000 tests a la suite de esta especificación, en la actualidad su radio de acción se extiende a casi todos los grupos de trabajo de los distintos estándares que se están evolucionando en estos momentos. Por ejemplo, en HTML5, además de distintos profesionales, aportan un co-chair en la persona de Paul Cotton, especialista con más de 10 años de experiencia. También lideran el grupo de trabajo de testeo de HTML5, desde el convencimiento de que sólo una extensa batería de tests puede asegurar la completa interoperabilidad de todas las implementaciones de HTML5 entre sí. El compromiso de Microsoft no sólo se refleja en su trabajo en el W3C. Internet Explorer 9 también se beneficia de esta filosofía, hasta convertirse en líder en el soporte a HTML5 de acuerdo a los tests del W3C. Por otra parte, a través de la iniciativa HTML5Labs, Microsoft reconcilia dos intereses inicialmente contrapuestos: la estabilidad obligatoria en un producto sobre el que los desarrolladores web van a crear sus aplicaciones, frente a la necesidad de implementar las últimas características de estándares inmaduros para facilitar su evolución. El segundo capítulo de este documento se centra en la quinta revisión del estándar HTML. Es importante hacer esta distinción con respecto a la etiqueta HTML5, que para la mayoría de medios reúne las nuevas versiones de otros estándares. Esta nueva revisión de HTML enfrenta un problema de desinformación con respecto a su testeo. Muchas páginas afirman evaluar el soporte que un navegador ofrece a esta nueva versión del popular estándar. Sin embargo, en este documento se pueden leer numerosos datos que demuestran la escasa exhaustividad de estos sitios, lo que invalida las conclusiones que arrojan. Frente a estos resultados de poco valor tenemos la información que el W3C ofrece al respecto, mediante la suite oficial de tests de la quinta revisión de HTML. Sin duda, un recurso de incuestionable mayor utilidad a la hora de medir dicho soporte al estándar. Este segundo capítulo prosigue entrando en un nivel más técnico describiendo algunas de las novedades que presenta HTML5 y que han sido implementadas en IE9. Las nuevas etiquetas semánticas o las etiquetas <canvas>, <audio> y <video> son algunas de ellas. Con respecto a <video>, se dedican unas páginas a arrojar luz a la polémica en torno a los códec de vídeo. La posición agnóstica que la especificación ha tomado al respecto ha permitido a cada fabricante elegir los códec que desea soportar. IE9 soporta el códec H.264, el estándar referente en la industria de contenidos audiovisuales; así mismo, se ofrece compatibilidad con WebM, con objeto de incrementar el poder de elección de desarrolladores y usuarios. Si la quinta revisión de HTML5 viene con importantes cambios, CSS3 no desmerece en dicho aspecto. Son muchos los módulos en los que trabaja el equipo de trabajo de CSS. Prácticamente todos aquellos que han alcanzado el estado de Candidate Recommendation están incluidos en IE9, por lo que los desarrolladores web ya pueden utilizar la nueva API de selectores, hacer uso de las nuevas funciones de definición de colores, organizar sus hojas de estilo con nombres de espacios o trabajar con media queries. Mención aparte merece la implementación del módulo de Backgrounds and Borders, que 5

6 facilita una gran flexibilidad a la hora de definir bordes redondeados y otros artificios visuales, muy reclamados por los diseñadores. De manera experimental IE9 también incluye algunos módulos que todavía no han alcanzado el grado de madurez de Candidate Recommendation. Estos módulos, por lo general, tienen un consenso entre todos los fabricantes de navegadores, de ahí su inclusión. En otros casos, la inmadurez se ha etiquetado utilizando el prefijo de vendedor de Microsoft. De este modo, siguiendo las directrices de uso de prefijos de vendedor del W3C, se cataloga la implementación como inestable, ayudando a que el desarrollador tome decisiones informadas respecto a su uso. Un ejemplo de este uso del prefijo de vendedor lo tenemos en la implementación del módulo de Transformaciones 2D. El tercer capítulo está dedicado a todas estas novedades en el soporte a CSS3. El extenso soporte a los estándares de la web que Internet Explorer 9 ofrece nace de un principio que Microsoft ha establecido durante el desarrollo del navegador y que se resume en dos palabras: same markup. Este concepto encierra un objetivo ambicioso: asegurar que todos los navegadores ejecutan del mismo modo el mismo código. En resumen, se busca que las aplicaciones web se comporten exactamente igual en todos los navegadores. Para lograrlo, implementar los más modernos estándares web no ha sido suficiente para el equipo de IE. En aras de alcanzar la mayor interoperabilidad posible con los demás navegadores, se han introducido cambios en Internet Explorer, con el objetivo de adecuar su comportamiento con el de otros navegadores, allí donde la inexistencia de un estándar (o las posibles múltiples interpretaciones de su texto) habían creado un vacío legal. En el capítulo cuarto, dedicado a DOM, se listan la mayoría de estos cambios. Sin embargo, estas mejoras y modificaciones que buscan ayudar al desarrollador a crear un solo código Javascript para todos los navegadores, no serán efectivas si no se recurren a buenas prácticas de programación. En concreto, es responsabilidad de todos ir desterrando la detección de navegadores, sustituyéndola por una simple detección de característica, evidentemente más sostenible en el largo plazo. De lo contrario nos encontraremos teniendo que reescribir código con cada nueva versión de los distintos navegadores. La implementación de DOM en IE9 no sólo ha sufrido cambios para adecuar su comportamiento al de los demás navegadores. También se beneficia de la introducción de novedades en la gestión y recorrido del árbol DOM, mejoras en la gestión de eventos, etc. Significativa es la implementación del método addeventlistener, muy reclamado por la comunidad de desarrollo web y que ya tiene su implementación en Internet Explorer, siempre con el objetivo de lograr un único código de marcado. El W3C publicaba recientemente una nota en la que indicaba que, actualmente, estaba trabajando en más de 100 estándares simultáneamente, todos ellos relacionados con el término marketiniano de HTML5. Aun cuando serían necesarias varias decenas de documentos como éste para cubrir semejante conjunto de funcionalidades, el capítulo quinto hace un breve repaso a algunos de ellos, puesto que no todo es HTML, CSS y DOM en la Web. El nuevo estándar de Geolocalización ha sido completamente implementado en IE9, lo que permitirá a los desarrolladores personalizar la experiencia de sus sitios en función de parámetros geográficos. SVG también se asoma por primera vez en Internet Explorer, con un completo soporte a la versión 1.1 de este estándar de gráficos vectoriales. En este capítulo podremos hacer un breve repaso al modo de crear formas, gradientes, patrones, texto, colores, etc., en SVG con Internet Explorer 9. También Javascript tiene un hueco para novedades en IE9, con la implementación de nuevas características 6

7 definidas en su estándar ECMAScript5. Por último, de un vistazo, veremos cómo se puede sacar partido a la nueva API Navigation Timing, que facilitará a los desarrolladores información sobre tiempos de carga de las páginas web, de forma nativa. Con esta API se terminarán los trucos a los que, hasta ahora, había que recurrir para recopilar este tipo de información. El objetivo de un único marcado no es el único que ha guiado el desarrollo de Internet Explorer 9. Los otros dos han sido hacer un navegador de una rapidez sorprendente, y evitar que recibiera demasiada atención del usuario. La rapidez se ha conseguido gracias a una profunda reorganización de la arquitectura de IE. Desde sus primeras versiones de desarrollo, Microsoft se situó a la cabeza del rendimiento gracias, entre otras mejoras, al uso intensivo de la aceleración gráfica por hardware. Si el avanzado soporte a la aceleración por hardware ha marcado la senda que los demás fabricantes han seguido con mayor o menor fortuna, no menos relevante es el magnífico rendimiento que el nuevo motor de Javascript está dando. Chakra se ha convertido en el más rápido de todos, de acuerdo con el famoso benchmark SunSpider, creado por el equipo de WebKit. Sin embargo, estas dramáticas mejoras en el rendimiento del navegador se hacen más patentes al unir los 11 subsistemas de que se compone un navegador moderno. Las mejoras que casi todos estos subsistemas han recibido son las que aúpan a IE9 al pódium de los ganadores cuando se dejan de un lado las pruebas sintéticas y se centra la lucha en la web real. Así lo reconocía recientemente el equipo de Facebook, refiriéndose al rendimiento de IE9 en los juegos comparado con los demás navegadores. El sexto capítulo de este documento trata sobre estas mejoras de rendimiento, pero también se detiene a describir cómo IE9 consigue pasar a un segundo plano y centrar toda la atención del usuario en el sitio web. La tecnología de Sitios Anclados, novedad exclusiva de Internet Explorer 9, facilita instalar los sitios web como si fueran aplicaciones de escritorio. El navegador adapta su aspecto a la apariencia del sitio web, de forma que el usuario vive la sensación de estar ejecutando su sitio web favorito, en lugar de simplemente navegándolo. Los sitios web que ya utilizan esta tecnología están reportando fantásticos aumentos en el número de visitas y en participación de los usuarios que anclan sus sitios a la barra de tareas. Puesto que esta característica es una gran ayuda al desarrollador, en el capítulo sexto se analiza en profundidad, con numerosos ejemplos de código. Como vemos, si bien en el actual escenario todos los navegadores tienden a confluir en la interpretación del código de las páginas web, sigue habiendo espacio para la innovación y la diferenciación con respecto a otros navegadores. Con los Sitios Anclados IE9 presenta una novedad que, a día de hoy, no ha tenido respuesta en otros fabricantes y que ya está demostrando sobre el terreno ser de enorme utilidad a aquellos que han decidido utilizarla. El paquete de beneficios para los desarrolladores se completa con unas renovadas Developer Tools, que cuentan con una nueva pestaña específicamente diseñada para recopilar información de tráfico de red. De este modo el desarrollador ya no tendrá que recurrir a herramientas de terceros y realizar costosos cambios de contexto; en adelante, toda la información que necesite para afinar su sitio web la tendrá al alcance de un click, el del botón F12. Empezábamos esta introducción rememorando un suceso histórico. La Línea Maginot sucumbió por las novedades tácticas de guerra alemanas, demostrando el error de planificar el futuro tomando como única referencia el pasado. En la industria de la Informática nos encontramos en un punto de inflexión igual de relevante, con el advenimiento de todos los estándares nacidos bajo el paraguas de HTML5. 7

8 De cada uno de nosotros, desarrolladores, depende etiquetar a Internet Explorer 9 por la opinión que nos merecieron sus predecesores, o ejercer nuestra responsabilidad profesional y analizarlo como lo que es: el primer navegador de la web del futuro. 8

9 LOS ESTÁNDARES En esta sección vamos a hacer un repaso profundo de los estándares. Qué son, qué ventajas nos aportan, qué organismos de estandarización existen, qué etapas sufre un estándar hasta convertirse en uno, qué riesgos se corren al trabajar con los estándares en función del nivel de madurez en que se encuentren, etc. También dedicaremos un apartado a conocer en profundidad qué relación tiene Microsoft con los estándares web, que son el motivo de este documento. QUÉ ES UN ESTÁNDAR Cuando pensamos en un estándar se nos viene a la cabeza algo similar a lo que la RAE define como segunda acepción de esta palabra: tipo, modelo, patrón o nivel. Partiendo de esta definición podemos pensar que existen muchos cuerpos de conocimiento susceptibles de ser estandarizados: música, matemáticas, lingüística, industria, etc. En nuestra disciplina el término estándar suele hace referencia a estándares técnicos, aquellos que, normalmente, se definen con un documento formal que establece prácticas uniformes en la ingeniería. Existen dos tipos de estándares: de facto y de iure. Los primeros suele establecerlos una compañía o producto que debido a su uso masivo en un campo se convierten en referencia en el mismo, aceptados por el resto de miembros del mercado. Los segundos son coordinados por un organismo de estandarización y aseguran un proceso de revisión y consenso entre las partes interesadas, antes de su publicación. Es, precisamente, este proceso de revisión y consenso el que los hace más beneficiosos que los estándares de facto, que normalmente responden a los intereses de una única parte. Existen muchos ejemplos de ambos tipos de estándares, e incluso algunos de estándares que han pasado por ambas fases. Por ejemplo, PDF nació en 1993 y su popularidad lo convirtió en el estándar de facto de documentos imprimibles. Sin embargo, no sería hasta 2005 que se convertiría en un estándar de iure, con la publicación de PDF/A en ISO, uno de los organismos estandarizadores más importantes. Para los desarrolladores los estándares juegan un papel vital. Ofrecen una base sólida sobre la que crear aplicaciones. Los estándares garantizan estabilidad en dos sentidos: en forma de una interfaz contra la que poder programar, y en forma de un comportamiento bien conocido de las características definidas en dicha interfaz. Ambos dos deben ser respetados por todos aquellos fabricantes que afirmen ser compatibles con dichos estándares en sus productos. La situación contraria, la ausencia de un estándar, abre la puerta a modificaciones en la interfaz y el comportamiento, sin garantizar la compatibilidad con versiones anteriores. El desarrollador, en tal caso, debe trabajar con la permanente amenaza que supone que la base sobre la que asienta su aplicación puede sufrir un vuelco, simplemente por la conveniencia del fabricante que controla dicho estándar de facto. En resumen, sólo cuando se construyen aplicaciones sobre la base bien conocida y confiable que provee un estándar emitido por un organismo estandarizador, puede el desarrollador asumir como inmutable dicha base. Esta ventaja es más que suficiente para exigir a todas los integrantes en un mercado la 9

10 puesta en común de sus intereses en forma de estándares, cuyos principales beneficiarios serán los desarrolladores de software. ORGANISMOS ESTANDARIZADORES Un organismo estandarizador es una organización que se dedica a la publicación y mantenimiento de estándares. En función del alcance que tengan los estándares emitidos, se dividen en organismos regionales, nacionales o internacionales. Entre los organismos internacionales podemos encontrar a ISO (International Organization for Standarization), probablemente el más conocido y encargado de la promulgación de estándares relacionados con la industria y el comercio. También son organismos de estas características IETF (Internet Engineering Task Force), publicador de estándares relacionados con Internet como SMTP; y ECMA (European Computer Manufacturers Association), responsable de la publicación de ECMAScript, el estándar de Javascript. En cualquier caso, sin género de duda, el organismo estandarizador internacional de más relevancia en el campo del desarrollo web es el W3C (World Wide Web Consortium), por ser el organismo responsable de los estándares web. Fue fundado en 1994 por Tim Berners-Lee, considerado como el padre de la web, y cuenta con más de 300 miembros. El W3C es responsable de la estandarización de una gran mayoría de las tecnologías que soportan la web como la conocemos, entre las que se incluye HTML, CSS, DOM, SVG, SOAP, XML, etc. En el caso de HTML, el W3C ha sido el responsable del mantenimiento y evolución del mismo desde Desde entonces ha auspiciado la publicación de las versiones 3.2, 4.0 y 4.1 de HTML. Así mismo, actualmente se encuentra trabajando en la quinta revisión de este estándar. El W3C está administrado por tres instituciones: el MIT en Estados Unidos, el ERCIM en Europa y la Universidad Keio en Japón. Internamente el trabajo de evolución y mantenimiento de los estándares se reparte entre los Working Groups, grupos de trabajo específicamente orientados a una tecnología concreta. Tomemos, por ejemplo, el grupo de trabajo de HTML como referencia (1). Existen 3 chairs dentro del grupo, personas encargadas de la coordinación del mismo, así como un número relativamente grande de participantes (actualmente más de 400). En este grupo se está trabajando actualmente no sólo en la quinta revisión del lenguaje de marcado, sino en otros futuros estándares como HTML Microdata, HTML-RDFa o HTML Canvas 2D Context (del que hablaremos más adelante). Para cada estándar pueden existir uno o más editores, que son los encargados de plasmar en la especificación las decisiones o acuerdos que los miembros del grupo de trabajo toman con respecto a la tecnología estandarizada. Los estándares emitidos por el W3C sufren un profundo proceso de revisión y consenso por parte de los miembros. Este proceso es el único que puede garantizar que, una vez aprobado el estándar, todas las partes lo implementarán tal como se acordó durante la redacción, puesto que la ausencia de consenso durante su elaboración prácticamente garantizaría diferencias en las implementaciones futuras, desvirtuando totalmente el objetivo del mismo: asegurar una compatibilidad entre fabricantes de la que se beneficien los desarrolladores. 10

11 OTROS GRUPOS Aunque el desarrollo de los estándares que son pilares de la web se lleva a cabo en el W3C, eso no significa que otras entidades privadas no puedan proponer alternativas o nuevas versiones de las mismas. Existen varias de estas entidades trabajando en los estándares web, como son WHATWG o Khronos Group. WHATWG (Web Hypertext Application Technology Working Group) es un organismo que ha adquirido una gran notoriedad recientemente por estar trabajando también en la quinta versión de HTML. De hecho, para ser precisos, empezaron a trabajar en HTML5 varios años antes de que lo hiciera el W3C. Cómo es posible, si HTML es un estándar del W3C? Hagamos un poco de memoria para entender qué ha pasado. En 2004 el W3C llevaba varios años trabajando para sacar la revisión 2.0 del estándar XHTML. Sin embargo, este esfuerzo no estaba dando los frutos deseados y algunos actores relevantes de la Web decidieron formar un nuevo grupo de trabajo, independiente del W3C, para generar una revisión del HTML, que llevaba ya 5 años estancado en su versión Al WHATWG se unieron desde un primer momento miembros de Apple, la Fundación Mozilla y Opera, aparentemente preocupados por la deriva que el W3C había tomado con respecto al desarrollo de los estándares de la Web. No sería hasta 3 años después que el W3C decidiría adoptar la especificación que, hasta ese momento, había producido el WHATWG. Sin embargo, una vez que el W3C decidió liderar el desarrollo de HTML5 el WHATWG, contrariamente a la opinión de algunos evangelistas de los estándares abiertos (2), decidió continuar en paralelo la creación de HTML5. Esto ha provocado confusión, dado que ambas especificaciones no son iguales, entre otras cosas porque el WHATWG decidió suprimir el uso de versionado del documento y producirlo de forma constante y fluida. Por tanto, aun cuando el WHATWG ya trabajaba con HTML5 varios años antes de que el W3C lo hiciera, los desarrolladores no hemos podido notar cambios visibles hasta que esta organización internacional se ha involucrado en su estandarización. El porqué del aparente empuje que el W3C es capaz de dotar a la creación de estándares, empuje del que el WHATWG carece, se basa en dos puntos. En primer lugar, el W3C cuenta con miembros de todos los actores importantes de la industria, además de ser un organismo independiente a todos ellos. Como se podía leer en un punto anterior, existen más de 300 miembros en el W3C y más de 400 participantes en el grupo de trabajo de HTML. En contraposición con esta heterogeneidad de opiniones, WHATWG se compone actualmente de 9 miembros (3). Es, precisamente, de la variedad de participantes en los procesos de estandarización del W3C, de donde emana el reconocimiento a nivel institucional, en lo que respecta a estándares web, que tiene este organismo, incomparable con cualquier otro grupo. Y es este reconocimiento, también, el que favorece que los estándares publicados tenga un grado de implantación muy superior al de cualquier otra organización. ETAPAS EN LA ESTANDARIZACIÓN Cada organismo de estandarización tiene su propia hoja de ruta a la hora de desarrollar los estándares que le ocupan. En el caso de los desarrolladores web es importante conocer cuáles son las etapas por las que pasa un estándar W3C, al ser el publicador de las especificaciones sobre las que se soporta la web. 11

12 El ciclo habitual de aprobación de un estándar en el W3C comprende los siguientes niveles de madurez: - Working Draft: los borradores de trabajo son una sucesión de versiones del estándar que van recogiendo las características del mismo, así como las modificaciones fruto del feedback obtenido de la comunidad tras cada versión; por tanto, en cada nueva publicación se acercan cada vez más a una versión completa. Existen varias etapas dentro de este nivel, desde la publicación del primer borrador hasta la emisión de sucesivos borradores Last Call, una vez que se ha cerrado el conjunto de características que se quiere incluir en el estándar. - Candidate Recommendation: cuando W3C considera el documento maduro, se pasa a este nivel para ganar experiencia de implementación del mismo. - Proposed Recommendation: tras comprobarse que la especificación se puede implementar (con al menos dos versiones independientes e interoperables) y maduro, se alcanza este nivel. - W3C Recommendation: publicación del estándar como tal. Por ejemplo, HTML5 se encuentra en el estado de Working Draft. Recientemente el W3C ha actualizado su hoja de ruta con respecto a éste y otros estándares, indicando que espera tener lista una versión Last Call de HTML5 para Mayo de 2011 (4). Este hito es muy relevante, puesto que una vez superado el estado de Last Call, no se espera que se introduzcan nuevas características en el estándar; sin embargo, eso no significa que no se puedan producir cambios significativos consecuencia de la implementación del mismo. También según el W3C, HTML5 será Candidate Recommendation en 2014, una vez que se haya terminado de desarrollar su suite de tests (imprescindible para alcanzar este nivel y, especialmente, para determinar la validez de las implementaciones de la especificación) y haya al menos dos implementaciones interoperables entre sí. En cualquier caso, esto no significa que no se pueda trabajar con HTML5 hasta estas fechas, puesto que algunas partes del estándar son lo suficientemente maduras y han obtenido un grado de consenso, entre los fabricantes de navegadores, lo suficientemente alto como para poder empezar a construir aplicaciones web sobre ellas. RIESGOS DE LOS ESTÁNDARES INMADUROS Los estándares, en sí mismos, no representan ningún riesgo para el desarrollador. Lo que sí representan es un riesgo cuando aún no se han convertido en estándares; es decir, cuando son meras especificaciones en proceso de estandarización. En este punto, dependiendo del grado de madurez en el que se encuentren, puede esperarse desde meras correcciones fruto del feedback de la comunidad o de la experiencia de su implementación, hasta abandonos definitivos. Como se indicaba en un punto anterior, el principal beneficio que un estándar aporta a los desarrolladores es la estabilidad en su lista de características y comportamientos. Sin embargo, una especificación emergente que aún está lejos de alcanzar el grado de madurez que la acredite como estándar, se comporta de forma contraria. Es mucho más probable encontrarse con cambios que rompen la compatibilidad hacia atrás, modificaciones sustanciales en su diseño o diferencias en el comportamiento entre versiones. El proceso de estandarización es tan iterativo e incremental como lo puede ser el proceso de desarrollo de software; y es precisamente gracias al 12

13 feedback que se recibe al final de cada iteración que la especificación madura hasta satisfacer a todas las partes en su formulación y convertirse en estándar. Hasta entonces, la especificación como base para desarrollo de aplicaciones no será firme y sólida como cabría esperar. En algunos casos estos cambios pueden llegar a ser traumáticos, como por ejemplo con los recientes sucesos en torno a Web Sockets e IndexedDB. Conozcamos un poco la historia de cada uno de ellos para entender mejor hasta qué punto es importante tomar decisiones informadas al trabajar con especificaciones que aún no han terminado su proceso de estandarización. WEB SOCKETS Web Sockets es una nueva tecnología que pretende, en palabras del W3C, permitir a las aplicaciones web mantener una comunicación bidireccional con procesos en el lado del servidor. Esta nueva API funcionará sobre el nuevo protocolo Web Socket, también en proceso de estandarización pero aparte de la API. Sin duda, un concepto interesante y de gran utilidad para el futuro de la web. La primera especificación de esta tecnología, su primer borrador de trabajo público, data de Abril de En Diciembre de ese mismo año Chrome se convertía en el primer navegador en implementar esta tecnología (5). La especificación, por supuesto, seguía en estado Working Draft, aunque no se hiciera ninguna referencia a ello en el post en el que la gente de Chrome anunciaba su disponibilidad y su activación por defecto. Una frase indicando que el protocolo aún no había sido cerrado y se sigue discutiendo en IETF era la única referencia a un posible peligro al hacer uso de él, dada su inmadurez. Ni una palabra sobre el nivel de madurez de la API en sí. El proceso de estandarización de Web Sockets continuó, así como el número de navegadores que ofrecían soporte. En Abril de 2010 la gente de Firefox anunciaba su intención de incluirlo en la siguiente versión (6). Sin embargo, en una postura más responsable, avisaba a los desarrolladores de que el estándar estaba en proceso de revisión e incluso apuntaba que la versión incluida Chrome era incompatible con la última versión de la especificación, que había modificado el handshake. En Junio de 2010 Chrome anunciaba la actualización de su implementación (7). En el post aclaraban que la nueva versión era totalmente incompatible con la anterior debido a cambios en el protocolo Web Socket, por lo que se hacía necesario no sólo actualizar el navegador, sino también el servidor. El post terminaba con una frase controvertida: continuaremos actualizando nuestra implementación para seguir el último borrador de la especificación, en lugar de preocuparnos por los cambios incompatibles. En Octubre de 2010 Opera añadió soporte a Web Sockets (8). En el post se aclaraba que la API de Web Sockets podía considerarse estable, no así el protocolo. Resulta curioso que el post terminara con una frase premonitoria: será interesante ver si alguna vez nos deshacemos de -76, en referencia a la versión del protocolo en uso en ese momento. En Noviembre Safari en ios 4.2 añadía soporte también. Justo a tiempo, se podría decir, porque 3 días después saltaba la noticia: el protocolo Web Socket era inseguro por diseño (9). Opera y Firefox reaccionaron con rapidez, anunciando una semana después que retiraban su soporte (10). Ni Chrome ni Safari han retirado su soporte a un protocolo que ya se ha demostrado públicamente inseguro, con el peligro que conlleva para usuarios y sitios web. Las críticas, por supuesto, han sido inevitables (11). Aunque algunos de estos navegadores incluyen mecanismos de auto-actualizado y, por tanto, tan pronto liberen una versión sin la implementación de Web Sockets la ventana de ataque se habrá 13

14 cerrado, no es suficiente. Todos aquellos desarrolladores que decidieron implementar sus sitios haciendo uso de estas nuevas características que, en el caso del equipo de Chrome, no se advirtió de una forma suficientemente firme que eran inestables, han visto cómo su trabajo deja de funcionar de un día para otro. Tampoco parece razonable pretender que los administradores de servidores actualicen sus servidores al mismo ritmo que se va madurando el estándar del protocolo. INDEXED DB La historia de IndexedDB empieza, en realidad, en otra especificación: Web SQL. En Abril de 2009 apareció el primer borrador público de lo que, en aquel momento, se llamaba Web Storage. Esta especificación pretendía definir dos APIs para el almacenamiento de información persistente en los clientes web: una para su acceso basado en pares clave-valor y otra para acceso a información estructurada. En Septiembre de 2009 una nueva versión renombró el estándar a Web Database. La especificación, ahora, pretendía definir una API para almacenar información en bases de datos que pudieran consultarse con una variante de SQL. A finales de Diciembre la nueva versión de la especificación entraba en dificultades: un mensaje en rojo al principio de la misma avisaba de su estancamiento. La razón: ser prácticamente una mera referencia a la API de SQLite, el popular motor de bases de datos. Casi un año después, en Noviembre de 2010, la especificación era abandonada definitivamente (12). Qué paso durante este período de poco más de un año, desde su primer borrador hasta su abandono definitivo? En Enero de 2010 Chrome anunciaba soporte a Web SQL en su canal estable (13). A pesar de ser no sólo un borrador de trabajo, sino uno que ya había anunciado tener problemas, Google introducía soporte en su navegador a Web SQL en su rama estable y sin hacer ninguna advertencia sobre el posible peligro de construir aplicaciones sobre él. En Marzo era la gente de Opera la encargada de dar soporte a Web SQL en la versión (en concreto, en la versión 2.7 de su motor de renderizado, Presto) (14). Sin embargo, el apoyo al estándar estaba lejos de ser mayoritario, puesto que ni la gente de Microsoft (15) ni la de Mozilla (16) parecían decididos a optar por Web SQL. En su lugar, habían mostrado sus preferencias por otra especificación que apenas 3 meses antes había publicado su primer borrador: Indexed DB. Esta especificación contaba con una diferencia fundamental con respecto Web SQL: establecer una API lo más sencilla posible, no orientada a SQL para hacer uso de ella. El primer borrador de Indexed DB, cuando aún se denominaba WebSimpleDB, data de Septiembre de Aunque en Noviembre de 2010 el W3C anunciaba el abandono definitivo de Web SQL, la primera implementación de Indexed DB no surgiría hasta Diciembre, de la mano de Microsoft y como parte de su iniciativa HTML5 Labs. Unas semanas después serían Firefox y Chrome quienes publicarían sus propias implementaciones. Web SQL, por tanto, se ha quedado en el camino. No es ni será nunca un estándar. Sin embargo, algunos fabricantes parece que se resisten a aceptar esta nueva realidad. Es el caso de la gente de Chrome, que sigue mostrándolo en su lista de características (17), a pesar de que la última actualización de dicha lista es muy posterior a la anulación del proceso de estandarización de Web SQL. Por si esto fuera poco, sus desarrolladores no ofrecen respuestas claras y directas cuando se les pregunta sobre el futuro de esta tecnología obsoleta antes de nacer. Por ejemplo, en Marzo de este año uno de los desarrolladores de 14

15 Google contestaba en el Group dedicado a Chromium, preguntado sobre el futuro de Web SQL en Chrome, que WebSQLDatabase será soportado durante un tiempo, pero 1 ó 2 años es mucho tiempo y no creo que nadie pueda darte garantías sobre Chrome para entonces (18). Esta respuesta no, desde luego, muestran un compromiso para con la estabilidad de las APIs que ofrece el navegador. Más allá de la inconveniencia de que cualquier desarrollador escriba una sola línea de código sobre una tecnología que ha sido descartada, más allá de la ilógica de no informar de dicha situación a quién pregunta al respecto de forma clara, resulta incorrecto que un fabricante desarrolle un producto que debe ser base para los productos de terceros con un período de vigencia tan escaso. Sólo soportando estándares firmes y consensuados se puede asegurar que la funcionalidad que el navegador provee perdurará más allá de 1 ó 2 años. Ni Web SQL ni Web Sockets lo eran, pero no serán sus fabricantes los que paguen las consecuencias de la decisión de incluirlos; serán todos aquellos desarrolladores web cuyos deseos por probar estas nuevas tecnologías eran mayores que su conocimiento sobre la inestabilidad de dichas especificaciones. Es, sin embargo, responsabilidad de los fabricantes de los navegadores impedir que episodios como estos vuelvan a suceder. VENDOR PREFIXES Los vendor prefixes hacen referencia a prefijos que colocan los fabricantes de navegadores delante de ciertas propiedades. Estos prefijos han sido acusados, probablemente fruto del desconocimiento, como mecanismos para fragmentar la web y obligar a los desarrolladores a realizar modificaciones específicas para cada navegador. Esta interpretación es totalmente errónea, puesto que los prefijos pretenden justo lo contrario: proteger el marcado común aislando aquellos elementos que no son considerados estándar. El W3C recomienda su uso tanto para extensiones propietarias de un navegador como para características que aún se encuentran en una fase experimental (19). Microsoft ha utilizado estos prefijos durante el desarrollo de IE de acuerdo a las reglas establecidas por el organismo estandarizador. Uno de los ejemplos más claros lo tenemos en la implementación de las Transformaciones 2D de CSS. Este módulo CSS se encuentra todavía en estado Working Draft, por lo que correctamente está marcado con el prefijo de Microsoft (-ms), para evitar que los desarrolladores ignoren la inmadurez de la especificación subyacente, susceptible de amplios cambios. Otra de las implementaciones en Internet Explorer 9 que se ha apoyado en los prefijos para balancear una implementación temprana con una alta probabilidad de cambio, es la de la API de Navigation Timing, que permite medir el rendimiento de una página web y de la que hablaremos más en profundidad en próximas secciones. Ahora que esta especificación ha pasado, recientemente, al estado de Candidate Recommendation, Microsoft ha eliminado los prefijos de vendedor en IE9, para facilitar el objetivo de un solo código de marcado para todos los navegadores. Para terminar, esta práctica ha sido utilizada por otros fabricantes de navegadores. En el caso de los CSS3 Gradients, parte del módulo CSS3 Image Values, tanto los desarrolladores de Mozilla como los de WebKit han decidido utilizar sus prefijos, -moz y webkit respectivamente, apuntando de este modo la inmadurez que esta sección del módulo sufre en estos momentos (20). 15

16 LIDERAZGO DE MICROSOFT El liderazgo de Microsoft en el desarrollo de estándares se remonta a muchos años antes del advenimiento de HTML5. Sin ir más lejos, durante la estandarización de CSS 2.1, Microsoft envió más de 7000 tests al W3C para que formaran parte de la test suite de este estándar (21). También durante el desarrollo en sí de IE8 se demostró esta implicación, tanto en el nivel de soporte a CSS 2.1, como en la introducción de elementos que ya entonces formaban parte de los primeros borradores de HTML5, como son las tecnologías DOM Store, Cross Document Messaging, Cross Domain Messaging y Ajax Navigation (22). Otro ejemplo de la involucración de Microsoft con el desarrollo de estándares y, en concreto con HTML5, lo tenemos en la figura de Paul Cotton, empleado de la compañía con más 10 años de experiencia trabajando en la creación de estándares en W3C. Cotton se convirtió en 2009 en co-chair del grupo de trabajo de HTML. Microsoft también lidera el grupo de trabajo de Testing de HTML5 y el de Rendimiento Web, y participa en muchos otros, incluidos algunos de tecnologías tan relevantes como SVG o CSS. Por último, Microsoft ha enviado casi 6000 tests (23) a los distintos grupos de trabajo del W3C y ECMA (organismo encargado de la estandarización de Javascript) durante el desarrollo de IE9, con la intención de contribuir a una suite de tests que permita determinar unívocamente cuál es el comportamiento correcto a la hora de implementar una característica de un estándar. Como ya se comentó en una sección previa, no es posible avanzar un estándar hasta el nivel de Candidate Recommendation hasta que no exista una suite de tests extensa que ayude, entre otras cosas, a resolver cualquier ambigüedad del texto de la especificación. COMPROMISO CON LOS ESTÁNDARES De poco sirve liderar el desarrollo de estándares, si luego no se refleja en un compromiso con los mismos en forma de productos que respeten los acuerdos de características y comportamientos recogidos en ellos. Sin embargo, Microsoft no ha caído en este error con Internet Explorer 9. La última versión de IE no es sólo un producto para usuarios, es sobre todo un producto pensado para satisfacer a los desarrolladores, para convertirse en la mejor plataforma posible sobre la que construir los sitios web del futuro. Esta plataforma sólo puede asentarse en el mejor soporte posible a los estándares que están emergiendo en estos momentos y que configurarán la web de los próximos años. Veamos de qué forma se define el compromiso con los estándares como estrategia de producto en IE9. SAME MARKUP Same markup es una expresión que el equipo de IE ha acuñado a lo largo del desarrollo de IE9, desde la primera Platform Preview que se lanzó en Marzo de 2010 (24). Lo que encierran estas dos palabras es una apuesta decidida por simplificar el desarrollo web mediante el objetivo de que todo el código HTML, CSS, DOM, etc., muestre el mismo comportamiento en todos los navegadores modernos. 16

17 Para lograr este objetivo es imprescindible un impulso decidido al desarrollo de estándares, de ahí la posición de liderazgo que, desde un primer momento, Microsoft está desempeñando en el desarrollo de HTML5 y otras tecnologías de la web moderna. También se han introducido numerosas modificaciones en IE9 para adecuar su comportamiento bien al estándar, bien al comportamiento común en los demás navegadores, respetando el estándar de facto. Algunas de las modificaciones más relevantes las encontramos en las APIs innerhtml y outerhtml, la aparición de elementos genéricos, la nueva forma de gestionar los espacios en blanco, el trato a las etiquetas que se solapan incorrectamente, las etiquetas <title> y <object>, etc (25). Por otra parte, es necesario que los desarrolladores pongan de su parte a la hora de alcanzar el objetivo de utilizar un marcado común para todos los navegadores. Este esfuerzo se centra en adoptar buenas prácticas y abandonar algunas que perjudican la calidad del desarrollo final. Algunos de los consejos a la hora de realizar desarrollos web de mayor calidad que facilitan el uso de un marcado común son: - Realizar detección de características en lugar de detección de navegadores: detectar el navegador a la hora de saber si se puede utilizar un determinado método Javascript, por ejemplo, es un error. Un caso popular es el método addeventlistener, que no ha sido soportado hasta IE9. Las páginas que estén utilizando detección de navegador a la hora de elegir entre addeventlistener o attachevent, seguirán utilizando erróneamente el segundo a la hora de servir las páginas a IE9. Sin embargo, utilizando detección de características ya estarían listas, sin necesidad de ninguna modificación, para utilizar el método adecuado. - Realizar detección de comportamientos: resulta más conveniente detectar si el navegador soporta un determinado comportamiento, en lugar de basarse en el modelo o versión. Por ejemplo, para detectar si el método getelementbyid está disponible, el popular framework jquery realiza, internamente, la inyección de un elemento HTML que posteriormente trata de recuperar usando esa función Javascript. De este modo es posible saber si el método está soportado sin tener que confiar en modelos o versiones concretas. - Evitar asumir características no relacionadas: en ocasiones, si un navegador no soporta un determinado método, se asume que tampoco soporta otros. Esto es un error, puesto que en sucesivas versiones del mismo se pueden implementar esos métodos que ya se ha asumido que no están disponibles, recurriendo a atajos innecesarios. En su lugar es conveniente detectar cada característica por separado. Por último, es encomiable el esfuerzo que Microsoft está haciendo para que sus clientes abandonen el uso de Internet Explorer 6, con iniciativas como un sitio web específicamente dedicado a monitorizar la cuota de uso de IE6 alrededor del mundo, así como ofrecer información y herramientas para migrar o ayudar a otros a hacerlo. Pocas veces una empresa demostró un compromiso tal con los estándares como para criticar tan abiertamente un producto propio y desaconsejar su uso. Y como muy bien saben los desarrolladores web, ellos serán los principales beneficiados del abandono definitivo del impopular navegador. 17

18 Figura APIS ESTABLES Otra de las ideas que han guiado el desarrollo de IE9 ha sido el convencimiento de que el navegador debe implementar aquellas partes de HTML5 y demás estándares relacionados que tengan un grado de madurez suficiente como para no producir traumáticas rupturas de compatibilidad (26). En próximos capítulos podremos ver cómo esta idea se ha plasmado, por ejemplo, con la selección de los módulos CSS a implementar: aquellos que se encontraran en el nivel de Candidato a Recomendación o que ofrecieran un amplio consenso a través de todos los navegadores sobre su modo de funcionamiento. Ofrecer APIs estables se alinea también con la idea de desarrollar un único marcado válido a través de todos los navegadores. Con un modelo de programación consistente e interoperable, los desarrolladores podrán empezar a ofrecer experiencias confiables y duraderas a los usuarios, que no sufran bruscos contratiempos como el ocurrido con Web Sockets, del que se ha hablado en un punto anterior. Por otra parte, una empresa que se compromete con el desarrollo a estándares no puede diferir su implementación hasta que no son maduros, puesto que es imposible alcanzar dicha madurez si no se llevan a la práctica programándolos. Es en este punto dónde entra en juego la iniciativa HTML5 Labs. Veamos en qué consisten. HTML5 LABS El 21 de Diciembre de 2010 el equipo de Internet Explorer publicaba en su blog un post en el que recordaba los principios que estaban guiando el desarrollo de Internet Explorer (26). 18

19 Recapitulando, recordaban que su objetivo era incluir soporte en Internet Explorer para estándares que tuvieran el suficiente grado de madurez como para no esperar cambios significativos en su especificación. De este modo los desarrolladores podrían empezar a construir sitios web con HTML5 sin sufrir las consecuencias de un estándar cambiante que, de un día para otro, introduce un cambio que rompe la implementación hecha. Qué pasaría entonces con estos estándares? La única forma cierta de hacerlos evolucionar era mediante su implementación. Sin embargo, si Internet Explorer 9 no incluiría soporte a ellos, cómo iba a hacerse esa implementación? La respuesta estaba disponible en ese mismo instante en el blog sobre Interoperabilidad de Microsoft: HTML5 Labs (27). HTML5 Labs es un nuevo sitio web lanzado por Microsoft con un objetivo claro: prototipar estándares que todavía no están lo suficientemente maduros para formar parte de Internet Explorer 9. El objetivo es satisfacer a dos públicos: por una parte, el de los desarrolladores web, que necesitan una base estable y sólida sobre la que construir sus experiencias para los usuarios; por la otra, el de los entusiastas que desean trabajar con las últimas tecnologías y participar en el debate activo al respecto del futuro de estos estándares, cuando aún está definiéndose. Aunque ambos roles tienen cabida en una misma persona; separarlos no es sino una obligación. Con HTML5 Labs Microsoft se mantiene al frente del desarrollo de estándares, ofreciendo implementaciones de tecnologías y aportando feedback a los equipos de trabajo de cada una de ellas, al tiempo que evita dañar a los desarrolladores debido a constantes cambios en una implementación. Este escenario, como hemos visto en un punto anterior, no es un supuesto sino un hecho ya acontecido durante la evolución de los distintos estándares conocidos como HTML5. Probablemente no sea casualidad que los dos primeros estándares que Microsoft ha implementado a través de HTML5 Labs sean precisamente WebSockets e IndexedDB. Sin duda, tras ellos, vendrán otros que, de haber sido implementados directamente en el navegador, habrían causado problemas similares a los que provocaron en su momento ambos. 19

20 HTML5 Internet Explorer 9 ofrece un avanzado soporte a la especificación HTML5, fundamentalmente enfocado en las partes más estables del estándar que están listas para ser utilizadas, así como en patrones que se han revelado como ampliamente aceptados por la comunidad de desarrolladores web. En esta sección veremos no sólo el soporte que ofrece a HTML5 Internet Explorer 9, sino también qué es exactamente HTML5, qué no es y cómo podemos conocer el grado de soporte que cada navegador ofrece al mismo. LA MARCA HTML5 Antes de entrar en detalles sobre la implementación que podemos encontrar en IE9, es necesario aclarar una importante confusión que existe en torno a HTML5. Se está utilizando esta marca como un paraguas bajo el que se cobijan un gran número de especificaciones. Esta denominación está más próxima al marketing que a la realidad de la organización del W3C. En realidad lo que se suele identificar como HTML5 se corresponde con varios grupos de trabajo, dedicados a HTML, CSS, SVG, DOM, etc. Dentro de cada grupo de trabajo se evolucionan un gran número de estándares distintos. Por ejemplo, el grupo de trabajo de WebApps está sacando adelante estándares como Selectors API, Indexed DB, Web Storage, Web Sockets, etc. En el caso del grupo de HTML no es sólo la revisión del lenguaje HTML lo que se está editando, también se trabaja en otras especificaciones como Microdata o Canvas 2D Context. En la siguiente Figura podemos ver un esquema de los grupos de trabajo y las especificaciones en las que cada uno está trabajando, así como el nivel de madurez que presentan. Figura 2 - Estándares bajo la marca HTML5 20