DNM+ Online
dotnetmania 2.0
Curso de programación con HTML5, CSS3 y JavaScript (I)
Tras el anuncio de las novedades presentadas en BUILD, queda claro que en el panorama del desarrollador se ha abierto otro frente con muchas expectativas. Tanto en las nuevas aplicaciones Metro Style, como para los sitios y aplicaciones web independientes de Windows 8 (tradicionales, digamos), la construcción de sitios que adopten el nuevo estándar y la creación de aplicaciones que lo aprovechen para permitir un despliegue realmente independiente del dispositivo se están convirtiendo a pasos agigantados en una necesidad. Vamos aquí a revisar las novedades de HTML5, CSS3 y JavaScript (o ECMAScript, 5ª edición) y sus API relacionadas, para, de forma paulatina, permitir al lector una introducción en las posibilidades que ofrecen estos lenguajes y un rápido aprovechamiento en sus desarrollos.

Los orígenes de nuevo estándar

Tras un período de “silencio y mantenimiento”, como lo calificaba algún analista, la entidad que se encarga de forma oficial de los estándares de la Web, W3C#, ha vuelto a la carga. En palabras de Paul Cotton1 (uno de los responsables del estándar HTML5), el objetivo es construir algo llamado Open Web Platform (Plataforma Web Abierta), y para eso se tienen que cumplir algunos requisitos; el más importante, conseguir una adopción universal por parte de la empresa y el mundo académico.

¿Qué es un estándar “de iure”? (no “de facto”)

En la obra de Javier Holguera que el lector habrá recibido con el número anterior, estos conceptos se definían de la siguiente forma: “Existen dos tipos de estándares: de facto y de iure. Los primeros suelen establecerlos una compañía o producto, y 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 todas las partes interesadas antes de su publicación. Este proceso de revisión y consenso es, precisamente, el que hace más beneficiosos a los estándares de iure que los de facto, que normalmente responden a los intereses de una única parte.”

El lapso de tiempo desde el último estándar

Han transcurrido ya 10 años desde la última publicación de una especificación de HTML (la versión 4.012, para ser exactos). En el medio, mucho trabajo, pero no tantos estándares generados, a veces por falta de coordinación o conflictos de intereses. Lo más reseñable, la especificación XHTML 1.03, que en palabras de la propia W3C es una reformulación de HTML 4.0 en XML 1.0; o sea, un HTML con sintaxis estricta. Su adopción fue insuficiente.

El problema de las fechas de terminación

El problema principal a la hora de construir algo tan universal como HTML5 es precisamente ése: su universalidad. Tiene que haber consenso, tiene que servir para todos, tiene que ser lo más sencillo posible y aportar novedades significativas… En suma, que se necesita una gran cantidad de tiempo para poner todas las fuerzas en funcionamiento, cubrir todos los aspectos, realizar los paquetes de pruebas suficientes que aporten una garantía a lo que se aprueba, etc… Y el resultado, a primera vista, parece desalentador: la fecha prevista para la terminación definitiva de HTML5 se acerca al 2020 (si no después).

¿Qué sentido tiene entonces hablar de algo en fechas tan lejanas a su terminación? Según Cotton, el estándar podrá estar operativo dentro de un par de años a lo sumo, y, aunque la versión final candidata (la llamada “Candidate Recommendation”) no se termine de forma oficial hasta mucho después, todo el corpus principal del estándar debe estar listo –e implementado en los navegadores- mucho antes. De hecho, la mayoría de los navegadores modernos ya lo implementa en buena parte, y cada nueva versión aporta mayores niveles de compatibilidad. Además, ya existen librerías para resolver las posibles incompatibilidades en el caso de navegadores anteriores.

Objetivos de la estandarización

Cotton era bastante claro a la hora de sintetizar el objetivo principal: conseguir la Plataforma Web Abierta (Open Web Platform). En el camino, esto puede desglosarse en una serie de objetivos más sencillos y específicos. Voy a permitirme añadir una lista de algunos de los objetivos que los responsables parecen subrayar en sus intervenciones públicas:

  • HTML5: Un nuevo lenguaje de marcado que recoja las necesidades actuales (audio y vídeo, nuevo sistema de gráficos y animaciones, etiquetas semánticas que colaboren con los robots SEO, unificación de criterios y eliminación de etiquetas redundantes, compatibilidad hacia atrás), y sobre todo el aspecto del consenso que ya hemos citado.
  • CSS3: Un nuevo lenguaje de definición de estilos, coherente con el de marcado, que coopere con el anterior a la hora de facilitar la separación del contenido de la presentación, e igualmente recoja las necesidades actuales. Aquí el problema, de momento, es que el nivel de implementación del estándar por parte de los navegadores es bastante desigual, por lo que se requiere el uso de alternativas dependientes de cada navegador. También es de esperar que este problema se solucione cuando se alcance un grado de madurez suficiente. Pero los usuarios de Visual Studio estamos de suerte: Microsoft implementa estas características en el IDE, algo que se ha mejorado notablemente en la preview de la próxima versión, que ya está disponible para descarga.
  • ECMAScript, 5ª Edición: El nombre JavaScript es más un apodo que un nombre real (canónico, diríamos). Inicialmente, el lenguaje se llamó LiveScript, aunque posteriormente, por una decisión estratégica de Netscape y Sun MicroSystems, pasó a llamarse JavaScript. La entidad de estandarización de JavaScript es ECMA (European Computers Manufacturers Association). Y la especificación “oficial” de JavaScript no es otra cosa que el estándar ECMA-262, que vio su primera versión en 1997, si bien no fue hasta 1999, cuando se publicó la 3ª Edición, cuando comenzó su adopción de forma masiva. A partir de ahí, los que lo han implementado han construido diversas variantes del lenguaje. Por si esto fuera poco, la 4ª Edición se abandonó por diferencias políticas en la forma de implementación. Así que buena parte del trabajo realizado para esa versión 4 (el que disfrutaba de un mayor consenso) ha pasado a formar para de la nueva 5ª Edición. La idea de conseguir una nueva versión del lenguaje JavaScript que funcione paralelamente con HTML5 y CSS3, y que incluya ciertas novedades y ciertos aspectos ya en uso, como la notación JSON, es el objetivo central de este esfuerzo colectivo. Recientemente (junio de 2011), ECMA anunciaba la aprobación de la 5ª Edición de su estándar (figura 1), que muchos engloban en el nombre “ECMAScript 5”, o incluso, “JavaScript 5”, y que está disponible para descarga5. Los anexos D y E de dicho documento incluyen posibles aspectos de esta versión del lenguaje que podrían tener un impacto de cara a la compatibilidad con versiones anteriores. Además, los tests se realizan de forma independiente por otra entidad, la TC39 (ECMA Technical Committee 39), que dispone de un sitio dedicado6 en el que cualquiera puede colaborar si lo desea. Hablaremos más adelante sobre el tema de los tests. No obstante, el “motor de interpretación de JavaScript” es algo delicado, porque, estando hecho independientemente por cada fabricante, debe respetar el estándar de la misma forma. Hoy día existe más de una docena de motores implementados en software diverso, de los cuales solo 7 implementan compilación JIT (Just-In-Time), lo que les hace mucho más adecuados para la optimización del rendimiento y el aprovechamiento del hardware de la máquina: Carakan (Opera), Chakra (Internet Explorer 9), V8 (Chrome), SpiderMonkey (Firefox), SquirrelFish (Apple WebKit), JavaScriptCore (Safari) y Tamarin (Adobe Flash).
  • Las API relacionadas: HTML y sus tecnologías no aportarían mucho al objetivo de construir aplicaciones basadas en el estándar si no fuera por la presencia de API que aporten lo que ningún lenguaje de marcas o definiciones puede aportar. Y esto se resume, sobre todo, en la gestión del estado de las aplicaciones, la geo-localización, las aplicaciones offline, las comunicaciones dúplex, el almacenamiento local y de sesión, el acceso a una base de datos sencilla, el soporte de tareas asincrónicas, etc. El desarrollo de estas API no está siendo abordado directamente por W3C. Ellos, más bien, sirven de coordinadores del trabajo. La buena noticia es que se han establecido ya claramente cuáles van a ser las API más importantes, y cuáles definitivamente formarán parte de la versión final y cuáles no (por ejemplo, WebSQL se ha abandonado a favor de IndexDB).

Figura 1.

El sueño de una Web Semántica

Una de las promesas inherentes al nuevo estándar es la de dar un paso más hacia el sueño de una Web Semántica. Una Web con inteligencia basada en el significado. El término se acuñó en 2001 como resultado de un artículo escrito por Tim Berners-Lee, que describía la Web Semántica como “el lugar en el cual las máquinas pueden leer páginas Web con la misma facilidad con la que los humanos lo hacemos”.

Por su parte, Wikipedia define la Web Semántica con las siguientes palabras: “Se basa en la idea de añadir metadatos semánticos y ontológicos a la World Wide Web. Esas informaciones adicionales —que describen el contenido, el significado y la relación de los datos— se deben proporcionar de manera formal, para que así sea posible evaluarlas automáticamente por máquinas de procesamiento. El objetivo es mejorar Internet ampliando la interoperabilidad entre los sistemas informáticos usando ‘agentes inteligentes’, programas de ordenador que buscan información sin operadores humanos”.

En total, parecen ser más de 100 las especificaciones agrupadas bajo el concepto (la marca) HTML5, y esta cifra podría incrementarse en el futuro antes de llegar al estado “Last Call”. Pensemos que, bajo este nombre, tienen cabida cosas relacionadas, pero muy distintas, como el código de marcado en sí (HTML), las hojas de estilo en cascada (CSS), el mecanismo de representación gráfica vectorial (SVG), los motores de interpretación de JavaScript, las API relacionadas (ya aprobadas o en fase de serlo), etc. Esto plantea un serio reto respecto a las pruebas de funcionamiento.

Los tests

Con los materiales reunidos como posibles elementos del nuevo estándar, comienzan simultáneamente las pruebas. Internamente, W3C dispone de una herramienta denominada Bugzilla, con la que se gestiona el estado de los bugs y su situación respecto a la resolución.

A partir de aquí, existe una serie de herramientas que W3C y sus entidades asociadas utilizan para los tests oficiales, y otro buen conjunto de iniciativas individuales, “extraoficiales”, que pretenden elaborar cuadros de conformidad respecto a las normas oficiales. La validez de las iniciativas que están fuera de los canales oficiales es más que discutible, y algunas veces roza lo partidista o simplemente interesado. E incluso entre las más universalmente aceptadas, como los tests ACID (figura 2), se dan circunstancias especiales. Es curioso comprobar que con una pequeña modificación del contexto, en la actualidad, todos los navegadores populares en sus últimas versiones pasan completamente los test ACID (IE9/10, FireFox7, Safari 5, Chrome 14 y Opera 11.5).

Figura 2.

Así pues, los tests serios de compatibilidad con el estándar son los que provienen, principalmente, de los creadores del estándar. En concreto, la página “HTML5 Test Suite Conformance Results”7 realiza un test de compatibilidad para cada visitante, indicándole el nivel de conformidad del navegador elegido respecto a 7 grupos principales, y realizando posteriormente un desglose de un total de más de 900 tests, uno a uno. En esta prueba, IE9 es el que sale mejor parado de todos los navegadores actuales, como puede verse en la figura 3.

Además, para aquellos interesados o curiosos respecto a un determinado aspecto del estándar, existe una página de W3C que permite realizar test individuales de una sola característica, disponible en la dirección http://w3c-test.org/html/tests/harness/harness.htm.

Figura 3. Resumen de la evaluación de tests del sitio oficial. Obsérvese cómo la cabecera indica el número de tests pasados, y solicita la colaboración de la comunidad

Conclusión

Aclarado lo anterior, ya estamos en condiciones de ponernos a trabajar con el estándar a la vista de lo que ofrece en este momento. El hecho de que la especificación haya alcanzado el estatus de “Last Call” indica que son ya mínimas las modificaciones que pueden añadirse a él, y que las que se hagan serán, probablemente, de poca profundidad. En el próximo número comenzaremos por ver las nuevas etiquetas que propone HTML5. Más adelante, analizaremos los nuevos conjuntos de atributos, la especificación CSS3, la especificación ECMAScript, 5ª Edición, y terminaremos revisando las nuevas API especialmente pensadas para aplicaciones web.

blog comments powered by Disqus