Semántica en HTML 5

Estoy por hacer una predicción audaz. Mucho después de nuestra existencia, HTML seguirá existiendo. No únicamente en billones de páginas archivadas de nuestra era, sino como una entidad viva que respira. Mucho esfuerzo, energía e inversión ha sido destinada a desarrollar las herramientas, protocolos y plataformas de la web, como para ser abandonados a la ligera, si llegan a ser abandonados en lo absoluto.

HTML 5, el reciente esfuerzo redoblado del W3C por darle forma a la siguiente generación de HTML, ha tenido un considerable impulso durante el último año. Es un proyecto enorme, que considera no solo la estructura de HTML, sino los modelos de análisis, el manejo de errores, el DOM (Modelo de Objetos del Documento), los algoritmos para obtener recursos, contenido multimedia, dibujo en 2D, plantillas de datos, modelos de seguridad, modelos para cargar páginas, almacenamiento de información del lado del cliente, y mucho más.

Igualmente se hicieron revisiones a la estructura, sintaxis y semántica de HTML, algunos de los cuáles han sido cubiertos por Lachlan Hunt en “A Preview of HTML 5.”

Sin embargo, durante este artículo enfoquémonos en la semántica de HTML. Es algo que me ha interesado por varios años, y algo que creo fundamental para el futuro de HTML.

La BBC recientemente anunció que removerían el microformato hCalendar de su listado de programas, debido a problemas de accesibilidad y usabilidad con el patrón de diseño abbr. Esto demuestra que, sin duda alguna, hemos explotado la capacidad semántica de HTML mucho más allá de lo que alguna vez se pensó, y por ende, lo que es posible mediante este lenguaje. Nos hemos simplemente acabado los elementos y atributos de HTML con los que desarrollamos documentos de semántica abundante. Si continuamos siendo astutos con los bloques de construcción de HTML que actualmente existen, más problemas como estos ocurrirán. Pero HTML sufre un defecto fundamental como lenguaje de marcado semántico — su semántica es fija, no extensible.

Este no es un simple problema teórico. Cientos de miles de desarrolladores usan los atributos id yclass de HTML para crear marcado semánticamente más rico. (También son usados como “hooks” para dar estilo con CSS, pero eso es otro asunto.) Casi siempre, los desarrolladores utilizan vocabulario ad hoc — ósea, palabras que ellos mismos inventan, en vez de valores tomados de esquemas existentes. Es marcado pseudo semántico a lo mucho.

Muchas páginas en la web utilizan microformatos para añadir semántica más estructurada que la disponible en el empobrecido conjunto de elementos y atributos de HTML. En tales casos, los valores usados para el atributo class vienen de convenciones de vocabularios, algunas veces adoptados de otros estándares, como vCard, o en ocasiones de vocabularios recientemente acuñados sin estándares sólidos pre-existentes (como es el caso de hReview).

Semántica extensible#section1

Este es un problema muy tangible que debe ser resuelto. Necesitamos mecanismos en HTML que claramente y sin ambigüedad permitan a los desarrolladores añadir semántica más completa y significativa — no pseudo-semántica — al marcado. Esta es posiblemente la única meta de importancia para el proyecto HTML 5.

Sin embargo, no es tan sencillo como ingeniar un mecanismo para crear semántica más completa en el contenido de HTML: hay restricciones a considerar con cualquier solución. Probablemente la mayor restricción sea la compatibilidad con versiones anteriores. La solución no puede inhabilitar a los miles de millones de dispositivos utilizando el navegador hoy en día, que continuarán en uso durante los años que vengan. Cualquier solución que no es compatible con lo anterior, no será ampliamente aceptado por desarrolladores ante el miedo de excluir usuarios. Será rápidamente dejado en el olvido.

La solución debe ser igualmente compatible con futuras versiones. No en el sentido de que debe funcionar con futuros navegadores — esa es responsabilidad de los desarrolladores de navegadores — sino en el sentido de ser extensible. No podemos esperar que una solución desarrollada justo ahora, resuelva todas las semánticas tanto imaginables como inimaginables que surjan en el futuro. Sin embargo, podemos desarrollar una solución que pueda ser extendida para permitir atender necesidades futuras según vayan surgiendo.

Estas dos restricciones por sí solas representan un gran reto. Pero en el contexto de un lenguaje con mejoras mayores llegando con una década de diferencia, y cuya importancia como plataforma global para la comunicación es suprema, este es un reto que debe ser resuelto.

Entonces, ¿cómo busca arreglar esto HTML 5? HTML 5 introduce un número de elementos nuevos. Algunos de estos son algo a lo que llamo “estructural” — section, nav, aside, header, y footer. El elemento dialog es un tipo de elemento de contenido, similar a blockquote. También hay un número de elementos de información (data elements), como por ejemplo, meter, que “representa una medida escalar dentro de un rango conocido, o un valor fraccional; por ejemplo, el uso en disco,” y el elemento time, que representa una fecha y/u hora.

Mientras estos elementos podrían ser útiles, y parecen haber generado algo de interés, ¿realmente resuelven el problema que hemos identificado, particularmente dentro de las resticciones gemelas que son la compatibilidad con versiones futuras y pasadas?

Consideremos cada restricción.

Compatibilidad con versiones anteriores#section2

¿Cómo logran los navegadores actuales manejar los nuevos elementos, como section? Pues, las versiones más recientes de Safari, Opera, Mozilla, e incluso IE7 interpretarán la página de la siguiente manera.

<h1>Encabezado De Primer Nivel</h1> <section>
    <h1>Encabezado De Segundo Nivel</h1>
    <p>Este texto está dentro del elemento section</p> <section>
        <h1>Encabezado De Tercer Nivel</h1>
    </section>
</section>

Parece un buen comienzo. Sin embargo, cuando intentamos aplicar estilo, por ejemplo, a elementos section utilizando el siguiente CSS:

section {color: red}

…la mayoría de los navegadores mencionados arriba logran dar estilo al elemento, pero IE7 (y seguramente también IE6) no lo hacen.

Por lo que tenemos un serio problema de compatibilidad con versiones anteriores en el 75% de los navegadores actualmente en uso. Dada la larga vida de Internet Explorer, podemos predecir que la mayoría de los usuarios continuarán usando IE6 o IE7 por muchos años más.

Si HTML 5 introduce estos nuevos elementos, ¿cuál es la probabilidad de que serán implementados por la gran mayoría de desarrolladores─teniendo el conocimiento de que son en esencia incompatibles con gran parte de los navegadores en uso?

Desafortunadamente, si están buscando por soluciones alternativas al problema de CSS, agregando atributos class en tus elementossection y después tratar de darles estilo utilizando el valor de la clase, no funcionará en IE. Tal vez hay algún tipo de método alternativo, pero de no ser así, parece que estamos en un callejón sin salida.

Movámonos a la compatibilidad con versiones futuras, la segunda restricción de nuestra lista.

Compatibilidad con futuras versiones#section3

Comencemos presentando la pregunta “¿por qué estamos inventando estos nuevos elementos?”. Una respuesta razonable sería: “porque HTML no tiene riqueza semántica, y al añadir estos elementos aumentamos su contenido─eso no puede ser malo, ¿o sí?”.

Al añadir estos nuevos elementos, estamos resolviendo la necesidad por mayor capacidad semántica en HTML, pero solo dentro de un alcance reducido. No importa la cantidad de nuevos elementos que se nos ocurran, siempre podremos pensar en más bondad semántica que podríamos añadir a HTML. Por lo tanto, habiendo añadido los nuevos elementos que deseamos, aún no está resuelto nuestro problema. No necesitamos añadir términos específicos al vocabulario de HTML, lo que necesitamos es un mecanismo que permita añadir riqueza semántica al documento según se requiera. En términos técnicos, necesitamos hacer a HTML extensible. HTML 5 no propone mecanismos para ser extendido.

HTML 5, por lo tanto, implementa una característica que termina con la compatibilidad en un alto porcentaje de navegadores, sin realmente permitirnos añadir semántica al lenguage en lo absoluto.

Muchas preguntas persisten sobre los nuevos elementos. ¿De dónde han venido los nombres de estos nuevos elementos? ¿Cómo fue decidido que debería haber un elemento para la navegación y que debería ser llamado nav? ¿Por qué el mismo término aplica para la navegación a nivel de página, nivel de sitio, y nivel de meta-sitio?

¿Por qué no adoptar un vocabulario existente, como Docbook? Su vocabulario para estructurar documentos es mucho más completo y ha sido desarrollado por expertos durante muchos años. Este no es un argumento a favor de Docbook en específico: el punto es que la tarea de extrema importancia de proveer un mecanismo para la riqueza semántica de HTML, está siento resuelta en una forma ad hoc, aparentemente prestando poca atención a las mejores prácticas en trabajos relacionados, regresando incluso más de 30 años. (El trabajo original en GML (Lenguaje de Marcado General) comenzó a principios de la década de 1970.)

Algunas ideas para una solución#section4

Entonces, habiendo sido crítico con respecto a los esfuerzos actuales, ¿tengo alguna propuesta práctica sobre cómo resolver este problema? Bueno, pues tengo el comienzo para una posible solución.

Si añadir elementos a HTML está fuera de contexto, al menos en los parámetros de esta discusión, los atributos son el área lógica donde HTML debería concentrarse. Después de todo, por casi una década hemos estado utilizando los atributos id y class como mecanismos para extender la semántica de HTML. Una gran parte de los desarrolladores están familiarizados y se sienten cómodos con esto. El proyecto de microformatos demostró que los atributos existentes de HTML no son suficientes para ser usados como un mecanismo generalizado para extender la semántica de HTML. Por lo tanto, si vamos a usar atributos para resolver este problema, necesitamos idear uno o varios atributos nuevos. Antes de que nos adentremos en la parte técnica de cómo podría funcionar eso, sería correcto ajustar esta propuesta a los mismos requerimentos que tenemos para los nuevos elementos de HTML 5. Principalmente, ¿es compatible con versiones anteriores introducir nuevos atributos a HTML? Y si lo es, ¿esto brinda un mecanismo factible para la expansión semántica de HTML?

Inventemos un nuevo atributo. Lo llamaré “structure”, pero el nombre en particular no es lo importante. Lo podemos utilizar de la siguiente manera:

<div structure=“header”>

Veamos cómo lo interpretan nuestros navegadores.

Por supuesto, todos nuestros navegadores aplicarán estilo con CSS.

div {color: red}

Pero, ¿qué pasa si realizo lo siguiente?

div[structure] {font-weight: bold}

De hecho, casi todos los navegadores, incluyendo IE7, aplican el estilo al div con el atributo structure, incluso si no existe tal atributo llamado structure! Desgraciadamente, nuestra suerte se acaba ahí, pues en IE6 no funciona. Pero podemos utilizar el atributo en HTML, y lograr que todos los navegadores existentes lo reconozcan. Incluso podemos utilizar CSS para dar estilo a nuestro HTML utilizando el atributo en todos los navegadores modernos. Y si queremos una alternativa para navegadores antiguos, podemos añadir un valor en el atributo class del elemento para dar estilo. Comparemos esto con la solución de HTML 5, que añade nuevos elementos a los que no se les puede aplicar estilo en Internet Explorer 6 o 7, y verás que es definitivamente una solución con mejor compatibilidad con versiones pasadas.

Extensibilidad mediante atributos#section5

En vez de elementos nuevos, HTML 5 debería adoptar un número de atributos nuevos. Cada uno de estos atributos estaría relacionados con una categoría o tipo de semántica. Por ejemplo, como he detallado en otro artículo, HTML incluye semántica de tipo estructural, retórica, de roles (adoptado de XHTML), y otras clases o categorías de semántica.

Estos nuevos atributos podría ser usados similar a como se utiliza el atributo class: para añadir semántica a un elemento, y describir de esta manera su naturaleza o meta-información.

Esto no es diferente al atributo rol de XHTML, sino que en vez de tener un único atributo “contenedor” para la semántica de todos los elementos, deberíamos identificar los diferentes tipos de semántica para un elemento, y separarlos.

Por ejemplo, el atributo de XHTML role funciona así:

<ul role="navigation sitemap">
    <li href="downloads">Descargas</li>
    <li href="docs">Documentación</li>
    <li href="news">Noticias</li>
</ul>

Los valores del atributo role son una lista de palabras separadas por espacios, provenientes del vocabulario por defecto, o de un vocabulario definido.

¿Por qué no simplemente adoptar el atributo role tal y como es? Pues, hay otros tipos de semántica por los que el término role no aplica. Por ejemplo:

<p rethoric="irony">Él es una persona asombrosa.</p>

Esto demuestra un tipo teórico de semántica──”rethoric”, que puede ser utilizado para marcar la naturaleza retórica del documento. Sin embargo, este elemento claramente no funciona como algo retórico en el documento. Sino que los contenidos del elemento son irónicos.

Aquí hay otro ejemplo. Cada vez es más notable que HTML necesita una manera de añadir una versión legible para una máquina de los valores entendibles para los humanos, por ejemplo, una fecha. Esto está en el núcleo del problema que la BBC tiene con el microformato hCalendar al que nos referimos anteriormente. Mientras <span role="2009-05-01">May Day next year realmente no tiene sentido, algo como <span equivalent="2009-05-01">May Day next year podría tenerlo.

De nuevo, utilizar el término específico equivalent o algún otro término para este tipo de atributo semántico no es el problema. Lo que debemos notar es que no es tan simple como utilizar el atributo class o el atributo role como si fuera un contenedor donde podemos meter toda la información semántica. Para una solución propiamente extensible que brinde compatibilidad con versiones anteriores y flexibilidad suficiente, una solución entre líneas debería ser algo a investigar.

Titulé esta sección como “Ideas para una solución” porque una gran cantidad de trabajo debe realmente llevarse a cabo para desarrollar una solución factible. Las siguientes son algunas preguntas a considerar.

• ¿Cuántos tipos distintos de atributos semánticos deberían haber? ¿Deberían ser extensibles estas categorías? Y si es así, ¿cómo debería implementarse?
• ¿Cómo se determinan los vocabularios?
• ¿Simplemente inventamos los términos que queremos, similar a la forma en que los desarrolladores han estado utilizando los valores class, o deberíamos estandarizar los posibles valores a utilizar? ¿O debería haber un mecanismo para inventar (y posiblemente compartir) vocabularios, utilizando algún tipo de perfil?
• Si tenemos conflictos entre dos vocabularios, como dos términos idénticos que se definen por dos vocabularios distintos, ¿cómo se resolvería?
• ¿Necesitamos algún tipo de espacio de nombres, o existe otro mecanismo?

En vez de apurarnos por responder estas preguntas, las presento como algunos problemas que necesitan ser considerados, por los que se debería comenzar un diálogo. Las consecuencias de las decisiones tomadas en HTML 5 son demasiado grandes como para tomar decisiones en ausencia de alguna entrada para los campos de expertos en lingüística, semántica, semiótica, y otras áreas relacionadas.

Espero por sobre todo, que ahora sea claro que “inventar nuevos elementos” no es una solución para incrementar la capacidad semántica de HTML.

No nos apuremos en tomar estas decisiones a la ligera─después de todo, con el calentamiento global ya le estamos dejando muchos problemas a nuestros nietos como para preocuparlos más. Al menos, heredemos el mejor HTML que podamos.

*Traducido al español por Juan Pablo Yamamoto#section6