Warum nicht XHTML5?

53

HTML5 ist also der große Schritt nach vorne, wurde mir gesagt. Der letzte Schritt, den wir gemacht haben, war die Einführung von XHTML. Die Vorteile lagen auf der Hand: Einfachheit, Strenge, die Möglichkeit, Standard-XML-Parser und -Generatoren für die Arbeit mit Webseiten zu verwenden und so weiter.

Wie seltsam und frustrierend ist es, dass HTML5 all das zurückwirft: Wir arbeiten wieder mit einer nicht standardmäßigen Syntax. Wieder einmal müssen wir uns mit historischem Gepäck und der Komplexität des Parsens auseinandersetzen. Auch hier können wir unsere Standard-XML-Bibliotheken, Parser, Generatoren oder Transformatoren nicht verwenden. Alle durch XML eingeführten Vorteile (Erweiterbarkeit, Namespaces, Standardisierung usw.), die das W3C aus guten Gründen ein Jahrzehnt lang genutzt hat, gehen verloren.

Gut, wir haben XHTML5, aber es scheint, dass es nicht so populär geworden ist wie die HTML5-Codierung. Siehe zum Beispiel diese SO-Frage . Sogar die HTML5-Spezifikation besagt, dass HTML5 und nicht XHTML5 "das Format ist, das für die meisten Autoren empfohlen wird."

Habe ich meine Fakten falsch? Warum bin ich sonst der einzige, der sich so fühlt? Warum wählen die Leute HTML5 gegenüber XHTML5?

— Jameshfisher
quelle

6

+1 Ich sehe, dass ich nicht der einzige bin, der mit dem Verlust aller XML-Vorteile in HTML5 frustriert ist.

— Arseni Mourzenko

Gute Frage, gut ausgedrückt.

— Konrad Rudolph

1

Ich hoffe, ich bin nicht der einzige, der sich über den Verlust aller Nachteile von XML in HTML5 freut. Vergleichen wir beispielsweise gültiges HTML5 mit gültigem XHTML. HTML5 <!DOCTYPE html>Hello World

<?xml version="1.0" encoding="iso-8859-1"?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0  Transitional//EN" "DTD/xhtml1-transitional.dtd"><html xml:lang="en" lang="en" xmlns="http://www.w3.org/1999/xhtml"><head><title></title></head><body>Hello World</body></html>

— :,

@zzzzBov, du bist definitiv nicht der Einzige, der sich darüber freut, und deshalb habe ich diese Frage zuerst gestellt. Außerdem: Du würdest doch nicht ernsthaft schreiben <!DOCTYPE html>Hello World, oder? Versuchen Sie das mit diesem Validator .

— Jameshfisher

1

@eegg, anscheinend hast du die Spezifikation für optionale Start-Tags nicht gelesen , weil ich ernsthaft schreiben würde<!DOCTYPE html>Hello World! , da es perfekt gültiges HTML5 ist. Kürzere Dokumente bedeuten weniger Mehraufwand für die Bandbreite, was für große Unternehmen erhebliche Einsparungen bedeutet (haben Sie gesehen, was Google für www.google.com sendet?).

— zzzzBov

25

Ich würde empfehlen zu lesen Wie sind wir hierher gekommen? . Mark Pilgrim gibt eine ausgezeichnete und kurze Geschichte von HTML bis HTML5.

Nach meinem Verständnis nutzen viele Webseiten nicht einmal das "X" von XHTML, weil sie nicht den richtigen MIME-Typ dafür angeben.

— These
quelle

18

Ja. Meine Zusammenfassung dieser Geschichte würde lauten: "Hey, niemand entspricht der Spezifikation. Vielleicht können wir sie dazu bringen, der Spezifikation zu entsprechen, indem wir festlegen, dass die Leute Fehler machen können, die sie wollen. Dann werden alle unsere Dokumente fehlerfrei sein und normenkonform. " Es kann nichts Gutes bringen, eine Spezifikation zu schreiben, wenn man zunächst davon ausgeht, dass niemand die Spezifikationen einhält.

— Jameshfisher

1

@eegg, deine letzte Zeile zeigt deine Unwissenheit gegenüber der Realität. Viele haben gut ist schon davon ausgegangen, dass niemand perfekt ist . Anstelle der Spezifikation "Wenn Sie einen Fehler machen, ist alles kaputt" heißt es stattdessen "Wenn Sie [diese Art von Fehler] machen, dann sollte [dieses Ergebnis] passieren". Wie viele Bücher wären in unseren Regalen, wenn sie 100% korrekt geschrieben, interpunktiert und grammatikalisch korrekt sein müssten, um veröffentlicht zu werden?

— zzzzBov

6

@zzzzBov, Ihre Analogie zu veröffentlichten Büchern ist seltsam. Warum sollte ein HTML-Parser fehlerverzeihender sein als ein Parser für [jede andere Sprache hier], bei dem ein Syntaxfehler mit einer Fehlermeldung angezeigt wird? Stellen Sie sich das Chaos vor, in dem wir stecken würden, wenn unsere C-Compiler ihr Bestes geben würden, um gebrochene Syntax stillschweigend neu zu interpretieren.

— Jameshfisher

@eegg, ich kann mir vorstellen, was passieren würde, wenn ein Parser für eine andere Sprache fehlerverzeihender auf Syntaxfehler reagiert: Wir würden weniger Zeit damit verbringen, fehlenden Klammern und Semikolons auf die Spur zu kommen, und mehr Zeit für die Eingabe von Funktionscode. Ich sage nicht, dass gute Programmierer ihre Programme nicht immer gut gestalten würden, aber es würde mittelmäßigen Programmierern sicherlich helfen , funktionierenden Code zu schreiben. Ein CProgramm würde wahrscheinlich viel ähnlicher aussehen als ein PythonProgramm, bei dem die Semikolons und Klammern meist verschwinden und der wichtige Code übrig bleibt.

— zzzzBov

"Die angeforderte Ressource /past.htmlist auf diesem Server nicht mehr verfügbar und es gibt keine Weiterleitungsadresse."

— Marco

6

Wenn Sie xml-kompatibles html5 erstellen und diese mit xml als MIME-Typ senden, wird der xml-Parser verwendet, und alles, was guten Jazz ausmacht, kehrt zurück.

BEARBEITEN: Weitere Informationen finden Sie unter: http://wiki.whatwg.org/wiki/HTML_vs._XHTML

— deadalnix
quelle

Definiere "guten Jazz". AFAIK: Das Parsen von HTML als XML bietet keinen Vorteil. Generieren und Transformieren sind andere Dinge, die bequem sein können, aber das Parsen an sich bietet keine Vorteile, nur Nachteile (es macht kosmetische Fehler fatal).

— Joeri Sebrechts

3

@Joeri Die Tatsache, dass das Parsen sehr viel einfacher ist, ist aus verschiedenen Gründen in meinem Buch von Vorteil (striktes Parsen erleichtert das Auffinden von Fehlern, bessere Werkzeugunterstützung, da Werkzeuge einfacher zu schreiben sind, Eingaben einfacher zu bereinigen usw.).

— Konrad Rudolph

Sie können auch einige Funktionen bereitstellen, die in Standard-HTML nicht verfügbar sind, z. B. micin xhtml mit anderen XML-Inhalten, und im Allgemeinen alle XML-Funktionen, z. B. Namespaces, verwenden. HTML-Parser sind in der Lage, fehlerhaften Quellcode zu reparieren - kosmetische Fehler, wie Sie sie nennen -, aber diese Korrekturen haben einen Preis. Der Preis ist, dass der Browser wissen muss, was er wahrscheinlich im Code findet, wodurch die verfügbaren Funktionen eingeschränkt werden.

— Deadalnix

3

HTML5 ist die logische und unvermeidliche Konsequenz von Browsern, die das Postelsche Gesetz anwenden ("Seien Sie liberal in dem, was Sie akzeptieren").

Wenn ein Browser mit ausreichendem Marktanteil dieses Prinzip anwendet, müssen andere dem folgen, indem sie nicht konforme Inhalte nicht nur akzeptieren, sondern sie auch so wiedergeben, wie es ihre Konkurrenten tun. HTML5 ist das logische Ergebnis dieser Situation: Die Browser-Anbieter haben entschieden, dass sie, da sie keine Inhalte als ungültig ablehnen werden (zumindest nicht auf HTML-Ebene - Javascript ist eine andere Sache!), Genauso gut um die Ecke sitzen könnten Tisch und vereinbaren Sie eine Interpretation für alles, was der Autor des Inhalts auf sie werfen könnte. In diesem Umfeld haben sie nicht freundlich auf Standardfreaks reagiert und ihnen mitgeteilt, dass sie nicht in dieses Chaos geraten wären, wenn sie nur von Anfang an schlecht geformten Inhalt abgelehnt hätten.

Sie und ich können also von der Seitenlinie wegschreien und den Browserverkäufern und ihren Benutzern mitteilen, dass die Welt ein besserer Ort gewesen wäre, wenn sie John Postel nicht geglaubt hätten, aber der Schaden ist angerichtet und es ist sehr schwer, ihn rückgängig zu machen.

— Michael Kay
quelle

3

Die Geschichte der konkurrierenden Schlamperei der Browser ist wahr genug. Aber hier ist die Sache: Deshalb gibt es die Standards-Geeks. Wenn alle Browser von Anfang an das Geradlinige und Enge durchgesetzt hätten, müssten Organisationen wie das W3C nicht hier sein, um die Dinge unter Kontrolle zu halten. Der springende Punkt der Standards ist die Schadensbegrenzung; Wenn das Normungsgremium Schlamperei aufgibt und akzeptiert, hat es seinen eigentlichen Zweck verfehlt.

— Jameshfisher

1

@eegg: HTML5 definiert die Analyseregeln neu, um alle Eingaben gültig zu machen und dennoch vorhersehbare Konsequenzen zu haben. Wenn Syntaxfehler nicht möglich sind, ist eine ganze Klasse von Fehlern von vornherein ausgeschlossen. Die Fähigkeit von XML, Analysefehler zu verursachen, ist ein Konstruktionsfehler und sollte als solcher erkannt werden.

— Joeri Sebrechts

1

@Joeri, Ihre Position scheint die der HTML5-Spezifikation zu sein, die zu ihrer verrückten logischen Schlussfolgerung gelangt ist. "HTML5 definiert die Parsing-Regeln neu, um alle Eingaben gültig zu machen" - tut es nicht. Das Konzept der Parsing-Fehler besteht weiterhin. "Wenn Syntaxfehler unmöglich sind, ist eine ganze Klasse von Fehlern von vornherein ausgeschlossen" - ist das vielleicht eine Parodie? Diese Logik habe ich in meinem Kommentar zu @pthesis sarkastisch umschrieben. Ja, die Klasse der Syntaxfehler entfernt wird , durch eine größere Klasse von Browser ersetzt werden Syntax Korrekturfehler .

— Jameshfisher

2

Die HTML5-Spezifikation wurde gegenüber der HTML4-Spezifikation erheblich verbessert. Insbesondere die Behandlung von Fehlerbedingungen und ungültigen Markups ist standardisiert, dh alle Browser, die den Standard korrekt implementieren, behandeln ungültige Markups auf dieselbe Weise.

HTML wird meistens von Menschen geschrieben (normalerweise in Verbindung mit einer Art Template-Sprache), und Menschen machen Fehler. Solange alle Browser mit Syntaxfehlern auf dieselbe Weise umgehen, ist die Regel "Seien Sie liberal in dem, was Sie akzeptieren" durchaus akzeptabel.

Das Erstellen von gültigem XML bietet kaum Vorteile, da Tools und Bibliotheken für den Umgang mit HTML (fast) genauso leicht verfügbar sind und HTML für den Menschen einfacher zu schreiben ist als XML.

— Dean Harding
quelle

Über die HTML4- Spezifikation ja. Mein Punkt ist jedoch, dass XHTML1.1 das bereits verbessert hat. Tools / Bibliotheken, die mit HTML umgehen, sind in der Regel wie BeautifulSoup - obwohl sie wunderbare Tools sind, sollten sie zusammen mit den Seiten, die zum Parsen erstellt wurden, sterben.

— Jameshfisher

1

Sie werden ohnehin nie die Vorteile eines einfacheren Parsers oder standardmäßiger XML-Tools auf der Clientseite erhalten.

Es gibt Milliarden von HTML-Seiten im Web, von denen einige von längst verstorbenen Leuten geschrieben wurden, sodass sie niemals auf XML aktualisiert werden. Wenn Sie also einen allgemein nützlichen Benutzeragenten erstellen möchten, müssen Sie in der Lage sein, altmodisches HTML zu analysieren. Wahrscheinlich bringt XHTML nur zusätzliche Komplexität mit sich, da zusätzlich zu dem bereits zu unterstützenden HTML-Parsing ein neuer Parsing-Modus erforderlich ist.

Auf der Serverseite können Sie weiterhin XML-Tools nutzen, indem Sie z. Generieren von XHTML mithilfe von XSLT. Wenn Sie jedoch nicht speziell eine XML-Toolchain verwenden, bietet die Verwendung von XML-Syntax anstelle von nur HTML keinen Vorteil.

(Sie sind nicht der Meinung, dass HTML keine "Standard" -Syntax ist. Die HTML-Syntax ist in der HTML5-Spezifikation genauestens festgelegt, daher ist sie genauso ein Standard wie die XML-Syntax.)

— JacquesB
quelle