Warum wurde striktes Parsen nicht für HTML gewählt?

38

Ich habe mich oft gefragt, warum beim Erstellen von HTML kein striktes Parsen gewählt wurde. Während des größten Teils der Internetgeschichte haben Browser jede Art von Markup akzeptiert und ihr Bestes versucht, um es zu analysieren. Der Prozess verschlechtert die Leistung, ermöglicht es Benutzern, Kauderwelsch zu schreiben, und erschwert die Einstellung veralteter Funktionen.

Gibt es einen bestimmten Grund, warum HTML nicht streng analysiert wird?

html history parsing

— Shubham
quelle

7

Vielleicht interessieren Sie Joels Artikel, Martian Headsets . Besonders hervorzuheben ist auch RFC 793: Robustness Principle , das ausdrücklich festlegt, dass TCP-Implementierungen ihr Bestes geben sollten, um Müll zu analysieren. Dieses Prinzip wurde seitdem auf Browser angewendet.

— Brian,

25

@ Brian: Robustheit bedeutet, dass Sie nicht umfallen sollten, wenn Sie Mist erhalten. Es bedeutet nicht, dass man Mist verstehen muss.

— Marjan Venema

2

XHTML verwendet striktes Parsen.

— user16764

3

Bin ich es nur, oder ist keine dieser Antworten sehr befriedigend?

— gsingh2011

2

@ gsingh2011 Keine der Antworten ist zufriedenstellend, aber meine Antwort ist die Wahrheit. Einige von uns hier waren schon vor langer Zeit im Netz aktiv :-) Aber ja, es ist erstaunlich, wie viel Müll wir aus so einfachen Gründen übrig haben.

— Ross Patterson

39

Der Grund ist einfach: Zum Zeitpunkt der ersten grafischen Browser, NCSA Mosiac und später Netscape Navigator, wurde fast alles HTML von Hand geschrieben. Die Browser-Autoren (Netscape wurde von Ex-Mosaic-Leuten entwickelt) erkannten schnell, dass die Benutzer sich weigern würden, falsches HTML zu rendern, und voila!

— Ross Patterson
quelle

7

+1 ja, so hat alles angefangen, in vi oder im notizblock. Da die meisten Seiten aus schlechtem Beispielcode kopiert wurden, wurde es nie besser. Außerdem boomte das WWW, und jeder, der etwas schreiben konnte, wurde Webentwickler, und es ging darum, schnell damit fertig zu werden.

— JQA

1

Anscheinend ist diese Antwort in Verbindung mit @

— Jukkas

35

Aus der Sicht eines Browsers ist es das Richtige, die besten Vermutungen anzustellen. Berücksichtigen Sie die Situation: Im Idealfall ist der HTML-Code, den Sie erhalten, vollständig korrekt und entspricht den Spezifikationen. Das ist großartig. Der interessante Teil ist jedoch, was passiert, wenn der HTML-Code nicht korrekt ist. da es sich um eine quelle handelt, auf die wir keinen einfluss haben, müssen wir darauf vorbereitet sein. Was können wir tun, wenn das passiert? Wir haben zwei Möglichkeiten: a) Scheitern und b) Bemühen Sie sich, den Fehler zu beheben. Wenn dies fehlschlägt, hat der Benutzer nur eine unnütze Fehlermeldung und kann nichts dagegen tun, da er den Server nicht kontrolliert. Wenn wir uns nach besten Kräften bemühen, hat der Benutzer zumindest das, was wir aus der Seite machen können, und oft ist die Vermutung meistens richtig.

Das einzige wirkliche Problem dabei ist, dass Sie die Fehlermeldungen benötigen , die normalerweise in einer Entwicklungssituation auftreten. Sie möchten sicherstellen, dass der von Ihnen generierte HTML-Code korrekt ist. Wir können es nicht einfach über einen Browser ausführen und prüfen, ob es funktioniert. Wir können nicht den Unterschied zwischen korrektem HTML und falschem HTML feststellen, den der Browser für Sie behoben hat. Dies ist jedoch ein lösbares Problem. Es gibt Browser-Plugins, die Verstöße gegen Standards melden, den W3C-Validator und viele andere ähnliche Tools.

— tdammers
quelle

7

Nun, ich glaube nicht, dass irgendjemand HTML bereitstellen würde, das Fehler auslöst. WARUM glaubst du, dass ein Compiler davon ausgeht, dass sich Code von einem Browser unterscheidet, der HTML voraussetzt?

— Shubham

1

Ich stimme Shubham hier zu: "Da wir es mit Eingaben von einer Quelle zu tun haben, auf die wir keinen Einfluss haben", ist der Einfluss falsch, aber einige Websites unterstützen aufgrund dieses Einflusses immer noch IE6.

— Steve314

2

@Shubham: Ein Compiler ist anders, weil er nicht dazu dient, maschinenlesbaren Quellcode in eine vom Menschen verdauliche Form umzuwandeln, sondern den vom Menschen lesbaren Quellcode in etwas, das für einen Computer bequemer ist (Maschinencode oder ein Zwischenprodukt) Format). Mit dem Compiler korrigieren Sie die Eingabe und sind froh, dass der Code nicht in die Produktion gelangt ist. Mit dem Browser verfluchen Sie den Browserhersteller oder den Autor der Website, aber so oder so können Sie die Seite nicht sehen.

— tdammers

2

@Shubham: Im Allgemeinen hat der Benutzer eines Compilers die Kontrolle über den zu kompilierenden Quellcode. Dies ist bei Webseiten in der Regel nicht der Fall.

— Supercat

17

HTML-Autoren und Authoring-Tools erzeugen beschissene Markups. Browser geben aus Wettbewerbsgründen ihr Bestes: Ein Browser, der die meisten Webseiten nicht in angemessener Weise rendert, wird von Benutzern abgelehnt, denen es egal ist, an wem er schuld ist.

Es ist ziemlich anders als bei Implementierungen von Programmiersprachen. Compiler und Interpreter arbeiten mit Code, von dem angenommen werden kann, dass er von einem Programmierer geschrieben wurde, während jeder und sein Bruder mit minimalem Schulungsaufwand HTML schreiben können oder ohne. HTML-Markup ist in gewissem Sinne Code, aber es sind eher Daten als Anweisungen für Programmiersprachen, und die (gute) Tradition in der Software besteht darin, mit Daten tolerant zu sein.

Bei XHTML gelten grundsätzlich strenge (XML-) Parsing-Regeln, sodass ein mit einem XML-Inhaltstyp bereitgestelltes XHTML-Dokument nur angezeigt wird, wenn es im XML-Sinne wohlgeformt ist. Andernfalls wird dem Benutzer nur der erste Fehler mitgeteilt. Dies wurde im Web-Authoring nie populär - fast das gesamte „XHTML“ wird als Text / HTML-Code ausgegeben und als traditionelle Tag-Suppe auf sehr liberale Weise verarbeitet, nur mit einigen neuen Exzentrizitäten.

— Jukka K. Korpela
quelle

15

HTML authors and authoring tools produce crappy markup.- Sie tun, weil Browser es akzeptieren. Wenn Browser es von Anfang an nicht akzeptiert hätten - dann wären diese Tools und Autoren nicht in der Lage gewesen, beschissene

— Markups zu erstellen

3

@GrandmasterB - Ich denke, Sie verpassen den Punkt - Auch wenn es nur einen Browser auf dem Markt gab - es wurde kein striktes Parsen durchgeführt.

— User93353

3

Lustiger Hinweis: Sie sagen, dass ein Browser, der eine ungültige Site nicht analysieren kann, Marktanteile verliert. Aber schauen Sie sich an, wie schlecht es auch sein mag, es verliert keine Marktanteile. Es zwingt nur arme Entwickler dazu, unsaubere Hacks mit alten APIs zu schreiben ... Und lass mich nicht mit dem Versionsschema anfangen ...

— Max

3

Anfangs wurden Browser in Eile geschrieben, um mit einer Auszeichnungssprache umzugehen, die nicht finalisiert war und keine offizielle Spezifikation hatte - es gab keine strengen Parsing-Regeln. (HTML 2.0 war 1995 nominell SGML-basiert, aber es war zu spät, um es tatsächlich zu implementieren.)

— Jukka K. Korpela,

2

Der IE hat tatsächlich einen Großteil seines Marktanteils eingebüßt. Aber das hat wahrscheinlich wenig oder gar nichts mit striktem Parsen zu tun. IE beherrschte das Web mit seinen Kuriositäten lange genug, um andere Browser zu zwingen, seine Kuriositäten weitgehend zu imitieren, da sonst so viele Seiten auseinanderfallen würden.

— Jukka K. Korpela

9

Das kurze daran wäre, dass HTML auf einer anderen, nicht mit Hyperlinks verknüpften Auszeichnungssprache namens SGML basiert, die häufig für Dokumentationen und Handbücher und dergleichen verwendet wird.

Aus einem Artikel über die Geschichte von HTML:

Tim hatte erwähnt, dass einige der frühen HTML-Dokumente auf einer alten SGML-Sprache basierten, die CERN bereits verwendete: - Wir haben in HTML einige Tags aus dem SGML-Tagset aufgenommen, das bei CERN [...] The HTML Parser verwendet und einmal unterstützt wurde ignoriert nicht verstandene Tags und nicht verstandene Attribute von CERN-SGML-Tags .

[...] Die meisten frühen HTML-Tags wurden tatsächlich aus der Sprache CERN SGMLGuid übernommen, die selbst eine Variante von AAP (eine frühe SGML-Sprache) war. Zum Beispiel werden Titel, hn, p, ol usw. anscheinend aus dieser Sprache übernommen. Die einzige radikale Änderung war die Hinzufügung des wichtigen anchor () - Links, ohne den das WWW nicht gestartet wäre.

Unter Berücksichtigung des fettgedruckten Teils haben sie im Grunde genommen eine Teilmenge der Tags implementiert, die in dem ihnen bekannten SGML-System verfügbar sind. Sie haben das neue <a> Ankertag hinzugefügt und sich dafür entschieden, eines der vielen Tags zu ignorieren, die sie nicht verwendet haben. ' Sie kümmern sich nicht um oder möchten dies aus irgendeinem Grund unterstützen (z. B. Tags für Bibliografielisten, xmp für "example", "box" -Tag, um ein Kästchen um einen Textblock zu zeichnen usw.). Der einfachste Weg, dies zu tun, besteht darin, dem Parser nicht bekannte Markups zu verzeihen und unbekannte Markups so gut wie möglich zu ignorieren, unabhängig davon, ob die Ursache ein vom Benutzer eingegebenes fehlerhaftes Markup ist oder der schnellste und einfachste Weg, vorhandene Dokumente zu konvertieren Dieses neue HTML-Format fügt einige Hyperlinks zu vorhandenen SGML-Dokumenten hinzu und ignoriert alle Tags, die nicht unterstützt oder implementiert werden.

— Jessica Brown
quelle

Die HTML-Syntax basierte in der Tat auf der konkreten SGML-Referenzsyntax für die Form ihres Markups. SGML selbst verfügte jedoch nicht über Elemente zum Markieren von Dokumenten, die von HTML ausgeliehen werden konnten. Die HTML-Elementmenge ähnelt der in SGML RCS übersetzten GML- Dokument-Markup-Sprache von IBM .

— Ross Patterson

5

Dies ist teilweise ein historischer Überrest des Browserkriegs

IE und netscape konkurrierten um die Marktübernahme und veröffentlichten immer neue Funktionen, die immer "umwerfender" wurden und die Seiten akzeptieren mussten, die für den anderen Browser entwickelt wurden.

Dies bedeutet, dass der Browser unbekannte Tags stillschweigend akzeptiert und ignoriert, nachdem die Komitees angefangen haben, sich einzumischen. Nun, Sie haben ein Komitee, das Dinge entwirft, und infolgedessen viele verschiedene Versionen (mit einigen mehrdeutigen Spezifikationen), von denen der Browser die meisten unterstützen möchte sie, und für jede Version einen eigenen Parser zu erstellen, wäre enorm aufgedunsen. Daher ist es (relativ) einfacher, einen einzelnen Parser mit verschiedenen Modi zu verwenden.

Zum anderen wollten Netscape und IE, dass HTML für den normalen Benutzer zugänglich ist (wie es damals üblich war), was bedeutet, dass versucht wird, das zu tun, was der Benutzer wollte, anstatt das zu tun, was er gesagt hat, und über jedes baumelnde Tag gestolpert wird.

Erschwerend kommt hinzu, dass es auch mehrere "Tutorial" -Seiten gibt, die das Falsche lehren und denken, dass sie richtig sind, weil das, was sie lehren, funktioniert.

Letztendlich bedeutet dies, dass, wenn Sie jetzt einen Browser mit nur striktem HTML-Parsing erstellen, 99% der Websites nicht funktionieren.

— Ratschenfreak
quelle

6

Noch bevor IE auf den Markt kam, führte Netscape kein striktes Parsing durch. Ich erinnere mich an Netscape von Anfang 1997.

— user93353

Selbst wenn es klare Standards gäbe, wäre es für einen Browser schwierig, zwischen Tags zu unterscheiden, die nach der Veröffentlichung des Browsers legitim definiert wurden, und Tags, die niemals legitim waren und niemals sein würden. Wenn "optionale" Tags, die ein Dokument verbesserten, aber für seine semantische Korrektheit nicht erforderlich waren, die Versionsnummer des Standards enthielten, der sie implementierte, dann konnte ein Browser, der Version 23 des Standards implementierte, ein <o24wowzo>Tag ignorieren <o23wowzo>, aber ein , aber z Ein Design hätte den "lesbaren" Aspekt von HTML beeinträchtigt.

— Supercat

2

Nun, wir haben versucht, eine nette strenge Option in den Tausendern zu etablieren, aber sie ist nicht aufgegangen, weil Leute, die blind "Best Practices" befolgten, den Browsern die Schuld gaben, wenn ihr falsches Markup im strengen Modus in Stücke ging. Und die Browser-Anbieter wollten nicht beschuldigt werden.

Sie behaupteten, dies liege daran, dass sie das Web für Laien zugänglicher machen wollten, aber niemand wurde daran gehindert, HTML 4 in seiner mildesten Form zu verwenden.

Trotzdem können Sie HTML5 weiterhin als XML bereitstellen, wenn Sie ein Layout im strengen Stil wünschen. IMO kann es eine gute Möglichkeit sein, die Vorteile von Layout- oder Benutzeroberflächen-Arbeiten in einem strengeren Modus zu nutzen, bevor Sie sie an andere Personen weitergeben, die sie möglicherweise ohne wirkliche Risiken so streng wollen oder auch nicht (es ist ihnen untersagt, den Doctype herauszureißen, weil) Eigentlich bevorzugen sie den Macken-Modus - im Jahr 2017 (zum Zeitpunkt dieser Bearbeitung) sollten sie gedreht werden. Es ist also im Grunde immer noch da, aber ich scheine mich daran zu erinnern, dass es einige Vorbehalte gab, die wir mit XHTML nicht hatten Verbreiten Sie einfach nicht die Nachricht, dass dies "der einzige Weg ist, es richtig zu machen", oder die Twits, die sich für diese Art von Gesprächen entscheiden, werden die Idee durchkreuzen, den Browsern erneut die Schuld geben und sie werden die Zähne nehmen von der einzigen strengen Alternative, die wir noch haben. (2017 edit:

http://mathiasbynens.be/notes/xhtml5

— Erik Reppen
quelle