Por qué el elemento ‘Video’ de HTML5 es inútil a efectos prácticos, incluso en los navegadores en los que funciona

Monday, 21 December 2009

Rara vez publico vídeos en DF, pero cuando lo hago me niego a incustrar un objeto Flash [1. En cuanto a por qué me niego a incrustar un objeto Flash, voy a expresarlo así: Utilizo y recomiendo de veras el programa ClickToFlash, que bloquea por defecto todos los contenidos Flash. ¿Por qué publicaría contenidos que emplean una tecnología que yo mismo bloqueo por defecto? Sinceramente deseo ver cómo Flash deja de el el estándar de facto para el vídeo incrustado en la web, y estoy dispuesto a que mi código hable por mí.]; quiero que el código sea sensato y de acuerdo a los estándares, quiero que el vídeo se pueda reproducir en navegadores de uso generalizado que cumplen los estándares, y no quiero que el vídeo se descargue automáticamente. Aquí hay un ejemplo de hace un año en el que usé QuickTime.

Lo que podéis ver al cargar la página es un fotograma póster (una imagen fija); entonces el usuario hace clic en el fotograma póster para que el vídeo se descargue y se reproduzca. Este es el código que usé en aquella ocasión:

<embed
   width="320" height="256"
   type="video/quicktime"
   pluginspage="http://www.apple.com/quicktime/download/"
   src="dtk-panic-1-poster.jpg"
   href="dtk-panic-1.mov"
   target="myself"
   controller="false"
   autoplay="false"
   scale="aspect"
/>

Ese código cumplía con todas las exigencias mencionadas anteriormente, salvo por una: el tag <embed> no es estándar. Peor aún, ahora tiene un nuevo e importante problema: no funciona en absoluto en Chrome (al menos en la versión para Mac).

Así que he estado siguiendo de cerca el nuevo código alternativo, normalmente de una gran complejidad, y que muestra el vídeo usando un reproductor Flash en los navegadores antiguos. Debido a que (a) no publico muchos vídeos; (b) la gran mayoría de los seguidores de DF usan una versión de Safari, Firefox o Chrome compatible con HTML5 (en el momento de redactar este artículo, Daring Fireball recibe más o menos el doble de visitas de MobileSafari que de todas las versiones juntas de Internet Explorer en cualquier día laboral); y (c) no me importa ser un poco capullo con este asunto; no me preocupa no utilizar código alternativo para navegadores que no soportan el elemento <video>.

Lo que me gustaría hacer es poder usar <video> con dos elementos de fuente — en formato MP4 y OGV — por todas las razones de compatibilidad entre navegadores detalladas en el estupendo capítulo de Mark Pilgrim sobre el vídeo en el libro sobre HTML5 en el que está trabajando. (Versión corta: Safari y MobileSafari únicamente soportan MP4, Firefox sólo soporta OGV, Chrome soporta tanto MP4 como OGV)[3. Haber tenido que incluir archivos distintos del mismo vídeo codificados en dos formatos distintos es verdaderamente incómodo. No lo es tanto el código extra comparado con el trabajo adicional de crear y codificar el segundo vídeo. Incluso los vídeos cortos que creé para ilustrar mi artículo sobre PastryKit tardaron unos minutos en comprimirse cada uno. En relación a la mayoría de las tareas que se realizan hoy con el ordenador, comprimir vídeo una vez ya cansa por lo lento que es. Comprimir dos veces es una pérdida de tiempo que nadie necesita. Pero así es como están las cosas.].

Así que decidí probar esta opción la semana pasada con los screencasts que creé para ilustrar mi artículo sobre PastryKit. Probé un código como el siguiente:

<video height="475"  width="407"  controls  poster="iphoneguide-mac.png">
   <source src="iphoneguide-mac.mp4" type="video/mp4" />
   <source src="iphoneguide-mac.ogv" type="video/OGV" />
</video>

Las buenas noticias: Este código funciona en Safari, Chrome y Firefox. También funciona a la perfección en MobileSafari en iPhone OS. Safari y Chrome reproducen el vídeo MP4, mientras que Firefox reproduce el OGV. (Chrome soporta ambos formatos, y reproduce el que se ha incrustado en primer lugar. Quiero que reproduzca la versión en MP4 porque la imagen y el sonido tienen una calidad notablemente superior). Ese es todo el código que hace falta; si no estáis familiarizados con el horrible código que se suele usar para incrustar vídeo, probad a ver el código fuente en unas cuantas páginas que tengan vídeo incrustado.

Las malas noticias: En los tres navegadores mencionados (Safari, Chrome, Firefox), con el sencillo código mostrado anteriormente el vídeo comienza a descargarse en el buffer de forma automática al cargar la página. Lo que quiero decir es que, en cuanto cargas la página web, los navegadores descargan los propios archivos de vídeos que se han incrustado. Como mencionaba al principio, no quiero que ocurra eso. En lugar de esto, quiero que al cargar la página el navegador muestre únicamente el fotograma póster, y cargue el vídeo solamente cuando el usuario haya hecho clic sobre él para iniciar la reproducción del vídeo.

Las especificaciones de HTML5 definen un atributo autobuffer para el vídeo y otros elementos multimedia (negritas añadidas para dar énfasis):

El atributo autobuffer es un atributo booleano. Su presencia le indica al usuario que el autor cree que el elemento multimedia se utilizará, incluso aunque el elemento no tenga un atributo autoplay. (Este atributo no tiene ningún efecto al usarse junto al atributo autoplay, aunque incluir ambos no es un error). Este atributo puede ser ignorado por el navegador.

Se diría, juzgando por mis experimentos, que estos tres navegadores le toman la palabra al fragmento en negrita de las especificaciones e ignoran el atributo en cuestión. Incluso aunque no actives este atributo, Safari, Chrome y Firefox seguirán descargando en el buffer el contenido enlazado en los elementos <video> (y <audio>). No hay modo de evitarlo usando código HTML.

Puede que estéis pensando “Oye, aún así parece una buena forma de actuar, porque de este modo los usuarios no tienen por qué esperar tanto tiempo a que el vídeo esté listo para reproducirse”. Imagino que esta forma de pensar es lo que ha llevado a los equipos de desarrollo de Safari, Chrome y Firefox a hacer esto.

Pero este comportamiento del navegador es muy inconveniente para usuarios y autores en ciertos contextos. Los usuarios que cargan la página con una conexión lenta, o con un acceso en el que pagan por el megabyte (cosa habitual en las redes inalámbricas), no deberían verse obligados a descargar un vídeo posiblemente grande cada vez que cargan la página. De igual modo, los autores no deberían verse obligados a pagar el ancho de banda para transferir vídeos que no van a verse.

Pensad en concreto en la naturaleza de la publicación de un vídeo incrustado en un weblog. Yo, el autor, publico un artículo que contiene un vídeo incrustado. Este artículo permanece visible en mi página de inicio durante una semana. Los lectores habituales pueden llegar a cargar la páginas de inicio decenas de veces durante el periodo de tiempo que el vídeo aparece. Con el buffering automático, van a descargar el vídeo entero cada vez que carguen la página. El caché local podría aliviar parte de la carga que supongan esos accesos, pero para sitios web con un gran tráfico y/o que suelan incrustar vídeo, la diferencia es abismal.

Es por esto por lo que los vídeos incrustados de YouTube, Vimeo y todos los sistemas parecidos se reproducen solamente al hacer clic sobre ellos. La descarga automática del vídeo está bien como atributo opcional, pero para muchos (probablemente la mayoría) contextos, resulta esencial la funcionalidad de hacer clic para cargar el vídeo.

Pero hasta donde llego no hay manera de conseguir vídeo con funcionalidad clic-para-cargar en Safari, Chrome o Firefox usando solamente un elemento <video>. La única solución que se me ha ocurrido era hacer algo así:

  1. En el código HTML, en lugar de usar un elemento <video>, utilizar un elemento <img> que cargue la imagen del fotograma póster.
  2. Añadir un control JavaScript onclick al elemento <img>, que, al ser activado haga sus tejemanejes con el DOM para quitar el elemento <img> sobre el que acabamos de hacer clic y lo sustituya con un elemento <video> que cargue los archivos de vídeo que queremos mostrar.

Y, de hecho, eso es justamente lo que utilicé para mis vídeos sobre PastryKit. Mirad el código fuente de la página para ver la solución. Adiós al código limpio y bonito para incluir-un-vídeo-tan-fácilmente-como-una-imagen. (Mis agradecimientos sinceros a Faruk Ates y Paul Irish por sus ayudas con la programación de los tejemanejes de JavaScript).

Este bug de WebKit notificado en Abril indica que no soy el primero que se da cuenta de este defecto. El mensaje trata sobre el elemento <audio> en lugar de <video>, pero el principio es exactamente el mismo. Y el ejemplo citado en el mensaje sobre el bug parece un caso ideal en el que todos deberían coincidir en que los contenidos multimedia no deberían descargarse de forma automática: una página del archivo de un podcast con un elemento <audio> por cada episodio.

Gran parte del atractivo de los elementos <video> y <audio> es que deberían ser más fáciles de usar. No obstante, en su estado actual estos elementos son inutilizables en ciertos contextos sin recurrir a la manipulación del DOM mediante JavaScript para conseguir que no se dispare la descarga automática de los contenidos multimedia.

Creo que la especificación del HTML5 debería cambiarse para que el valor del atribute autobuffer sea respetado de forma obligatoria. E incluso si la especificación no es modificada, los navegadores web no deberían escoger la opción de ignorarlo. Los navegadores web sólo deberían descargar en el buffer contenidos multimedia de HTML5 cuando el atributo autobuffer o el atributo autoplay están activados de forma explícita en el código.