Flash exporta a… ¿qué, exactamente?

Adobe sigue blindando o intentando blindar a Flash (la herramienta de animación, más que la de desarrollo, parece) frente a los dispositivos (cada vez más, distinguidos por llevar al dorso un tatuaje de una pieza de fruta) que no reproducen Flash (el formato). Cosa que no debería sorprender a nadie. Pero sí me sigue sorpendiendo la manera en que lo están haciendo. Hoy han publicado en sus Labs Wallaby, an experimental technology that converts the artwork and animation contained in Adobe® Flash® Professional (FLA) files into HTML.

Si queréis ver un ejemplo de lo que hace, podéis ver un original en Flash y su transformación a HTML (encontrados ambos vía Andy Baio en enwire.dk). Las cosas que sorprenden:

  • Si habéis abierto la versión HTML con Firefox, Opera o IE… no habéis visto la animación. Porque ahora mismo solo funciona bajo navegadores Webkit (esto es, básicamente Safari y Chrome). Eso era razonable cuando hicieron la primera demo (a finales de octubre). Pero ya han pasado cuatro meses desde entonces…
  • Si abrís el código fuente veréis que no hay un canvas de por medio: el código muestra una colección de piezas en svg en divs anidados y animados en JavaScript usando jQuery y las herramientas de animación en JavaScript propias de WebKit.

Sus motivos deben tener, pero, por un lado, cuatro meses para lanzar algo a los Labs sin que funcione más que en navegadores (hasta ahora, al menos) minoritarios no me parece una gran idea. Uno podría sospechar que la idea es hacer algo que funcione óptimamente en la implementación de Webkit de Safari Mobile pero, entre nosotros, acabo de abrir la página en un iPhone y funcionar, funciona, pero… se arrastra. Y, por otro, si tenemos que imaginar que los desarrolladores de Webkit (y de Firefox Mobile, y de Opera Mini y Mobile) van a optimizar algo en sus motores, votaría por Canvas mucho antes que por cualquier otra cosa.

Vaya, que no dudo de la brillantez de los estrategas y desarrolladores de Adobe, pero no salgo de mi asombro…

El Opera Web Standards Curriculum, en español y catalán

Como sucede de vez en cuando, voy a juntar trabajo y blog en una entrada. Y es que parte de mi trabajo durante los últimos meses ha sido encargar y revisar la traducción, edición web y publicación del Opera Web Standards Curriculum, que desde hace unos días se encuentra disponible tanto en castellano como en catalán:

El Opera Web Standards Curriculum es una gran obra (por su calidad y su tamaño) para introducirse en el mundo del diseño y desarrollo web con estándares. Hace unos nueve meses ya (como un parto, oiga) comenzamos a buscar alternativas para la asignatura de Lenguajes y estándares web del grado de Multimedia de la UOC y el Curriculum, con su licencia Creative Commons, nos pareció una gran forma de dar a nuestros estudiantes un recurso de aprendizaje de calidad notable y, a la vez, contribuir a la comunidad en general con un recurso abierto.

“Sólo” tenemos los primeros 38 artículos y la cosa aún no está completamente acabada (¿qué lo está, en la web?). Para cualquier error que detectéis, tenéis los comentarios de esta entrada, mientras habilitamos un mecanismo mejor (sabemos, de momento, por ejemplo, que la navegación presenta algún problemilla en navegadores ‘webkit’ y que, precisamente con Opera :-S, el CSS para los <code> es más bien enorme…).

En unas semanas espero tener publicado en Mosaic algo un poco más extenso sobre el tema en un par de semanas pero, de momento, sirva esta entrada como anuncio no oficial. Espero que os sea de utilidad :-).

HTML 5: The Markup Language

Hace unos días (tantos como cuatro, ahora mismo) se publicaba el “borrador del editor” de HTML 5: The Markup Language, que “describe la quinta gran versión del lenguaje HTML y da detalles necesarios para que los creadores de documentos HTML creen documentos conformes al lenguaje”. Como “borrador de editor”, ni es completo ni existe un acuerdo total sobre sus contenidos, o sea que no hay que darle estatus de ‘ley’, pero sí es conveniente echarle un vistazo más o menos exhaustivo.

Y eso es lo que he hecho, y lo que sigue son mis notas al respecto. Muy parciales, como no podría ser de otra forma. Pero igual os son útiles. Aunque, como siempre, lo conveniente es leerse uno mismo el documento.

Los nuevos elementos semánticos

¿Bendición o sobrecarga semántica? ¿Es fantástico disponer de un elemento article para marcar cosas como artículos de una revista o entradas de un blog o ya estábamos bien con un <div class="article">? El jurado está deliberando. En la misma situación están aside (para “contenido tangencialmente relacionado con el que forma el flujo textual principal del documento”), dialog (para diálogos, que además incluye los dt y dd anteriormente limitados a las listas de descripciones), nav, para secciones de un documento que “enlazan a otros documentos o partes del propio documento; esto es, enlaces de navegación”, section para secciones de documentos o progress, para las barras de progeso.

También podríamos añadir hgroup, un contenedor de encabezados que debería usarse, por ejemplo, para agrupar títulos y subtítulos, o address, footer y header, a anotar, además, en la lista de etiquetas de HTML 5 que se van a usar muy mal: el universo asumirá que address es para direcciones (físicas y/o electrónicas), mientras que la especificación dice que es para información de contacto. De la misma forma, footer no es para los pies de página, sino para “pies de sección” y “típicamente contiene información sobre su sección, tales como quién la escribió, enlaces a documentos relacionados, información de copyright”: los metadatos de una entrada de blog, por ejemplo, vaya. Por su parte, el header contendrá, tipícamente, la cabecera de una sección, incluyendo titulares y contenidos como material introductorio o ayudas de navegación (si alguien aprecia un cierto solapamiento entre hgroup y header, no es el único).

No faltan, tampoco, los elementos que, permítanme jugar a adivino, apenas van a ser usados: ¿¡keygen para generar claves públicas y privadas!? ¿¡ruby y rp para ruby annotations (no me lo he mirado con detalle, pero es algo específico de Asia oriental)!? No son ni mucho menos tan escandalosos mark, para “texto marcado o resaltado para propósitos de referencia, por su relevancia en otro contexto”, meter, para “medidores” o small, que no es para reducir el tamaño, sino para poner “la letra pequeña” (de hecho, pueden intuirse usos interesantes, desde luego) pero tampoco creo que se vaya a usar universalmente, y su funcionalidad puede replicarse (y es replicada, por aquellos que necesitan la funcionalidad) de bastantes formas.

Todo el mundo tendrá su propia opinión sobre el posible exceso de elementos y/o la importancia de disponer de elementos realmente universales y/o lo positivo o negativo de poder extender de alguna forma más o menos semántica los elementos y clases de HTML. La del W3C no es ni más ni menos correcta que cualquier otra (o, al menos, no lo es menos: no olvidemos que es fruto del duro trabajo de bastante gente capacitada durante mucho tiempo), pero me siento con la capacidad de discrepar ligeramente…

Y ya para cerrar este apartado, también tenemos algunos elementos “poco definidos”, como command. Dice el documento que da detalles necesarios para que los creadores de HTML creen documentos de acuerdo a los estándares. No dice que dé todos los detalles. Y, como mínimo para mí, cierto es que en este caso no los da: “representa un comando que el usuario puede invocar”. Habrá que seguir prestando atención. En las mismas estamos con el elemento details, que “representa información adicional o controles que el usuario puede obtener bajo demanda”. Habrá que esperar para tener un documento que aclare estos detalles (o pelearse con el resto de documentos de HTML 5, claro).

Y el resto

Que no son esos elementos nuevos lo único que me ha llamado la atención. Unas cuantas cosillas más que me han parecido dignas de mención:

  • ¿HTML 5 o XHTML 5? HTML 5 tiene dos posibles sintaxis: HTML y XML. Si servimos el documento como text/html, debe usarse la sintaxis HTML. Si lo servimos como text/xml, application/xml o application/xml, debe usarse la sintaxis XML. El problema está, naturalmente, en el debe: los que estamos acostumbrados a escribir XHTML y servirlo como text/html vamos a tener que (i) pasarnos al HTML o bien (ii) apechugar con los peligros de servir XML (como la validación dura).
  • DOCTYPEs. Obligatorios en HTML, optativos en XML. Para documentos HTML nuevos, el doctype será <doctype html> o <doctype html system "about:legacy-compat"> (y sus variaciones). Los actuales DOCTYPEs pasan a ser “deprecated”, pero siguen estando dentro del estándar (con lo que mucho HTML 4 y XHTML 1 es, si está bien escrito, automáticamente, HTML 5).
  • Juegos de caracteres. Si no usamos US-ASCII (que no lo usaremos) es obligatorio declararlo usando un elemento meta.
  • SVG y MathML. Pueden usarse automáticamente, tanto en las sintaxis HTML como XML (aleluya ;-) ).
  • media y type. Atributos que pueden usarse, dentro de un elemento a, por ejemplo, para especificar el contenido del destino de un hiperenlace. type, que usa el ‘MIME type’, ya existía, pero media es nuevo y usa Media Queries.
  • El atributo ping. A usar dentro de los enlaces, si se desea, especifica una o más URLs a notificar cuando se sigue un enlace. Una bendición para hacer analítica, cuando menos…
  • audio, video y source. Crucemos los dedos para que los navegadores implementen suficientes codecs (y de manera homogénea) para que esto sea útil y no un fracaso bien intencionado… :-|
  • i y b. También conocidos como “los elementos presentacionales que se negaban a morir”. Para textos “cuya presentación tipográfica es en cursiva o negrita”. Estamos todos de acuerdo que ese tipo de texto no debe marcarse con un em ni un strong a no ser que se esté enfatizando. Pero, ¿por qué no usar un span class="bold" y CSS?
  • blockquote y cite. A falta de leer el documento para implementadores de agentes de usuario, sigue sin especificarse qué debe hacer un navegador con el atributo cite de un blockquote (y, por tanto, obligando a los autores a enseñarlo con JavaScript y obviando la existencia de cosas como los lectores de RSS).
  • Los atributos específicos de body. Ahíesná: onafterprint, onbeforeprint, onbeforeunload, onhashchange, onmessage, onoffline, ononline, onpopstate, onredo, onresize, onstorage, onundo y onunload. Habrá que estar al tanto, porque apuntan posibilidades interesantes. (Por cierto, tanto la etiqueta de apertura como la de cierre de bodypueden omitirse en bastantes ocasiones.) Y al nuevo atributo manifest del elemento html, que controla la caché de contenido para uso fuera de línea: es muy de agradecer el interés por lo que pasa cuando no disponemos de conexión.
  • sandbox y seamless. Dos atributos nuevos para el elemento iframe. El primero avisa al navegador que debe ir “con mucho ojito” con el contenido del iframe (restringiendo su acceso al resto de contenidos del documento, por ejemplo; si me apuran, yo habría activado esto por defecto y habría puesto un nosandbox…) y el segundo le dice que el contenido del iframe debería fundirse en la medida de lo posible con su contexto.
  • input. Le han salido tipos nuevos: date, time, week, month, datetime y datetime-local para fechas y horas, url y email (autoexplicativos), tel para los números de teléfono, number y range para números y rangos de números, color y search (también autoexplicativos). Otra vez la disyuntiva: ¿pesa más la universalización y la comodidad de validar automáticamente o la sobrepoblación de tipos?

PS 20090908 Ahora que está de moda lo de las ‘cheat sheets’, hay una, tamaño DIN A3, muy apañá, en Woork que detalla, entre otras cosas, los elementos que se han caídeo de HTML 4 a 5 y los nuevos…

¿Cuándo lo podré usar?

Captura de pantalla de la web 'When Can I Use', que indica qué nuevas características de los estándares web soporta cada versión de cada navegador
Los selectores de CSS 2.1, ya. Los 3, tardarán...

Es estos tiempos interesantes de versiones cambiantes de navegadores y estándares, saber qué está implementado en cada navegador es un auténtico cirio. Tremendamente útil, pues, es When can I use…, que te lista qué puedes usar en cada uno de los ‘grandes’ navegadores, en su versión ‘actual’, anterior, ‘próxima’ y futura…

HTML bonito

Código bonito. Más información en el artículo

Ahora que se lleva lo del “jogo bonito”, por un lado, y lo de las chuletas por el otro, What Beautiful HTML Code Looks Like da una serie de orientaciones sobre cómo estructurar el código HTML. Muy recomendable.