Buceando en HTML5 y sus ventajas ¿qué hay de nuevo?

Estoy gratamente sorprendido por la nueva versión de HTML5. La W3C, ese organismo dedicado a crear retro-estándares, creo que va a tener bastante éxito con éste.

La ventaja que tienen los retro-estándares es que puedes escuchar a las partes implicadas que están usando ciertas tecnologías, puedes observar qué herramientas se están necesitando y qué tipo de aplicaciones se están desarrollando, para llegado el momento, coger todo eso y hacerlo formar parte de un estándar. Así no te puedes equivocar.

Voy a intentar desgranar los elementos nuevos que se nos ofrecen, tanto desde el punto de vista de la sintaxis como desde el scripting, contando por qué creo que es útil o en qué creo que lo hubiera utilizado. Este ejercicio es interesante para los desarrolladores web con cierta experiencia, ya que al ver alguna nueva característica pueden pensar

Aaaaaah!!! ésto yo lo hubiera usado en X, me hubiera facilitado la vida.

Si muchos desarrolladores piensan lo mismo, seguramente esa nueva funcionalidad va a tener éxito.

Hay ocho temas en los que se puede bucear, dentro de la nueva especificación:

Nuevo elementos semánticos como <header/>, <footer/> y <section/>.
Canvas, una superficie para hacer dibujos en dos dimensiones con Javascript.
Introducir vídeos en las páginas sin necesidad de plugins de terceros.
Geolocalización.
Almacenamiento persistente local.
Aplicaciones web que pueden trabajar en modo desconectado (offline).
Mejoras en los formularios.
Microdatos o microformatos, que te permiten crear tus propios vocabularios.

Nuevos elementos semánticos

De cara a la accesibilidad y a clarificar y mejorar ciertos usos erróneos de HTML han realizado un gran trabajo. Pero primero veamos algo sobre el doctype y sobre el elemento <html/>.

De sobra es conocido que HTML no es sólo un estándar definido en algún sitio, sino que es un estándar definido en algún sitio y vapuleado en muchos otros -tantos como navegadores- por lo tanto el doctype ha venido variando en función de muchas variables como el navegador, el modo de estándares o el modo «sucio» (quirks mode), y los gustos del programador. Antes de HTML5, un doctype que activa el modo estándares en todos los navegadores modernos venía a ser:

<!DOCTYPE html
PUBLIC «-//W3C//DTD XHTML 1.0 Strict//EN»
«http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd»>

Que en HTML5 no tiene nada de malo y lo podemos conservar si nos gusta, pero seguro que éste os gustará más:

<!DOCTYPE html>

¿No os dije que os gustaría más?

El elemento raíz de todo documento es <html/> y ha venido acumulando elementos redundantes, quedando así en XHTML:

<html xmlns=»http://www.w3.org/1999/xhtml»
lang=»en»
xml:lang=»en»>

Pero ahora resulta que todos los elementos de HTML5 están en el mismo namespace y que no hace falta repetir el idioma, por tanto nos quedamos con éste:

<html lang=»en»>

Sí, me gusta más.

Hay más cambios localizados dentro del elemento <head/> que no detallaré para no extenderme demasiado. Para el elemento <link/> existe un completísimo juego de nuevos tipos de relación para el que recomiendo acudir a linkTypes en whatwg.org. El otro cambio importante es el relativo a la especificación de la codificación de caracteres, que ahora queda:

<meta charset=»utf-8″ />

Y dentro del <body>, los flamantes elementos que vamos a poder usar serán:

<section/>. El significado de una sección dependerá de cada autor, pero normalmente está bastante claro. Una página personal o corporativa tiene secciones, que son zonas de contenido con una determinada cohesión, como por ejemplo las manidas secciones: Quienes somos, qué hacemos, donde estamos. Esta nueva etiqueta nos permite definirlas y que un analizador automático (básicamente un buscador) pueda tener constancia de estas secciones y quizá podría servir para que los buscadores generaran automáticamente un mapa de tu sitio.
<nav/>. Hay mil formas de definir visualmente un menú de navegación pero ninguna estandarizada para que la comprendan las máquinas. Esta etiqueta representa un paso importantísimo en la mejora de la accesibilidad de las páginas, porque un navegador preparado para personas con alguna discapacidad visual o motriz, sabrá donde tiene que buscar.
<article/>. Representa un item de información independiente, que puede ser usado o visto de forma independiente de la web principal. Puede ser un post de un blog, un widget o un post de un foro por ejemplo.
<aside>. Sirve para representar información que está relacionada con el contenido principal, pero por no distraer al lector se saca del flujo principal. Con el mismo sentido que los cuadros que vemos con citas o información relacionada, dentro de un artículo de una revista.
<hgroup/>. Se usa para agrupar los encabezados de una sección. Contendrá los conocidos elementos de <h1/> a <h6/>. El problema con estos elementos era que permitían generar un solo árbol para la estructura del sitio. Un ejemplo claro es el típico subencabezado. Si el encabezado recibe un <h1/> y los capítulos reciben cada uno un <h2/>, que es lo típico, entonces si hay un subencabezado puede a) quedar sin estructurar y sólo contaría visualmente b) Recibir otro <h2/>, que no sería correcto, porque no está al mismo nivel que los capítulos o aún peor c) Recibir un <h2/> y tener que relegar los capítulos a <h3/>.
La nueva etiqueta permite definir varios árboles y soluciona este problema. Para saber si se están usando bien se puede usar HTML5 outliner.
<header/>. En general esta etiqueta no te obliga a nada. Se podría usar para definir un conjunto de ayudas de navegación, o también puede contener los <h1/> a <h6/> o los <hgroup/>. Al final, casi todas las páginas que definimos suelen tener cabecera, cuerpo, pie. Esta etiqueta te permite definir qué comprende la cabecera.
<footer/>. Similar a <header/>. Todas las páginas suelen tener una zona al pie de contenido fijo.
<time/>. Me gusta y me parece especialmente importante esta etiqueta. ¿Cuantas veces hemos realizado búsquedas sin poder saber si el contenido encontrado es actual? Debemos pensar en que las máquinas deben poder reconocer la fecha y la hora de un documento, no sólo la persona. Si se especifica la fecha de creación con una etiqueta predeterminada como esta, conseguimos que los buscadores encuentren la información de la fecha que necesitamos, más rápidamente, y también que personas con una discapacidad visual puedan saber cuando fue escrito el documento. Te permite definir una fecha para que la lea un buscador y otra para que se presente visualmente:

<time datetime=»2009-10-22″ pubdate>22 de Octubre de 2009</time>
<mark/>. Sirve para marcar un texto con propósito de que sea una referencia. Sirve para atraer la atención sobre un determinado fragmento de texto y su equivalente visual podría ser -no que deba- una marca con un rotulador fluorescente sobre un papel.

Vemos que, sabiamente, el grueso de las mejoras va encaminado a que podamos construir documentos que sean comprendidos por un analizado automático, en la línea de lo que se intenta conseguir con la Web Semántica. Es muy lógico hacerlo así, ya que todo el aspecto visual de un documento se controla íntegramente con CSS.

Canvas

Con el canvas, definimos una zona del documento, donde mediante primitivas Javascript podemos crear diversas figuras y textos en dos dimensiones. La palabra signfica lienzo y eso es ni más ni menos lo que es. Es como tener el Paint avanzado en un documento web, permitiendo líneas, rellenos, textos, gradientes e incluso imágenes. Hay un ejemplo muy ameno donde se ha implementado el juego Halma. Otro ejemplo más interesante es la galería de imágenes con paso de página sin Flash.

Vídeo

Tenía que llegar. Después de tanta batalla con plugins y zarandajas, HTML5 ha definido un elemento <video/>. Claro que sí.

El problema sigue siendo, como no, que cada pareja navegador/sistema operativo va a apostar fuerte por su propio formato de vídeo, unos libres y otros no tanto. Pero el nuevo elemento tiene capacidades fallback, así que si el soporte nativo no funciona, siempre puede intentar reproducirlo mediante un plugin, como Flash. Y además te permite enlazar simultáneamente a varias versiones del vídeo, e intentará una por una reproducirlas, hasta que encuentre la primera que le venga bien.

Básicamente la situación a dia de escribir esta entrada, si quieres que se vea en la mayoría de las plataformas, será que hay que codificar el vídeo con varios codec y en varios contenedores:

Hacer una versión con vídeo Theora y audio Vorbis en un contenedor Ogg para Mozilla Firefox 3.5+, Google Chrome 3.0+ u Opera 10.5+. Son formatos libres y no restringidos por ninguna patente conocida.
Otra versión que use WebM (VP8 + Vorbis). Firefox, Chromium y Opera están empezando a incorporarlo. Es parecido a H.264 pero liberado por Google, que lo había comprado previamente.
Otra versión vídeo H.264 versión Baseline y audio AAC de baja complejidad, en un contenedor MP4, para IE9 (IE8 no soporta <video/>) y para Safari 3.0+ y dispositivos móviles. No son formatos libres.
Enlazar las tres versiones en un elemento <video/> y hacer fallback hacia un reproductor Flash.

No hay uno que les venga bien a todos. Unas veces por dispositivos de baja potencia como teléfonos móviles, que manejan mejor H.264 y otres veces por empecinarse en imponer un formato con patentes (Apple, Microsoft).

Geolocalización

Una API para realizar aplicaciones geolocalizadas, en la que el usuario tiene la decisión sobre si comparte su localización, y que incluye varias formas de ser localizado: dirección IP, células de telefonía, red wifi a las que estés conectado y como no, GPS cuando esté disponible. Las aplicaciones geolocalizadas están muy de moda con los dispositivos móviles con conexiones de datos y van a formar parte de nuestra vida lo queramos o no, así que es un buen movimiento englobar todos los sistemas de localización en una API uniforme.

Almacenamiento persistente local

Una manera de ir mucho más allá de las cookies. Un almacenamiento de gran tamaño en el cliente, que se mantiene aunque recargues la página y aunque cierres el navegador o incluso el ordenador. Y además que no es transmitido al servidor.

Básicamente se trata de una API Javascript para almacenar pares de <clave,valor> y que además define eventos capturables cuando la información almacenada cambia. Cada página recibe 5Mb de espacio para almacenar esta información.

Realmente hubiera usado esta funcionalidad en muchos proyectos, en los que la información almacenada en la sesión comenzaba a ser muy molesta en cuanto a la sobrecarga del servidor. Lo veo muy útil para almacenar las preferencias de navegación, estructura, colores o temas de un sitio web sin que el servidor tenga porque saber nada de ello, ni almacenarlo en base de datos ni en la sesión.

Aplicaciones web offline

Cada página del sitio deberá declarar un manifest cache donde indica los recursos (páginas html, css, etc.) que necesita para trabajar. El navegador las descargará y cuando vaya offline usará las copias que están en caché. Realmente esta característica tiene tanta enjundia que me remito al capítulo 8 del libro HTML5 Up and Running, de O’Reilly Media.

Cada vez más herramientas reales se están haciendo para la web. Veo esta característica de aplicaciones que pueden ejecutarse offline especialmente importante en aplicaciones de gestión de una organización que puedan depender de un servidor externo a esa organización. De esa manera, el usuario o usuaria puede seguir trabajando después de un corte de la conectividad. Desarrollé una aplicación de gestión inmobiliaria una vez, que aunque no era el objetivo, sí contenía ciertas características parecidas a ésto. Esta funcionalidad me hubiera ahorrado mucho trabajo.

Mejoras en los formularios

Las que siguen:

Texto por defecto. El típico texto de una caja que aparece proporcionando ayuda sobre el tipo de datos que se espera en ese campo y que desaparece automáticamente cuando el campo recibe el foco. Ésto ha sido un detalle muy de agradecer.
Campos autofoco. Cuando queremos que cierto campo reciba automáticamente el foco al cargar la página, pero hecho de forma declarativa en el código y no con Javascript.
Direcciones email. Sí, por fin, un campo para introducir el email que no sea un simple type=»text». Pero para completar la jugada, creo que los navegadores deberían validar automáticamente la corrección de un valor de tipo email. Opera parecer ser el único que está validando automáticamente el email en este tipo de campos.
Direcciones web. La misma argumentación.
Números. De nuevo este tema es muy interesante. Lo primero es que te proporciona nuevos atributos para el input y un nuevo tipo:

<input type=»number» min=»0″ max=»10″ step=»2″ value=»6″>

y lo segundo es que te ofrece algunos métodos Javascript para tratar estos campos: input.stepUp(n), input.stepDown(n) y (…redoble…) input.valueAsNumber() ¿Cuantas veces nos hemos visto en el cenagal de tener que hacer funciones para pasar un texto a un valor numérico, con todo su control de errores?. Se agradece.
Date pickers. ¿Se necesita comentario? Magnífica idea. Cuantas horas perdidas validando fechas o creando o integrando código para hacer datepickers.
Cajas de búsqueda. Cajas de texto especiales cuyo type es «search» y en la cual el Mac hará algunas pijadillas como presentártelo con bordes redondeados. Por ahora no merece más atención.
Color pickers. Bueno, algunos pueden pensar que es excesivo meter una operación no tan frecuente como elegir un color, en un componente genérico. Pero bueno, ahi está.

Para ampliar esta información sobre los <input/> podeis visitar los Estados del atributo type

Microdatos o microformatos

Ésta viene a ser la apuesta más arriesgada en pro de la Web Semántica. Si todos los desarrolladores web comenzáramos a pensar en términos de «voy a hacer una página que una máquina pueda comprender» en lugar de «voy a hacer una página que las personas puedan ver» llevaríamos el SEO a otro nivel y todos los métodos y trucos actuales quedarían desfasados, al tiempo que los buscadores serían mucho más eficaces.

Básicamente lo que queremos es aumentar los atributos disponibles para las etiquetas de forma que podamos definir Personas, Organizaciones, Productos, etc. Entonces, una pregunta a un buscador por el prouducto «Busca el Producto de marca HTC y modelo Wildfire» siempre devolvería resultados de páginas que describan ese producto, porque buscará dentro de los microformato, no simplemente ocurrencias de palabras. Veamos el ejemplo en código:

<section itemscope itemtype=»http://data-vocabulary.org/Product»>
<p itemprop=»brand»>HTC</p>
<p itemprop=»model»>Wildfire</p>
</section>

Claro está que todo tiene que atender a unas convenciones para saber de qué estamos hablando y de que mi idea de model es la misma que la tuya, por eso aquí están los items que podemos definir en Vocabulary.org. Aquí hay un ejemplo para definir a una persona

Para finalizar, comentar que he intentado exponer lo que se añade, pero también hay mucho que (¡al fin!) se elimina. Para ello nada mejor que consultar los Elementos obsoletos. Se dividen entre los que lanzarán solo una advertencia y los que no se deben usar. Si os preguntábais hasta cuando aguantarían el <marquee/> o el <blink/>… finalmente les ha llegado su hora.

¿Qué me hubiera gustado que se añadiera? Pues quizá un timeout para cuando cargas bilbiotecas externas de javascript (justo porque ahora mismo las bibliotecas ajax almacenadas en Google me están dando problemas) para no impedir la carga de la página. Quizá también algún método para definir grupos de imágenes que pudieran ser superpuestas, de modo que las imágenes que están más arriba actuaran a modo de máscara de las que están por debajo, y que no hubiera que conseguirlo a base de CSS… pero bueno por pedir que no quede ¿no? ¿Cual habría sido vuestra petición?