Los elementos estructurales de HTML (artículo, sección, navegación y aparte) son, a primera vista, algunas de las partes más fáciles de la especificación HTML5 para comprender e implementar. Sin embargo, en realidad son algunas de las partes de HTML5 menos bien especificadas, mal entendidas y mal implementadas.

Creado arbitrariamente intentan introducir una forma completamente nueva de estructurar páginas web; violan los principios de diseño de HTML; perjudican la accesibilidad para algunos usuarios; y no deberías usarlos.

Sí, estoy saliendo disparado contra esta parte específica de HTML5, pero no asuman que soy 'anti-HTML5'. He escrito un libro sobre HTML5 , Amo la web abierta, me encantan los buenos estándares web, y me encanta el hecho de que después de una década de estancamiento, la innovación en las tecnologías web ahora está sucediendo a una velocidad vertiginosa. Eso, sin embargo, no significa que tenemos que aceptar todo lo que recibimos. No tenemos que comer todo en la placa HTML5, incluso si encontramos partes del plato bastante sabrosas. Algunas partes probablemente deban devolverse al chef.

Hay partes buenas y malas de la enorme especificación HTML5, y vamos a pensar críticamente sobre una parte muy específica de la especificación: los elementos seccionales o "estructurales" que introduce HTML5. Así que pongamos nuestros sombreros de detective y veamos de dónde vienen estos nuevos elementos, cómo se supone que deben usarse, y cómo nosotros, la comunidad de diseño web, los hemos malentendido fundamentalmente, básicamente forjando las especificaciones. Vamos a cuestionar la base misma de estos elementos y reventar algunos mitos sobre ellos en el camino.

¿De dónde provienen los elementos estructurales de HTML5?

Echemos un mito que se ha repetido hasta la saciedad sobre estos elementos: la idea de que se basan en la investigación de cómo nosotros, la comunidad web, estábamos marcando nuestros documentos. Es un mito que se ha repetido en libros, blogs y conversaciones desde hace años, y simplemente no es cierto. ¿Cómo puedo saber? Yo pregunté.

Cuando estaba investigando los orígenes de estos elementos, decidí preguntarle al editor de la especificación HTML5, Ian Hickson, de dónde provenían estos elementos. Respondió:

Yo y otros colaboradores de WHATWG [los añadieron], [en] 2004ish, porque eran elementos obvios para agregar después de ver cómo los autores usaban HTML4. Más tarde (fines de 2005 y principios de 2006) hicimos algunas investigaciones objetivas para descubrir cuáles eran las diez mejores clases de HTML y resultó que básicamente coincidían exactamente con los elementos que habíamos agregado, lo que era conveniente.

Analicemos esto: primero, Hickson y los miembros de WHATWG agregaron estos elementos antes de realizar cualquier investigación . Puede sumergirse en los archivos de la lista de correo WHATWG (afortunadamente público) y descubrir las primeras discusiones sobre estos elementos para usted. Por ejemplo, puede ver a Hickson discutiéndolos en noviembre de 2004, con comentarios tales como éste :

Sí, tengo la intención de incluir cosas como [elementos semánticos] en las aplicaciones web. Actualmente, la pizarra de mi oficina tiene una lista de elementos bajo el encabezado "ELEMENTOS DE NIVEL BLOQUE HTML5", y estoy tratando de encontrar la forma de hacer que funcionen bien (los elementos en cuestión se mencionan actualmente en el borrador, pero el borrador no maneja bien los encabezados). Todavía no he visto el marcado en línea, pero eso también está en las cartas.

Es decir, parece que la semántica estructural de HTML5 llegó a ser: un hombre, una pizarra y algunos aportes de otros miembros de WHATWG. (El WHATWG, o Grupo de Trabajo de Tecnología de Aplicación Web de Hipertexto, fue formado por representantes del navegador en respuesta al abandono de HTML del W3C por el ideal utópico de XHTML 2.0).

Los elementos utilizados por millones de documentos que hemos estado discutiendo y debatiendo fueron, al parecer, creados arbitrariamente por capricho del editor HTML5 en 2004. (Y se encontraron con un crítica astuta y algunas predicciones tristemente precisas casi inmediatamente.)

Detrás colectivos

Tantek ha estado insistiendo en la investigación antes de especificar nuevos formatos durante mucho tiempo en el contexto de los microformatos, y finalmente las especificaciones WHATWG se diseñarán de manera similar con datos reales, en lugar de que saquemos cosas de nuestras espaldas colectivas. - Ian Hickson

Eso nos lleva al segundo punto. En diciembre de 2005, más o menos un año después de idear estos nuevos elementos, Hickson (un empleado de Google) realizó una investigación sobre cómo se crearon los documentos utilizando la vasta base de datos documental de Google. La investigación fue 'un análisis de una muestra de poco más de mil millones de documentos, extrayendo información sobre nombres populares de clase, elementos, atributos y metadatos relacionados'. Las identificaciones no se incluyeron en la investigación. Los hallazgos fueron publicados por Google como Estadísticas de autoría web (2005) .

La parte crítica de la investigación, en lo que respecta a los elementos estructurales de HTML, fueron los hallazgos de clases , que, a pesar de usar una muestra donde ~ 900 millones de los mil millones de documentos aparentemente no tenían clases, contenía algunas clases comunes que estoy seguro que todos hemos usado en nuestros proyectos antes: pie de página, menú, título, pequeño, texto , contenido, encabezado, nav, derechos de autor, botón, principal, etc.

Hickson luego da su vuelta a los datos, sugiriendo que estas clases "realmente [mapean] muy bien a los elementos que se están proponiendo en HTML5" y proporciona una tabla que compara los hallazgos de la investigación y los nuevos elementos en HTML5: un pie de página la clase está en la investigación, un elemento de pie de página está en HTML5; una clase de encabezado está en la investigación, un elemento de encabezado está en HTML5; las clases text , content , main , body están en la investigación, y, err ... el artículo está en HTML5 que, como veremos, no coincide en absoluto; sección no se encuentra en absoluto, que también vale la pena señalar.

Tomado al pie de la letra, esto es todo lo suficientemente razonable. Uso el pie de página, usa el pie de página, el pie de página está en HTML5. ¿Cuál es el problema?

El problema es que si lees el verdadero Especificación de HTML5 , los elementos en HTML5 se definen de una manera que tiene poco que ver con la forma tradicional en que los hemos utilizado.

Por un lado, Hickson ha introducido un concepto completamente nuevo de estructuración de una página web en HTML5 con elementos de sección . Por otro lado, Hickson está comparando sus elementos de sección HTML5 con las clases que se usan en la naturaleza, sin entender en qué se usan realmente esas clases. Un ejemplo clásico es 'encabezado', que la mayoría de nosotros usaría para el área en la parte superior de la página, pero la especificación HTML5 sugiere que puede usarlo para el encabezado de cada comentario en una página . De Verdad. El hecho de que las clases en la investigación y los elementos en HTML5 tengan el mismo nombre no significa que sus usos sean los mismos.

Ahora bien, si se comunicara claramente que los nuevos elementos se introdujeron con un nuevo propósito y una lógica clara, entonces eso no sería tan malo. Pero eso no es lo que nos han dicho.

Aquí está Hickson en 2009 , respondiendo a una pregunta sobre el propósito de la sección, navegación, artículo, aparte y otros:

Están, más o menos, llenando las solicitudes más comunes de los desarrolladores web en función de cuáles son los valores de atributo class = "" más comunes. Su objetivo principal es simplificar la creación y el estilo.

Desafortunadamente, este parece ser un caso en el que el editor de HTML5, a pesar de su buen trabajo al juntar las especificaciones, ha olvidado (seamos generosos) por qué agregó estos elementos a lo que es esencialmente su especificación. Tal vez sea la diferencia horaria entre 2009 y 2004, quién sabe. Pero sí sabemos esto: los elementos de seccionamiento de HTML5 no se agregaron para completar 'las solicitudes más comunes de los desarrolladores web'. ¿Como sabemos? Solo podemos mirar la lista y ver que los elementos más fundamentales agregados, como el elemento de sección (y el artículo relacionado y los elementos a un lado), no aparecen en la investigación de atributos de clase común.

Aunque Hickson puede haber olvidado por qué se agregaron estos elementos, todavía podemos leer afortunadamente las especificaciones que documentan su propósito.

Pero, ¿qué sucede cuando le dices a los diseñadores web y desarrolladores que no se preocupen, estos elementos simplemente reemplazan lo que ya estás haciendo y luego especifican estos elementos de una manera que ciertamente no es lo que los diseñadores y desarrolladores web estaban haciendo? Los pones en un viaje de ida a la ciudad de la confusión.

Este es el peor tipo de investigación: una interpretación perezosa de los datos hechos para justificar las decisiones que ya se tomaron. Un principio de diseño muy repetido de HTML5 es ' pavimentar los caminos de los vacas ', es decir' Cuando una práctica ya está muy extendida entre los autores, considere adoptarla en lugar de prohibirla o inventar algo nuevo '. Y así parecería con estos nuevos elementos estructurales: sección, artículo, navegación y aparte (y encabezado y pie de página). ¿De verdad, estos son solo 'pavimentación de los caminos de los vaqueros'?

Esa es la impresión que muchos de nosotros tenemos, ya que eso es lo que nos han dicho que son.

De hecho, hace casi cinco años cuando obtuvimos por primera vez vista previa de HTML5 , parecía que estos elementos podrían simplemente reemplazar los divs 'no semánticos' que estábamos acostumbrados a usar. Lo que era div id = "encabezado" en la parte superior de la página ahora podría convertirse en encabezado ; div id = "footer" ahora podría convertirse en un pie de página , y nuestro div solo podría ser artículo. Simple, ¿verdad?

Bifurcamos la especificación

Desafortunadamente, a pesar de hacer lo que nos dijeron (es decir, simplemente cambiar uno por el otro), en realidad hemos implementado estos elementos de una manera que no se refleja en las especificaciones de HTML5. Es decir, cuando se trata de la estructura HTML5, básicamente hemos bifurcado las especificaciones. Actualmente existen dos métodos de estructura HTML5: la interpretación de la comunidad, que se refleja en el artículo A List Apart de 2007 (y un sinnúmero de otros); y la especificación HTML5 real, que presenta una forma completamente nueva de estructurar una página web llamada delinear.

Esta es la contradicción en el corazón de la semántica estructural de HTML. Por un lado, el editor nos dice que los nuevos elementos se basan en la investigación sobre lo que ya estábamos haciendo y, por lo tanto, están destinados a facilitar un poco la creación; y, por otro lado, tenemos lo que el editor realmente creó en la especificación HTML5, que es una nueva forma de estructurar una página web de una manera que genera un esquema de documento utilizando elementos de sección .

Había una elección clara que hacer aquí. Rompe con los principios de diseño de HTML5 e introduce algo nuevo, o simplemente sigue las prácticas reales de autoría y especifica los elementos de una manera que refleje la práctica del diseño web. Hickson intentó hacer lo primero y lo llamó el último, y ahora tenemos un gran lío en nuestras manos.

¿Hambriento por más? Parte dos de este artículo ahora está disponible y el libro de Luke "The Truth About HTML5" está disponible por tiempo limitado a través de nuestro sitio hermano MightyDeals.com con un asombroso 50% de descuento.

¿Trabajas con elementos estructurales HTML5? ¿Los encuentras útiles o un obstáculo? Háganos saber en los comentarios.

Imagen / miniatura destacada, usos imagen de la estructura a través de Shutterstock.