Sopa de etiquetas

En el desarrollo web , " sopa de etiquetas " es un término peyorativo para referirse al código HTML escrito para una página web que es sintáctica o estructuralmente incorrecto. Históricamente, los navegadores web han tratado los errores estructurales o de sintaxis en HTML con indulgencia, por lo que ha habido poca presión para que los desarrolladores web sigan los estándares publicados. Por lo tanto, existe la necesidad de que todas las implementaciones de navegadores proporcionen mecanismos para lidiar con la aparición de "sopa de etiquetas", aceptando y corrigiendo la sintaxis y la estructura no válidas siempre que sea posible.

Un analizador de HTML (parte de un navegador web) que es capaz de interpretar un marcado similar al HTML incluso si contiene una sintaxis o estructura no válidas puede denominarse analizador de sopa de etiquetas . Todos los navegadores web principales tienen actualmente un analizador de sopa de etiquetas para interpretar HTML mal formado, con la mayoría de los elementos de manejo de errores estandarizados.

La "sopa de etiquetas" abarca muchos errores de creación comunes, como etiquetas HTML mal formadas , elementos HTML anidados incorrectamente y entidades de caracteres sin escape (especialmente símbolos & y menores (<)).

He utilizado este término en mis clases durante años para caracterizar el conjunto de corchetes angulares que actúan como etiquetas en HTML en páginas que son aceptadas por los navegadores. Minimización incorrecta, construcciones superpuestas... cosas que parecen marcas SGML pero cuyo creador no conocía o no respetaba las reglas SGML para el vocabulario HTML. En efecto, una colección confusa de texto y marcas. [...] Nunca he visto el término definido en ninguna parte.

—  G. Ken Holman, Re: [xml-dev] ¿Qué es Tag Soup?, lista de correo de desarrollo XML, 11 de octubre de 2002.

El Servicio de Validación de Marcado es un recurso para que los autores de páginas web eviten crear una sopa de etiquetas.

"Sopa de etiquetas" es un término que se utiliza para denigrar diversas prácticas en la creación de páginas web. Algunas de ellas (ordenadas aproximadamente de la más grave a la menos grave) son:

1. Marcado mal formado en el que las etiquetas están anidadas o cerradas incorrectamente. Por ejemplo, lo siguiente:

   < p > Este es un fragmento mal formado de < em > HTML. </ p > / em >
   

2. Estructura no válida en la que los elementos están anidados incorrectamente según la DTD del documento. Algunos ejemplos de esto incluyen anidar un elemento "ul" directamente dentro de otro elemento "ul" para cualquiera de las DTD de HTML 4.01 o XHTML. Dan Connolly cita el uso del elemento title fuera de la sección de encabezado . ^[1]
3. Uso de elementos y atributos propietarios o no definidos en lugar de los definidos en las recomendaciones del W3C. Por ejemplo, el uso del elemento Blink o del elemento Marquee , que eran elementos no estándar que originalmente sólo eran compatibles con los navegadores Netscape e Internet Explorer respectivamente.

El marcado malformado es posiblemente el problema más grave en la creación de páginas web. Sin embargo, gracias a una mejor educación e información y quizás con alguna ayuda de XHTML, el problema del marcado malformado se está volviendo menos común. Los navegadores, cuando se enfrentan a un marcado malformado, deben adivinar el significado pretendido por el autor. Deben inferir las etiquetas de cierre donde esperan que estén y luego inferir las etiquetas de apertura para que coincidan con otras etiquetas de cierre. La interpretación puede variar notablemente de un navegador a otro. ^[2]

Si bien muchos editores gráficos web producen un marcado bien formado, un autor que escribe código manualmente con un editor de texto y luego prueba solo en un navegador puede pasar por alto fácilmente esos errores. Por lo tanto, la presentación puede variar drásticamente de un navegador a otro, ya que cada uno intenta "corregir" la intención del autor de diferentes maneras y luego aplica estilos a esas "correcciones".

En este caso, la estructura de documento no válida solo se refiere al uso de atributos y elementos en lugares donde no pertenecen. Por ejemplo, colocar un atributo "cite" en un elemento "cite" no es válido, ya que las DTD de HTML y XHTML no atribuyen ningún significado a ese atributo en ese elemento. De manera similar, incluir un elemento "p" dentro del contenido de un elemento "em" tampoco es válido. Con el avance hacia la separación del marcado mal formado del marcado no válido, los problemas con el marcado no válido se han visto cada vez más como menos graves. Algunos han comenzado a abogar por modelos de contenido más flexibles que permitan una mayor flexibilidad en la creación de documentos HTML (ya sea en HTML o XHTML). Sin embargo, el uso de marcado no válido puede desdibujar el significado pretendido por el autor, aunque no tan gravemente como el marcado mal formado.

Muchos editores de páginas web gráficas siguen produciendo un marcado no válido. Además, muchos diseñadores y autores web profesionales prestan poca atención a las cuestiones de validez. Es habitual ver marcado no válido en muchos de los sitios de la World Wide Web.

En los primeros tiempos de la web (gran parte de la década de 1990), el diseño de la especificación oficial de HTML se volvió cada vez más exigente, en comparación con el deseo de los diseñadores de tener flexibilidad para crear diseños visualmente vibrantes. En respuesta a esta presión, los fabricantes de navegadores agregaron unilateralmente nuevas características propietarias a HTML que no se ajustaban a los estándares de la época. Esto significó que había elementos propietarios en HTML que funcionaban en algunos navegadores, pero no en otros.

Hasta cierto punto, este problema se vio frenado por la introducción de nuevos estándares por parte del W3C, como CSS, introducido en 1998, que ayudó a proporcionar una mayor flexibilidad en la presentación y el diseño de las páginas web sin necesidad de grandes cantidades de elementos y atributos HTML adicionales.

Además, en HTML 4 y XHTML 1, muchos elementos fueron reemplazados por una única construcción semántica (como elementos de objeto que reemplazaron elementos propietarios de subprogramas e incrustaciones ) o quedaron obsoletos debido a que eran de presentación (como los elementos "s", "strike" y "u").

Sin embargo, los desarrolladores de navegadores siguieron introduciendo nuevos elementos en HTML cuando percibieron la necesidad. Algunos navegadores incluyeron atributos tabindex en cualquier elemento. Los desarrolladores de WebKit de Apple introdujeron el elemento canvas , una versión del cual fue posteriormente adoptada por Mozilla .

En 2004, Apple, Mozilla y Opera fundaron el WHATWG con la intención de crear una nueva versión de la especificación HTML que fuera compatible con todo el comportamiento de los navegadores. Esto incluía cambiar la especificación, si era necesario, para que coincidiera con un consenso existente entre los distintos navegadores. ^[3]

Los elementos canvas ^[4] e incrustar ^{[5] fueron estandarizados posteriormente por el WHATWG. Se incluyeron ciertos elementos (incluidos} b , i y small ) que anteriormente se consideraban de presentación y estaban en desuso, pero se definieron de una manera independiente del medio en lugar de visual. ^[6]

El W3C publicó versiones de la especificación WHATWG como HTML5 . ^[3]

Si bien algunos de los problemas de la sopa de etiquetas se deben a deficiencias de los navegadores y, en ocasiones, a la falta de información para los autores de páginas web, parte de la proliferación de la sopa de etiquetas se debió a la falta de enlaces en los propios estándares web. El W3C ha encabezado varias iniciativas para abordar las deficiencias de los estándares web. A medida que más navegadores admiten nuevas revisiones de los estándares, disminuye la presión sobre los desarrolladores web para utilizar código no estándar para resolver los problemas.

Las hojas de estilo en cascada (CSS) proporcionan un mecanismo para especificar la presentación de los elementos de un documento sin alterar la estructura de marcado del documento. Antes de que las CSS fueran algo común, los desarrolladores web podían recurrir a algún marcado estructuralmente no válido para lograr ciertos objetivos de presentación; por ejemplo, incluir elementos de nivel de bloque dentro de elementos en línea para obtener un efecto particular o usar a veces una gran cantidad de <font>etiquetas HTML específicas para la visualización. Las CSS utilizan reglas de estilo para llevar a cabo estas tareas, dejando el marcado más limpio y simple.

XHTML es una reformulación del lenguaje HTML basada en XML . XHTML fue desarrollado para solucionar muchos de los problemas asociados con la sopa de etiquetas.

XML permite a los analizadores separar el proceso de interpretación de la sintaxis del documento y su estructura. En HTML y SGML , un analizador necesitaba conocer ciertas reglas sobre los elementos durante el análisis, como qué elementos podían estar contenidos dentro de otros elementos y qué elementos cerraban implícitamente el elemento anterior. Esto se debe a que en HTML y SGML, las etiquetas de cierre e incluso las etiquetas de apertura eran opcionales en algunos elementos. Al requerir que todos los elementos tengan etiquetas de apertura y cierre explícitas, los analizadores XML pueden analizar el documento y producir un árbol de documento sin ningún conocimiento del tipo de documento. Esto permite que los analizadores sean universales y muy livianos, y que estén separados del proceso de validación o interpretación del documento.

La especificación XML define claramente que un agente de usuario conforme (como un navegador web) no debe aceptar un documento y no continuar analizándolo si encuentra algún error sintáctico. Por lo tanto, un navegador que interprete una página web como XHTML se negará a mostrar la página si encuentra un error de formato. Esto puede ayudar a garantizar que cuando los autores prueben el código XHTML en un navegador conforme, se les informará inmediatamente de los problemas de formato: tal vez el problema más grave al que se enfrentan los navegadores web. Cuando el código está mal formado, la intención del autor es ambigua. Sin las directivas de XML, los navegadores HTML deben utilizar algoritmos complejos para inferir el significado pretendido por el autor en una amplia gama de casos en los que se encuentra una sintaxis no válida.

XML y XHTML introducen el concepto de espacios de nombres. Con los espacios de nombres, los autores o las comunidades de autores pueden definir nuevos elementos y atributos con una nueva semántica y entremezclarlos en sus documentos XHTML. Los espacios de nombres garantizan que los nombres de los elementos de los distintos espacios de nombres no se fusionen. Por ejemplo, un elemento "table" podría definirse en un nuevo espacio de nombres con una nueva semántica diferente a la del elemento "table" de HTML y el navegador podrá diferenciar entre los dos. Al proporcionar espacios de nombres, XHTML combinado con CSS permite a las comunidades de autores ampliar fácilmente el vocabulario semántico de los documentos. Esto permite el uso de elementos propietarios siempre que esos elementos puedan presentarse a la audiencia a la que van dirigidos mediante definiciones completas de hojas de estilo (incluidos estilos auditivos/de voz y táctiles).

Los documentos XHTML se pueden mostrar en la Web mediante el tipo de medio Internet application/xhtml+xml o text/html^[7] Las versiones de Microsoft Internet Explorer anteriores a la 9 no muestran documentos XHTML mostrados como application/xhtml+xml. IE9 y versiones posteriores son compatibles. Consulte también la discusión de este tema en el artículo XHTML .

HTML5 pretende ser la solución más completa hasta el momento al problema de la sopa de etiquetas, manteniendo al mismo tiempo la máxima compatibilidad posible con versiones anteriores y posteriores. A diferencia de XHTML, que se aparta de la compatibilidad con versiones anteriores y adopta el enfoque de que los analizadores deberían ser menos tolerantes con el marcado mal formado, HTML5 reconoce que ya existe código HTML mal formado en grandes cantidades y probablemente seguirá utilizándose, y considera que la especificación debería ampliarse para garantizar la máxima compatibilidad con dicho código.

Por lo tanto, la especificación HTML 5 ha modificado su definición de sintaxis HTML tanto para adaptarse a la sintaxis común que se utiliza hoy en día como para describir explícitamente exactamente cómo debe tratar el analizador el "código mal formado". El manejo del código mal formado ahora tiene un lugar en la propia especificación, lo que se espera que reduzca la necesidad de que los futuros analizadores HTML implementen medidas adicionales fuera de la especificación para tratar el código que no reconoce.

Existen muchas herramientas de software que pueden analizar e intentar corregir el marcado mal formado, entre otras funciones.

• HTML Tidy es una herramienta de software disponible para muchas plataformas que puede corregir la sintaxis no válida y la mayoría de las estructuras de documentos no válidas, convirtiendo código tipo HTML a HTML o XHTML.
• Aggiorno es un complemento de Visual Studio que se centra en hacer que los sitios web cumplan con los estándares.
• TagSoup es una biblioteca Java que analiza HTML, lo limpia y entrega un flujo de eventos SAX que representan XML bien formado (no necesariamente XHTML válido). Esta herramienta se utiliza para procesar archivos JNLP en la implementación de código abierto del protocolo JNLP disponible en IcedTea-Web , un subproyecto de IcedTea , el proyecto de compilación e integración de OpenJDK .
• Beautiful Soup es un analizador similar a DOM de Python para HTML/XML que puede manejar marcado malformado. ^[8]
• tagsoup: una biblioteca para el lenguaje Haskell .

A diferencia del XHTML estricto, HTML y su predecesor SGML están diseñados para ser escritos por humanos y ya tienen un grado significativo de flexibilidad en la sintaxis para reducir el código repetitivo. Estas diferencias no invalidan el documento y, por lo tanto, no son una sopa de etiquetas. Lo siguiente se aplica tanto a HTML 4 como a HTML5, ^[9] y los ejemplos datan de los primeros días de HTML. ^[10]

• Etiquetas como <head>...</head>a menudo se pueden omitir por completo.
• El cierre de etiquetas se puede omitir a menudo porque la especificación rechaza que algunos elementos se aniden en sí mismos. Por ejemplo, <li>...</li>se pueden escribir varios elementos sin cerrar.

A pesar de su validez, estas omisiones aún requieren un analizador especial con conocimientos de HTML (a diferencia del XML más rígido) para analizarlas. Además, es común que las herramientas también "corrijan" estas estructuras. Por ejemplo, HTML Tidy permite omitir etiquetas opcionales, pero por defecto no lo hace. ^[11]

• Marcado superpuesto
• Modo peculiaridades

• G. Ken Holman. Re: [xml-dev] ¿Qué es Tag Soup?, lista de correo de desarrollo XML, 11 de octubre de 2002. Mensaje archivado disponible en línea.
• "sopa de etiquetas". Definitions.net. STANDS4 LLC, 2013. Web. 19 de noviembre de 2013. sopa.