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

38

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?

html history parsing

— Shubham
fuente

77

Es posible que le resulte interesante el artículo de Joels, Martian Headsets . También es de especial interés el RFC 793: Principio de robustez , que establece explícitamente que las implementaciones de TCP deberían hacer todo lo posible para analizar la basura. Este principio se ha aplicado desde entonces a los navegadores.

— Brian

25

@Brian: la robustez significa que no debes caer cuando recibes basura. No significa que tengas que darle sentido a la basura.

— Marjan Venema

2

XHTML utiliza un análisis estricto.

— user16764

3

¿Soy solo yo, o ninguna de estas respuestas es muy satisfactoria?

— gsingh2011

2

@ gsingh2011 Ninguna de las respuestas es satisfactoria, pero mi respuesta es la verdad. Algunos de nosotros aquí estuvimos activos en la red hace mucho tiempo :-) Pero sí, es sorprendente la cantidad de basura que nos queda por razones tan simples.

— Ross Patterson el

39

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!

— Ross Patterson
fuente

77

+1 sí, así es como empezó todo, en vi o bloc de notas. Con la mayoría de las páginas copiadas del código de ejemplo incorrecto, nunca mejoró. Además, la WWW se disparó, por lo que cualquiera que pudiera escribir se convirtió en desarrollador web y todo se trataba de hacerlo rápidamente.

— jqa

1

Aparentemente, esta respuesta en conjunción con el comentario de @Jukka da la mejor explicación posible

— Shubham

35

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.

— tdammers
fuente

77

Bueno, no creo que nadie sirva HTML que arroje errores. ¿POR QUÉ crees que un compilador suponiendo que el código es diferente de un navegador que asume HTML?

— Shubham

1

Estoy de acuerdo con Shubham aquí: "dado que estamos tratando con aportes de una fuente en la que no tenemos influencia" es falso, la influencia es indirecta, pero algunos sitios web aún admiten IE6 debido a esa influencia.

— Steve314

2

@Shubham: Un compilador es diferente porque su propósito no es transformar el código fuente legible por máquina en una forma digerible por humanos, sino transformar el código fuente legible por humanos en algo que sea más conveniente para una computadora (código máquina o algún intermediario formato). Con el compilador, arreglas la entrada y te alegra que el código no haya llegado a producción. Con el navegador, maldices al creador del navegador o al autor del sitio web, pero de cualquier manera, no puedes ver la página.

— tdammers

2

@Shubham: en general, el usuario de un compilador tendrá control sobre el código fuente que se está compilando. Ese generalmente no es el caso con las páginas web.

— supercat

17

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.

— Jukka K. Korpela
fuente

15

HTML authors and authoring tools produce crappy markup.- Lo hacen porque los navegadores lo aceptan. Si desde el principio los navegadores no lo aceptaran, entonces estas herramientas y autores no habrían podido evitar la producción de marcas

— desagradables

3

@GrandmasterB: creo que se pierde el punto: incluso donde solo había un navegador en el mercado, no hizo un análisis estricto.

— user93353

3

Nota divertida: usted dice que si un navegador no puede analizar un sitio no válido, perderá participación de mercado. Pero solo mire, es decir: por malo que sea, no pierde cuota de mercado. Simplemente obliga a los desarrolladores pobres a escribir trucos sucios al usar API antiguas ... Y no me hagas comenzar con su esquema de versiones ...

— Max

3

Al principio, los navegadores se escribieron a toda prisa para lidiar con un lenguaje de marcado que no estaba finalizado y no tenía una especificación oficial: no había reglas estrictas de análisis. (HTML 2.0, en 1995, estaba nominalmente basado en SGML, pero era demasiado tarde para implementarlo).

— Jukka K. Korpela

2

IE ha perdido bastante de su cuota de mercado. Pero esto probablemente tiene poco que ver con el análisis estricto. IE, con sus rarezas, gobernó la web el tiempo suficiente para obligar a otros navegadores a imitar en gran medida sus rarezas, porque de lo contrario muchas páginas se desmoronarían.

— Jukka K. Korpela

9

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.

— Jessica Brown
fuente

La sintaxis HTML se basó en la sintaxis concreta de referencia de SGML para la forma de su marcado. Pero el SGML en sí mismo no tenía elementos para marcar documentos que HTML pudiera tomar prestados. El conjunto de elementos HTML en realidad se parece al lenguaje de marcado de documentos GML de IBM , transcrito en el SGML RCS.

— Ross Patterson

5

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.

— monstruo de trinquete
fuente

66

Incluso antes de que IE entrara al mercado, Netscape nunca hizo un análisis estricto. Recuerdo Netscape desde principios de 1997.

— user93353

Incluso si hubiera estándares claros, sería difícil para un navegador distinguir entre etiquetas que se definieron legítimamente después del lanzamiento del navegador, frente a etiquetas que nunca han sido y nunca serían legítimas. Si las etiquetas "opcionales" que mejoraban un documento pero no eran necesarias para su corrección semántica incluían el número de versión del estándar que las implementó, entonces un navegador que implementó la versión 23 del estándar podría ignorar silenciosamente una <o24wowzo>etiqueta pero rechazar una <o23wowzo>, pero tal un diseño habría afectado el aspecto "legible para humanos" de HTML.

— supercat

2

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

— Erik Reppen
fuente