HTML es la piedra angular sobre la que descansa toda la biblioteca digital de la civilización humana y, sin embargo, sigue siendo el lenguaje más incomprendido, maltratado y falsamente trivializado de la historia de la informática. En una época en la que cualquier desarrollador moderno descarga alegremente 450 megabytes de dependencias en node_modules, configura cadenas de empaquetado con docenas de capas reactivas y orquesta complejas mutaciones de estado, el documento final emitido al navegador web es, con lamentable frecuencia, una sopa informe de contenedores <div> y <span> pegados con manejadores de eventos en línea.

Escribir HTML riguroso, semántico y accesible no es una cuestión de purismo estético; es pura arquitectura de sistemas. Los navegadores no son lienzos pasivos de dibujo, sino complejísimos motores de compilación equipados con analizadores léxicos de transmisión, autómatas finitos deterministas (DFA), algoritmos de reconstrucción de árbol y sintetizadores del árbol de accesibilidad (AOM). Cuando seleccionas la etiqueta semántica adecuada de entre los 265 elementos estandarizados por el W3C y el WHATWG, activas tres décadas de optimización a bajo nivel en rendimiento de renderizado, navegación ergonómica por teclado, interoperabilidad con lectores de pantalla y relevancia en algoritmos de búsqueda.

La arquitectura del marcado semántico: de Tim Berners-Lee al Living Standard

En 1991, en las instalaciones del laboratorio de física de partículas del CERN en Ginebra, Sir Tim Berners-Lee redactó un humilde documento titulado «HTML Tags». Aquella propuesta original constaba de tan solo 18 elementos estructurales derivados de SGML. La visión de Berners-Lee era eminentemente arquitectónica: concebir un formato hipertextual descentralizado que permitiese a científicos de todo el mundo compartir publicaciones académicas sin preocuparse por la arquitectura del procesador, el sistema operativo, las fuentes instaladas o la resolución de pantalla.

Hacia 1995, Dave Raggett y el IETF presentaron la ambiciosa propuesta de HTML 3.0. Raggett ideó estructuras avanzadas para ecuaciones matemáticas, tablas complejas y distribución de texto continuo alrededor de figuras. No obstante, antes de que los comités pudieran ratificarlo, estalló la feroz guerra de navegadores entre Netscape Navigator y Microsoft Internet Explorer a finales de los noventa. En una desesperada carrera por capturar cuota de mercado, las compañías pisotearon la semántica y comenzaron a inventar etiquetas visuales propietarias: Netscape introdujo el estridente <blink>, mientras que Microsoft contraatacó con el banner deslizante <marquee>, la música de fondo <bgsound> y los bloques invisibles <spacer>.

Al filo del nuevo milenio, el World Wide Web Consortium (W3C) se adentró en un callejón sin salida ideológico conocido como XHTML 2.0. Encerrados en una torre de marfil académica, los miembros del comité dictaminaron que la web debía renunciar a la compatibilidad con versiones anteriores y aplicar una validación XML implacable: cualquier comilla omitida o etiqueta sin cerrar debía paralizar de inmediato el renderizado mediante la infame «Pantalla Amarilla de la Muerte» (Yellow Screen of Death). Dado que la web real es un ecosistema vivo, dinámico y propenso a errores humanos, el mercado comercial rechazó de plano este dogmatismo.

En 2004, ingenieros clave de Apple, Mozilla y Opera se rebelaron abiertamente contra el estancamiento del W3C y fundaron el WHATWG. Su manifiesto era de un pragmatismo demoledor: investigar empíricamente cómo procesaban los navegadores el código real en internet, documentar un algoritmo de análisis tolerante a fallos que jamás colapsara y transformar HTML en un «Living Standard» (Estándar Vivo) en constante evolución. Hoy en día, el WHATWG es la autoridad que rige la especificación oficial de HTML, catalogando 265 etiquetas que abarcan desde el seccionamiento semántico hasta gráficos vectoriales SVG, fórmulas matemáticas en MathML, widgets nativos interactivos y multimedia enriquecida.

Bajo el capó: cómo los motores de los navegadores procesan el DOM y el árbol de renderizado

Para comprender el impacto real de cada etiqueta, es imprescindible descender a las entrañas de motores de renderizado modernos como Blink (Chrome), WebKit (Safari) o Gecko (Firefox) cuando reciben un flujo de bytes a través de la conexión TCP:

• Decodificación de flujo y preanálisis rápido: La capa de red envía fragmentos de bytes crudos al decodificador de texto, que resuelve la codificación de caracteres según los encabezados HTTP o la etiqueta <meta charset="utf-8">. De forma paralela e inmediata, un analizador secundario (Preload Scanner) inspecciona el flujo bruto para comenzar a descargar de fondo recursos críticos como hojas de estilo, fuentes y scripts asíncronos.
• Tokenización mediante autómatas de estado finito: El analizador léxico principal implementa una máquina de estados DFA. Consume carácter por carácter, alternando entre decenas de estados internos (Estado de Datos, Estado de Apertura de Etiqueta, Estado de Atributos) para emitir tokens atómicos: tokens DOCTYPE, tokens de etiqueta de inicio, de cierre, de texto y de comentarios.
• Construcción del árbol y resolución de errores: A diferencia de los motores XML, el algoritmo de construcción del árbol en HTML5 maneja una pila de elementos abiertos y estrictos modos de inserción (como «in body», «in head» o «in table»). Ante sintaxis rota o indebidamente anidada (como <p>Texto <div>Bloque</div></p>), el motor ejecuta automáticamente el célebre Adoption Agency Algorithm (AAA) para reorganizar y cerrar elementos de formato en la pila sin romper la ejecución de la página.
• Fusión de DOM y CSSOM en el Render Tree: El Document Object Model (DOM) se construye en memoria como una estructura en árbol en C++. Simultáneamente, los estilos se procesan en el CSSOM. El motor cruza ambas estructuras para generar el Render Tree, descartando nodos que no producen salida visual (como <head>, <script> o cajas con display: none).
• Disposición (Reflow), pintado y composición: El motor recorre el Render Tree calculando las coordenadas geométricas exactas y dimensiones de cada caja en píxeles de pantalla (Reflow). A continuación, el proceso de pintado (Paint) rasteriza líneas, colores y texto en mapas de bits distribuidos en capas aceleradas por GPU. Por último, el compositor envía las capas a la pantalla. Introducir etiquetas erróneas que fuercen mutaciones imprevisibles del DOM desencadena constantes reflows globales que disparan el consumo de CPU y provocan tirones en la interfaz.

Los pecados del desarrollo web moderno: «Div-Soup», abuso de etiquetas y crímenes contra la accesibilidad

El vicio más destructivo en la ingeniería de software actual es la «Div-Soup» o sopa de divs: la perversa costumbre de maquetar interfaces complejas recurriendo exclusivamente a cajas mudas <div> y <span>. El ejemplo paradigmático de este despropósito es el botón falso: <div class="boton" onclick="enviarFormulario()">Enviar</div>.

Al implementar ese elemento como un simple <div> en vez de utilizar el botón nativo <button>, el desarrollador desecha décadas de ingeniería de accesibilidad. Un div carece de semántica implícita: es inaccesible mediante la tecla Tabulador, no responde a las pulsaciones de Enter o Barra espaciadora, no envía formularios de manera nativa, no transmite el estado disabled a lectores de pantalla y resulta invisible para el software de navegación por voz. Para emular el comportamiento que un <button> ofrece de forma gratuita desde 1995, el programador debe redactar decenas de líneas de JavaScript: añadir tabindex="0", escuchar eventos de teclado, gestionar aria-disabled y simular estilos de foco. Es un esfuerzo absurdo que solo genera fragilidad y deuda técnica.

De igual gravedad es la destrucción de la jerarquía de encabezados. Cuando se coloca un <h4> justo después de un <h1> únicamente porque el tamaño visual de la letra encaja en el diseño, se sabotea la orientación de las personas con discapacidad visual. Los usuarios de lectores de pantalla navegan mediante teclas rápidas de encabezado («H» o números del 1 al 6) para explorar mentalmente el esquema de la página. El tamaño visual debe gestionarse con CSS; HTML debe reservar sus etiquetas para representar la estructura lógica.

Asimismo, los rastreadores de motores de búsqueda como Googlebot utilizan el seccionamiento semántico (<main>, <article>, <nav>, <aside>, <header>, <footer>) para distinguir el contenido editorial sustantivo de la navegación y el pie de página. Si una web es un mar indiferenciado de divs, los motores se ven forzados a usar heurísticas de descarte, lo que penaliza la relevancia algorítmica y la obtención de fragmentos enriquecidos en los resultados de búsqueda.

Accesibilidad W3C, el árbol ARIA y las especificaciones Living Standard

De forma paralela a la estructura del DOM, el navegador construye en tiempo real una segunda jerarquía de datos: el Árbol de Accesibilidad (AOM). A través de las API nativas del sistema operativo (UI Automation en Windows, NSAccessibility en macOS o AT-SPI en Linux), este árbol se comunica con herramientas de asistencia como NVDA, JAWS o VoiceOver.

Cada elemento semántico de HTML5 incorpora de serie roles, estados y propiedades del estándar W3C ARIA:

• <nav> expone de manera automática el punto de referencia role="navigation".
• <main> declara inequívocamente el bloque central con role="main".
• <dialog>, al invocarse con showModal(), confina de forma automática el foco dentro de la ventana, atenúa el fondo con ::backdrop y responde de forma nativa a la tecla Escape.
• <details> y <summary> crean un panel desplegable nativo con soporte de teclado y alternancia de aria-expanded sin requerir una sola línea de JavaScript.
• <progress> y <meter> transmiten valores cuantitativos accesibles sin depender de animaciones complejas en canvas.

La primera regla de oro de ARIA estipula categóricamente: «Si puedes usar un elemento o atributo HTML nativo que ya cuente con la semántica y el comportamiento requeridos, hazlo en lugar de parchear un elemento genérico añadiendo roles y propiedades ARIA artificiales.» ARIA es un mecanismo de ajuste complementario, no una excusa para descuidar el marcado estructural.

El cementerio digital: por qué Marquee, Blink y Center fueron enterrados

El estándar HTML5 formalizó la obsolescencia y retirada definitiva de decenas de elementos arcaicos procedentes de los albores de internet. Comprender por qué se descartaron estas etiquetas arroja luz sobre los principios de diseño de la web moderna:

• Separación de responsabilidades: Etiquetas como <center>, <font>, <big> y <strike> mezclaban la apariencia visual con la estructura lógica. Con la madurez de CSS mediante Flexbox y Grid, incrustar formatos fijos en HTML se convirtió en una trampa que impedía el diseño web adaptable a móviles.
• Rendimiento de hardware y accesibilidad: La célebre etiqueta <marquee> forzaba un bucle ininterrumpido de repintado en el hilo principal del navegador, devorando recursos en los primeros procesadores de telefonía móvil. Peor aún: el texto en movimiento constante supone una barrera insalvable para personas con déficit de atención o visión reducida que no pueden pausar el desplazamiento.
• Rotura de la arquitectura hipertextual: Los marcos <frameset> y <frame> fracturaron el pilar básico de la web: el enlace URL único. Un usuario podía navegar por tres marcos distintos mientras la barra de direcciones del navegador permanecía estática, imposibilitando guardar marcadores, compartir enlaces o utilizar el botón de retroceso.
• Vulnerabilidades de seguridad: Antiguos contenedores de complementos como <applet> (Java) o <keygen> abrían brechas directas de seguridad en el sistema del cliente. Los estándares actuales los sustituyeron por soluciones aisladas como <iframe sandbox>, WebAssembly y las API nativas de criptografía web.

Al dominar el repertorio completo de 265 etiquetas HTML, SVG y MathML recogidas en esta guía, asimilas el vocabulario técnico imprescindible para construir plataformas web ultrarrápidas, robustas y plenamente accesibles para cualquier persona en el mundo.