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…
