¿Por qué no se eligió el análisis estricto para HTML?

A menudo me he preguntado por qué no se eligió el análisis estricto al crear HTML. Durante la mayor parte del historial de Internet, los navegadores han aceptado cualquier tipo de marcado y han hecho todo lo posible para analizarlo. El proceso degrada el rendimiento, permite a las personas escribir galimatías y dificulta la interrupción de funciones obsoletas.

¿Hay alguna razón específica por la que HTML no se analiza estrictamente?

La razón es simple: en el momento de los primeros navegadores gráficos, NCSA Mosiac y más tarde Netscape Navigator, casi todo el HTML estaba escrito a mano. Los autores del navegador (Netscape fue construido por personas ex mosaicas) reconocieron rápidamente que los usuarios se negarían a procesar HTML incorrecto, ¡y listo!

Porque hacer las mejores conjeturas es lo correcto, desde la perspectiva de un creador de navegadores. Considere la situación: idealmente, el HTML que recibe es completamente correcto y de acuerdo con las especificaciones. Eso es genial. Pero la parte interesante es lo que sucede cuando el HTML no es correcto; Dado que estamos tratando con aportes de una fuente en la que no tenemos influencia, realmente, tenemos que estar preparados para esto. Ahora, cuando eso sucede, ¿qué podemos hacer? Tenemos dos opciones: a) fallar yb) hacer el mejor esfuerzo para recuperarse del error. Si fallamos, el usuario no tiene más que un mensaje de error inútil, y no hay nada que pueda hacer al respecto, porque no controla el servidor. Si hacemos un gran esfuerzo, el usuario tiene al menos lo que podríamos hacer con la página, y a menudo la suposición es correcta.

El único problema real con esto es cuando necesita los mensajes de error, que generalmente se encuentra en una situación de desarrollo: desea asegurarse de que el HTML que genera es correcto y que "funciona en el navegador X" no es equivalente a "correcto", no podemos simplemente ejecutarlo a través de un navegador y ver si funciona: no podemos distinguir entre el HTML correcto y el HTML incorrecto que el navegador ha arreglado para usted. Sin embargo, este es un problema solucionable; hay complementos de navegador que informan violaciones de estándares, está el validador W3C y muchas otras herramientas similares.

Los autores HTML y las herramientas de creación producen un marcado deficiente. Los navegadores hacen lo mejor que pueden por razones competitivas: los navegadores que no muestren la mayoría de las páginas web de manera razonable serán rechazados por los usuarios, a quienes no les importará en lo más mínimo de quién es la culpa.

Es bastante diferente de lo que hacen las implementaciones de lenguaje de programación. Los compiladores e intérpretes trabajan en código que puede suponerse que está escrito por un programador, mientras que todos y su hermano pueden escribir HTML con un entrenamiento mínimo o sin él. El marcado HTML es código, en cierto sentido, pero son datos en lugar de instrucciones de lenguaje de programación, y la (buena) tradición en el software es ser tolerante con los datos.

XHTML, en principio, impone reglas de análisis estrictas (XML), de modo que un documento XHTML servido con un tipo de contenido XML se mostrará solo si está bien formado en el sentido XML; de lo contrario, solo el primer error se comunica al usuario. Esto nunca se hizo popular en la creación web: casi todo el "XHTML" se sirve como texto / html y se procesa como sopa de etiqueta tradicional de una manera muy liberal, solo con algunas nuevas excentricidades.

En resumen, HTML se basó en otro lenguaje de marcado no hipervinculado llamado SGML que se usa a menudo para documentación y manuales y similares.

De un artículo sobre la historia de HTML:

Tim había mencionado que algunos de los documentos HTML principios se basaban en un viejo lenguaje SGML que el CERN ya estaba utilizando: - Hemos incluido en HTML algunas etiquetas del conjunto de etiquetas SGML utilizados en el apoyo y una vez en el CERN [...] El analizador HTML ignorará las etiquetas que no entienda e ignorará los atributos que no entienda de las etiquetas CERN-SGML .

[...] la mayoría de las primeras etiquetas HTML fueron tomadas del lenguaje CERN SGMLGuid, que era una variante de AAP (un lenguaje SGML temprano). Por ejemplo, el título, hn, p, ol, etc., aparentemente están tomados de este lenguaje. El único cambio radical fue la adición del enlace anchor () importante, sin el cual la WWW no habría despegado.

Tomando nota de la parte en negrita, básicamente, implementaron un subconjunto de las etiquetas disponibles en el sistema SGML con el que estaban familiarizados, agregando la nueva etiqueta de anclaje <a> y eligiendo ignorar cualquiera de las muchas etiquetas que no tenían No importa o desea apoyar por cualquier motivo (como etiquetas para listas de bibliografía, xmp para "ejemplo", etiqueta "cuadro" para dibujar un cuadro alrededor de un bloque de texto, etc.). Entonces, la forma más sencilla de hacerlo es perdonar el marcado que el analizador no conoce e ignorar el marcado desconocido lo mejor posible, independientemente de si la causa es un marcado incorrecto escrito por el usuario o la forma más rápida y fácil de convertir documentos existentes a Este nuevo formato HTML es para agregar algunos hipervínculos a los documentos SGML existentes e ignorar las etiquetas que no sean compatibles o implementadas.

Esto es parcialmente un remanente histórico de la guerra del navegador

IE y netscape estaban compitiendo para hacerse cargo del mercado y seguían lanzando nuevas funciones que se volvían cada vez más "impresionantes", y se vieron obligados a aceptar las páginas diseñadas para el otro navegador.

Esto significa que el navegador acepta e ignora las etiquetas desconocidas en silencio, después de que los comités comenzaron a involucrarse ... bueno, usted tiene un comité que diseña cosas y, como resultado, muchas versiones diferentes (con algunas especificaciones redactadas de forma ambigua) donde el navegador desea admitir la mayoría de ellos, y crear un analizador separado para cada versión sería una gran hinchazón. Por lo tanto, es (relativamente) más fácil usar un solo analizador con diferentes modos.

Por otra parte, netscape e IE querían que html fuera accesible para el hombre común (como era la moda en aquellos días), lo que significa tratar de hacer lo que el usuario quería hacer en lugar de lo que dijo hacer y tropezar con cada etiqueta colgante.

Para empeorar el problema, también hay varios sitios "tutoriales" que enseñan lo incorrecto y piensan que tienen razón porque lo que enseñan funciona.

En última instancia, esto significa que si ahora crea un navegador con solo un estricto análisis html, el 99% de los sitios simplemente no funcionarán.

Bueno, intentamos establecer una buena opción estricta en los años 000, pero no funcionó porque las personas que seguían las "mejores prácticas" ciegamente, culpaban a los navegadores cuando su marcado incorrecto se desmoronaba en modo estricto. Y a los vendedores de navegadores no les gustaba ser culpados.

Afirmaron que era porque querían que la web fuera más accesible para los no profesionales, pero a nadie se le impedía usar HTML 4 en su forma más indulgente.

Dicho esto, aún puede servir HTML5 como XML si desea un diseño de estilo estricto. En mi opinión, puede ser una buena manera de aprovechar los beneficios de hacer el diseño o el trabajo de la interfaz de usuario en un modo más estricto antes de pasarlo a otras personas que pueden o no querer que sea estricto sin ningún riesgo real (excluyendo que rompan el doctype porque en realidad favorecen el modo peculiaridades: en 2017 (el momento de esta edición) deberían ser filmados. Así que básicamente sigue ahí, pero investiga un poco. Parece recordar que hubo algunas advertencias que no teníamos con XHTML que no realmente impactan en el trabajo de diseño. Simplemente no corras la voz de que es "la única forma de hacerlo bien" o las personas que compran en ese tipo de charla acumularán la idea, culparán a los navegadores nuevamente y se llevarán los dientes fuera de la única alternativa estricta que nos queda (edición de 2017:

http://mathiasbynens.be/notes/xhtml5