Desmitificando HTML5

Cliente: [...] y quiero que la web corporativa se haga en HTML5.
Desarrollador: ¿Necesita algún elemento nuevo de HTML5 en concreto?
Cliente: Uh... Esto... Bueno, quiero que tenga vídeo, gráficas interactivas, todo lo que trae HTML5.
Desarrollador: Sin problema, pero el precio del desarrollo subirá. Los gráficos en HTML5 hay que programarlos igualmente, lo único que en vez de Flash utilizaremos Canvas. Si queremos que el vídeo se vea en todos los navegadores, habrá que hacer diferentes codificaciones: necesitaremos más almacenamiento y hardware más potente para la codificación si hay mucho volumen de vídeos.
Cliente:¿Pero eso no viene ya de serie con el HTML5 ése?
Desarrollador: No, hay que hacerlo igualmente.

Reconozco que esta esta conversación ficticia está un poco traída por los pelos, pretende ser más satírica que otra cosa, pero ilustra un poco la sensación que tengo respecto al HTML5: parece que es la panacea y la solución a todo, la tecnología que finalmente hará de la web un lugar idílico, normalizado y estandarizado,... pero sigue haciendo falta alguien que programe.

Hay muchas novedades y aportaciones en HTML5 que ya han analizado en multitud de sitios, así que no voy a decir nada nuevo. Lo que quiero transmitir con este artículo es que HTML5 no es un milagro tecnológico ni nada similar (se oye demasiado a menudo "¡... y está hecho con HTML5...!", como si fuese lo más de lo más de la innovación y la solución a todos los problemas). Es una evolución (con muchos aciertos y posiblemente, limitaciones) del HTML y así es como los técnicos debemos verla. No nos dejemos llevar por el "hype" de las siglas y de los departamentos de Marketing ;-)

Algunas cosas que me parecen interesantes (en la Wikipedia viene un buen resumen):

• Mejoras semánticas (en mi opinión, casi la novedad más importante). En versiones anteriores, cada bloque en una página no tenía sentido semántico. Es decir, la cabecera, menú, pie de página, etc... eran siempre un
  . Con HTML5 tenemos , , , ...
  Esto parece una tontería, pero es muy importante y tiene muchas aplicaciones:
• Los buscadores pueden identificar rápidamente qué partes de la página son relevantes.
• Los agentes de usuario (navegadores) pueden presentar la página de acuerdo a las instrucciones que le de el usuario, por ejemplo: "ocultar la barra de menús" o "destacar el contenido del artículo", etc.
  Imaginemos un navegador/lector para personas con problemas de visión: cada vez que pasen de página no les leerá el interminable menú de navegación, ni la cabecera, etc. Directamente les leerá el contenido del artículo.
• Se facilita enormemente el intercambio de contenidos entre sitios web (y el "robo" también, todo hay que decirlo). Nuestros scripts ya sabrán qué hay que recoger en una página y qué no.
  
• Por fin se puede mostrar vídeo en el navegador sin necesidad de utilizar un plugin (típicamente, Flash). El problema está en los navegadores: cada uno soporta un formato/codec diferente. Si queremos garantizar que todos los navegadores podrán tratar con nuestro vídeo, hay que preparar múltiples fuentes.
  Ejemplo (c&p de la Wiki ;-)
  
  

  <video poster="movie.jpg" controls>
  <source src='movie.webm' type='video/webm; codecs="vp8.0, vorbis"'/>
  <source src='movie.ogv' type='video/ogg; codecs="theora, vorbis"'/>
  <source src='movie.mp4' type='video/mp4; codecs="avc1.4D401E, mp4a.40.2"'/>
  <p>This is fallback content</p>
  </video>
  
  Si queremos dar soporte a navegadores antiguos que no entiendan el tag , debemos preparar un mecanismo para mostrarles el vídeo a través de un plugin.
  
  

• Lo mismo es aplicable para el audio. Cada navegador funciona diferente.
  
• Gráficos 2D: se estandariza el tag y su API. Un bloque canvas sólo define una región que puede ser "pintada" a través de un script (típicamente Javascript). Nada más (y nada menos).
  Últimamente se ven algunas maravillas como juegos, pruebas de concepto, etc, "programados en HTML5". Error de concepto: están programados en Javascript y se muestran en una página HTML5.
  Hacer cosas en un no es una tarea trivial. En la especificación se definen funciones o métodos de bajo nivel y nada más. Existen bastantes "librerías" de Javascript que facilitan la tarea, pero no son parte de la especificación.
  
• Por fin se simplifican los DOCTYPE (se queda un simple ) y los atributos del tag .