Warum sollten Sie am Ende des Tages XHTML anstelle von HTML wählen? [geschlossen]


77

Ich frage mich, warum ich XHTML anstelle von HTML verwenden sollte.

XHTML soll "modularisiert" sein, aber ich habe keine serverseitige Sprache gesehen, die dies ausnutzt.

XHTML ist auch strenger und ich sehe keinen Vorteil. Was bietet XHTML, das ich so dringend brauche? Wie macht es meinen Code "besser"?

BEARBEITEN: Eine weitere Frage, die ich in den Kommentaren gefunden habe: Analysiert XHTML schneller als HTML?

EDIT2: Nachdem ich alle Ihre Kommentare und Links gelesen habe, stimme ich in der Tat zu, dass ein anderer Beitrag die richtige Antwort verdient, also habe ich den ausgewählt, der direkt auf die beste Quelle verweist.

Außerdem wird gezeigt, dass die Leute den grünen Kommentar positiv bewerten, ohne ihn zu lesen.


12
+1 Ich bin gespannt, ob moderne Browser es schneller analysieren können, da normales HTML weniger durcheinander ist und sie nur normale XML-Parser verwenden können.
Dominic Rodger

Gute Frage; Ich glaube nicht, dass meine Meinung eine Antwort wert ist, aber ich denke, dass es die meiste Zeit Zeitverschwendung ist. Machen Sie konformes HTML und nennen Sie es einen Tag.
Paolo Bergantino

4
Jedes Mal, wenn ich mich mit XHTML beschäftige, wünschte ich mir, HTML5 würde etwas Traktion bekommen ...
annakata

1
Dies wurde mehrmals gefragt, siehe zum Beispiel (aktuellen) Top-Link in der Spalte "Verwandte" ...
PhiLho

2
@WebDevHobo: Bitte überdenken Sie die Änderung der akzeptierten Antwort, da sie nicht durch zuverlässige Quellen gesichert ist und es Quellen gibt, die sie widerlegen: webdevout.net/articles/beware-of-xhtml#myths
Kornel

Antworten:


47

Sie sollten Vorsicht vor XHTML lesen. Dies ist ein informativer Artikel, der vor einigen Fallstricken von XHTML über HTML warnt.

Ich war ziemlich begeistert von XHTML, bis ich es gelesen habe, aber es macht mehrere gültige Punkte. Einschließlich des folgenden Bits;

XHTML 1.x ist nicht "zukunftskompatibel". XHTML 2, das sich derzeit in der Entwurfsphase befindet, ist nicht abwärtskompatibel mit XHTML 1.x. In XHTML 2 werden viele wichtige Änderungen an der Art und Weise vorgenommen, wie Dokumente geschrieben und strukturiert werden. Selbst wenn Ihre Site bereits in XHTML 1.1 geschrieben wurde, ist normalerweise eine vollständige Neufassung der Site erforderlich, um sie in korrektes XHTML 2 zu konvertieren Die XSL-Transformation ist in den meisten Fällen nicht ausreichend, da einige Semantiken nicht richtig übersetzt werden.

HTML 4.01 ist eigentlich zukunftskompatibler. Ein gültiges HTML 4.01-Dokument, das für moderne Support-Levels geschrieben wurde, ist gültiges HTML 5, und in HTML 5 wird die meiste Aufmerksamkeit von Browser-Entwicklern und dem W3C geleistet.

Die zukünftige Kompatibilität kann bei der Arbeit an einigen Projekten sehr groß sein. In dem Artikel werden noch einige andere gute Punkte angesprochen, aber ich denke, das hat mich am meisten beeindruckt.

Verwechseln Sie den Artikel nicht mit einer Beschimpfung gegen XHTML. Der Autor spricht zwar über die guten Punkte von XHTML, aber es ist gut, sich der Mängel bewusst zu sein, bevor Sie eintauchen.


3
Ein schöner Artikel und Requisiten an Sie, dass Sie ihn uns gezeigt haben.
KdgDev

9
XHTML 1.x ist „zukunftskompatibel“. Die Charta für die XHTML 2-Arbeitsgruppe ist nun abgelaufen. - Es wurde jetzt von XHTML5
Casebash

3
html5 ist nicht xhtml. xhtml wird sterben und xhtml2 wird nie herauskommen
Neil McGuigan

1
@MrLister Sie meinen die Tatsache, dass XHTML tatsächlich Syntaxfehler abfängt und signalisiert, anstatt sie stillschweigend zu korrigieren und latente Fehler in Ihrem Code zu hinterlassen?
Nayuki

1
@Nayuki Die Tatsache, dass XHTML5 (im Gegensatz zu HTML5 oder früheren Versionen von XHTML) Entitätsnamen wie  und nicht erkennt é. Aus diesem Grund habe ich alle meine XHTML-Dateien bei XHTML 1.1 belassen.
Herr Lister

39

Ich wollte dies als Kommentar zu einem der anderen Beiträge hinzufügen, aber es wurde etwas zu groß.

Was der grundlegende Punkt ist, den die meisten Menschen zu vermissen scheinen, ist der Zweck hinter XHTML. Einer der Hauptgründe für die Entwicklung der XHTML-Spezifikation bestand darin, die präsentationsbezogenen Tags im Markup zu deaktivieren und die Präsentation in CSS zu verschieben. Während diese Trennung mit einfachem HTML erreicht werden kann, wird dieses Verhalten durch die Spezifikation nicht gefördert.

Die Trennung von Meta-Markup und Präsentation ist ein wesentlicher Bestandteil der Entwicklung für das "programmierbare Web" und verbessert nicht nur die Suchmaschinenoptimierung und den Zugriff für Bildschirmleser / Textbrowser, sondern führt auch dazu, dass Ihre Website für diejenigen, die dies wünschen, leichter analysiert werden kann Greifen Sie programmgesteuert darauf zu (in vielen einfachen Fällen kann dies die Entwicklung einer bestimmten API überflüssig machen oder sogar nur clientseitigen Skripten ermöglichen, beispielsweise Telefonnummern zu identifizieren). Wenn Ihre Webseite der XHTML-Spezifikation entspricht, kann sie problemlos mit XML-bezogenen Tools und Dingen wie XPath durchsucht werden. Dies sind fantastische Neuigkeiten für diejenigen, die bestimmte Informationen von Ihrer Website extrahieren möchten.

XHTML wurde nicht für die Verwendung für sich selbst entwickelt, sondern für die Verwendung mit einer Vielzahl anderer Technologien. Es basiert stark auf der Verwendung von CSS für die Präsentation und bildet eine Grundlage für Dinge wie Mikroformate (ob Sie sie lieben oder hassen), um ein standardisiertes Markup für die gemeinsame Datenpräsentation anzubieten.

Lassen Sie sich nicht von der Menge täuschen, die XHTML für unbedeutend und einfach zu restriktiv und sinnlos hält. Es wurde mit einem Zweck erstellt, den 95% der Welt zu ignorieren scheinen / von dem sie nichts wissen.

Verwenden Sie auf jeden Fall HTML, aber verwenden Sie es für das, wofür es gut ist, und gehen Sie beim Betrachten von XHTML genauso vor.


In Bezug auf die Analysegeschwindigkeit stelle ich mir vor, dass es beim Analysieren der tatsächlichen Dokumente zwischen XHTML und HTML kaum Unterschiede geben würde. Der Kompromiss besteht lediglich darin, wie Sie das Dokument anhand des verfügbaren Markups beschreiben. XHTML-Tags sind aufgrund der erforderlichen Attribute, des ordnungsgemäßen Schließens usw. in der Regel länger, verzichten jedoch auf die Notwendigkeit eines Präsentations-Markups im Dokument selbst. In diesem Fall denke ich, dass Sie über den Vergleich einer Apfelsorte mit einer etwas anderen Apfelsorte sprechen ... sie sind unterschiedlich, aber es ist unwahrscheinlich, dass dies von Bedeutung ist (in Bezug auf das Parsen und Rendern) ) wenn du nur einen gesunden, leckeren Apfel willst.


14
Während XHTML-Ziele lobenswert sind, spielen die Browser-Anbieter weder mit XHTML noch mit CSS gut. Richtiges XHTML macht die Webentwicklung derzeit schwieriger und nicht einfacher. Wenn die Anbieter von Tools und Browsern diese Situation ändern, werden wir möglicherweise einige Vorteile feststellen können, aber diejenigen, die am meisten davon profitieren können, sind nicht die Website-Entwickler, sondern die SE-Anbieter. Stellen Sie sich vor, Sie könnten aussagekräftige Informationen präsentieren, die von Ihren Websites in einem Maße gesammelt wurden, in dem die Website selbst keinen Besuch benötigt? Was passiert mit Ihren Werbeeinnahmen? Wer glaubst du, lebt überhaupt in den Elfenbeintürmen?
AnthonyWJones

1
Gutes Gegenargument; und ich verstehe Ihren Standpunkt, aber der Isolationspunkt ist nicht rein XHTML-bezogen, da Sie argumentieren könnten, dass RSS-Feeds dies getan haben. Die Leute besuchen jedoch immer noch Websites, da viele Leute nicht gerne über Feeds lesen. Es geht darum, einen einfacheren Zugriff auf Daten zu ermöglichen und diese semantisch zu markieren, anstatt sie in einem Durcheinander von präsentationsbezogenen, schlecht geformten Tags zu verbergen. Es ist nur ein Vorteil für Sie, Ihre Website für die Verarbeitung leicht zugänglich und "aussagekräftig" zu machen. In Bezug auf Browser, die Markup rendern. Ich kann zustimmen, aber zeige mir zuerst Konsistenz beim HTML-Rendering.
James B

3
Die Zusammenfassung der Zusammenfassung lautet dann, dass die Interoperabilitätsvorteile von XHTML durch die Unzulänglichkeiten der Browser-Anbieter bedroht sind.
Annakata

6
Die Trennung von Präsentation und Markup war ein Ziel, das mit dem strengen Doctype einige Zeit vor XHTML lag. Und HTML 4 hat das Präsentations-Markup zugunsten des strukturellen Markups auslaufen lassen. Nur weil fast jeder HTML 4 Transitional verwendet, bedeutet dies nicht, dass es eine gute Idee ist oder sogar von der Spezifikation empfohlen wird. Abgesehen davon erhalten Sie keine echte Trennung, da Sie Ihr Markup fast immer an Ihren Stil anpassen müssen. CSS Zen Garden ist schön, aber für einige CSS-Effekte benötigen Sie mehrere Ebenen von <div> s. Und das ist imho keine gute Trennung von Stil und Inhalt. HTML und XHTML sind hier sehr ähnlich
Joey

2
Das Konzept datiert vor XHTML, aber XHTML macht es zu einer Priorität, und die Spezifikation versucht, eine strenge Kontrolle darüber zu geben. Die Unterstützung von HTML4 für die Trennung von Präsentation und Markup ist bestenfalls schlampig. <div> s sind keine Präsentations-Tags, sondern dienen der logischen Aufteilung von Informationen. Nur weil sie nicht richtig verwendet werden, bedeutet dies nicht, dass die XHTML-Spezifikation in irgendeiner Weise ungültig ist. XHTML fördert weitaus bessere Praktiken als HTML und ist in Bezug auf schlechte Syntax weitaus strenger. Es ist eine Win-Win-Situation für diejenigen, die auf ein auf Standards basierendes Web hinarbeiten möchten.
James B

18

Für den Besucher einer Website macht es wahrscheinlich keinen sichtbaren Unterschied. Darüber hinaus ist XHTML in der Regel schwieriger zu verwenden, da mindestens ein weit verbreiteter Browser immer noch nicht weiß, wie er damit umgehen soll, und Sie es in diesem Fall als Text / HTML bereitstellen müssen (was zu ungültigem HTML führt).

Wenn Ihr HTML-Code regelmäßig von automatisierten Tools verarbeitet wird, anstatt von Menschen gelesen zu werden, sollten Sie XHTML verwenden, da es strenger strukturiert ist und XML einfacher zu analysieren ist (vom Standpunkt der Anwendung aus. Nicht, dass XML dies ist von Natur aus leicht zu analysieren).

Abgesehen davon sehe ich jedoch keine zwingenden Gründe, es zu verwenden. XHTML wurde entwickelt, um XML-Funktionen für HTML zu nutzen, und läuft im Grunde auf "HTML 4 mit mehreren lästigen Nebenwirkungen" hinaus (zumindest IMHO).


5
+1. Ich stimme vollkommen zu. XTHML ist ein weiteres Beispiel für die Entwicklung von Komitees, die in Elfenbeintürmen leben (CSS ist das andere Beispiel, an das ich denke).
AnthonyWJones

2
Ich stimme voll und ganz mit XHTML überein, aber die Entwicklung von CSS war bis zu ihrer relativ jüngsten Entscheidung, die Browser-Anbieter nur den Standard herausfinden zu lassen, in Ordnung. Die Probleme mit CSS scheinen mir zu 100% die Schuld der Anbieter zu sein.
Annakata

10
Ich stimme dem hier vorgebrachten Argument grundsätzlich nicht zu. Ich wollte einen Kommentar posten, aber er wurde zu groß und wurde zu einer Antwort (unten). Die XHTML-Spezifikation. wurde nicht einfach entwickelt, um das Parsen zu vereinfachen (obwohl dies der Fall ist), sondern um eine Vielzahl von Technologien zu unterstützen, die eine vollständigere Struktur aufweisen, als HTML zulassen konnte. Vielleicht von Leuten in Elfenbeintürmen entwickelt ... aber die Spezifikation ist viel sinnvoller, wenn Sie die Dinge im Internet betrachten.
James B

3
Ich denke, alle positiven Stimmen zu diesem Beitrag zeigen zwei Dinge: 1. Viele Leute haben XHTML wirklich nicht verstanden (siehe James 'Antwort), und 2. es gibt eine Menge Frustration darüber aufgrund seiner wahrgenommenen Nützlichkeit. Wer ist schuld? Ich denke, die "Werbung" für XHTML war einfach sehr, sehr schlecht.
Konrad Rudolph

1
@Konrad: XHTML ist zweifellos nützlich, aber diejenigen, die upvoted haben, könnten sein: 1) Frustriert, wie Sie sagten, muss XHTML (derzeit) als HTML bereitgestellt werden! 2) Nur einfache Informationen an menschliche Benutzer ausgeben, nicht auf externe Parser abzielen und keine Modularität oder andere erweiterte Funktionen (Namespace ...) benötigen.
PhiLho

16

Verwenden Sie HTML (HTML4 Strict oder HTML5).

  • HTML kann CSS vollständig nutzen, kann validiert und eindeutig analysiert werden. Die Trennung von Struktur und Präsentation wurde in HTML4 vorgenommen, und XHTML setzte dies lediglich fort.

  • Alle Browser unterstützen HTML. Nur einige Browser unterstützen XHTML und diejenigen, die dies tun, bieten häufig eine ausgereiftere und besser getestete und optimierte Unterstützung für HTML (dies wird durch die Tatsache verursacht, dass ein winziger Teil der Seiten den XML-Modus verwendet).

  • Wenn Sie sich für IE und Google interessieren, müssen Sie HTML oder eine Teilmenge von XHTML und HTML verwenden, die in Anhang C der XHTML-Spezifikation definiert sind. Letzteres ist in beiden Welten fast das Schlimmste, da solches XHTML nicht mit Standard-XML-Tools generiert werden kann, keine für XHTML neuen Erweiterungsmechanismen verwenden kann und zusätzliche Einschränkungen gegenüber denen in HTML allein aufweist.

  • XHTML1.0 ist jetzt über 10 Jahre alt, es wurde in "Web1.0" -Zeiten entwickelt und wie der Leiter von W3C sagte, hat es im Nachhinein nicht funktioniert und es ist ein besserer Ansatz erforderlich . W3C HTML5 wurde während des Gesprächs geschrieben und geht auf die Anforderungen der heute verwendeten Webanwendungen ein und weist eine sehr gute Abwärtskompatibilität auf.

  • HTML5 schließt viele Lücken zwischen HTML4 und XHTML1 (z. B. fügt Inline-SVG, MathML i RDF hinzu) und bereinigt die Sprache über das hinaus, was in XHTML1.0 und XHTML1.1 getan wurde.

  • XHTML2 wird in absehbarer Zeit nicht von Webbrowsern unterstützt. Es ist wahrscheinlich, dass es niemals unterstützt wird (alle Browser-Anbieter unterstützen [X] HTML5 stark, einige haben bereits erklärt, dass sie XHTML2 nicht implementieren werden).


XHTML1.0 hat genau die gleiche Semantik und Trennung von Präsentation und Struktur wie HTML4.01. Wer etwas anderes sagt, hat die Spezifikation nicht gelesen . Ich ermutige alle, die Spezifikation zu lesen - sie ist überraschend kurz und uninteressant.

  • Stylesheets wurden in HTML4.01 eingeführt und in XHTML1.0 nicht geändert.
  • Präsentationselemente waren in HTML4.01 veraltet und wurden in XHTML1.0 nicht entfernt.

XHTML-Mythen .


Es gibt keine unauffindbaren Unterschiede in HTML und XHTML, die das Parsen von einem viel langsamer als das andere machen würden. Dies hängt davon ab, wie der Parser implementiert ist.

  • Sowohl SGML- als auch XML-Parser müssen die gesamte DTD laden und analysieren, um Entitäten zu verstehen. Dies allein ist normalerweise mehr Arbeit als das Parsen des Dokuments selbst. HTML-Parser "betrügen" fast immer und verwenden fest codierte Entitäten und Elementinformationen. XHTML-Parser in Browsern betrügen ebenfalls.
  • Das Parsen von HTML erfordert die Behandlung impliziter Start- und End-Tags, und reales HTML erfordert zusätzliche Arbeit, um falsch platzierte Tags zu behandeln.
  • Für eine ordnungsgemäße Analyse von XHTML müssen XML-Namespaces verfolgt werden.
  • Drakonische XML-Regeln erfordern die Überprüfung, ob jedes Zeichen richtig codiert ist. HTML-Parser mögen damit durchkommen, aber OTOH müssen sie suchen <meta>.

Der Gesamtunterschied bei den Kosten für das Parsen ist gering im Vergleich zu der Zeit, die zum Herunterladen von Dokumenten, Erstellen von DOMs, Ausführen von Skripten, Anwenden von CSS und allen anderen Aufgaben von Browsern benötigt wird.


13

Ich bin überrascht, dass alle Antworten hier XHTML über HTML empfehlen. Ich bin der gegenteiligen Meinung - Sie sollten XHTML auf absehbare Zeit nicht verwenden. Hier ist der Grund:

  • Kein Browser interpretiert XHTML als XHTML, es sei denn, Sie dienen als Mimetyp application/xhtml+xml. Wenn Sie es nur mit dem Standard-Mimetyp bereitstellen, wird es von allen Browsern als HTML interpretiert, z. B. wenn nicht geschlossene oder nicht ordnungsgemäß verschachtelte Elemente akzeptiert werden.

  • Sie sollten dies jedoch niemals tun , da Internet Explorer dies nicht erkennt application/xhtml+xmlund die Seite nicht vollständig rendern würde.

  • Es gibt signifikante Unterschiede im DOM zwischen XHTML und HTML. Da derzeit alle sogenannten XHTML-Seiten als HTML bereitgestellt werden, wird der gesamte Javascript-Code mit dem HTML-DOM geschrieben. Wenn die Unterstützung für den XHTML-Mimetyp so bedeutend wird, dass die Benutzer davon überzeugt werden, ihn zu verwenden, wird der größte Teil ihres Javascript-Codes beschädigt - selbst wenn sie glauben, dass ihre Seiten als XHTML validiert sind.


1
Dies ist kaum ein Punkt ... als ob niemand es jemals benutzt, wie wird es jemals zu einem akzeptierten Standard werden? Es gibt viele Workarounds, genau wie es viele für eine große Anzahl der neuen Web-Technologien gibt (selbst PNGs mit Transparenz müssen im IE noch umgangen werden).
James B

5

Anstatt weiterhin über HTML 4.01 Strict und XHTML Strict zu diskutieren, würde ich vorschlagen, heute mit HTML 5 zu beginnen. John Resig, der Autor von jquery, machte letztes Jahr in seinem Blog einen ähnlichen Vorschlag .

Der HTML 5-Doctype löst in seiner schönen Einfachheit den Standardmodus in allen Browsern (einschließlich IE6) aus.

<!DOCTYPE html>

Das ist es.

HTML 5 bietet einige aufregende neue Funktionen wie das <canvas>Tag, mit dem die Entwicklung von Javascript-Anwendungen möglicherweise auf die nächste Stufe gebracht werden kann. HTML 5 bietet auch eine angemessene Unterstützung für Medien (und Medien sind heutzutage ein ziemlich wichtiger Aspekt des Webs!) In Form von <video>und<audio> Tags.

Wenn Ihnen die Syntax von XHTML gefällt, dh das Schließen von "leeren" Tags, z. B. <br />, wird dies in HTML 5 vollständig unterstützt. Von Karl Dubost aus dem W3C-Beitrag Erfahren Sie, wie Sie HTML 5 schreiben :

Das automatisch schließende Tag ist in HTML 5 zulässig und konform.

XHTML2 hat im Vergleich zu HTML 5 relativ wenig Beachtung gefunden. Es wird immer deutlicher, dass HTML 5 die Zukunft des Markups im Web ist. Microsofts neuester Browser, IE8 noch macht XHTML diente als text / xml als text / html.

Microsoft hat einen Co-Vorsitzenden in der W3C-HTML-Arbeitsgruppe und es gibt eine implizite Unterstützung für HTML 5. Alle Browser-Anbieter haben öffentlich ihre Unterstützung für HTML 5 angekündigt.

Selbst wenn XHTML2 wieder Unterstützung von der Branche erhält, wird es letztendlich kein bedeutendes Problem sein, zwei konkurrierende Standards zu haben, wie es in der Vergangenheit der Fall war. Beide Sprachen unterstützen XML-Namespaces (im Fall von HTML 5 Serialisierung von HTML, dh DOCTYPE-Switching).


Ich kann nicht anders, als zuzustimmen, dass HTML5 ein vielversprechender Standard zu sein scheint. Ich hoffe, dass es besser abschneidet als die XHTML2-Spezifikation.
James B

1
Wenn ich Tags nicht schließe, fühle ich mich trotzdem schmutzig.
KdgDev

2
@WebDevHobo, Sie können Ihre Tags schließen und sie werden weiterhin korrekt gegen HTML 5 validiert - dies ist Teil der Spezifikation. Ich bevorzuge dies auch selbst (siehe Update auf dem Post für das Zitieren).
Bayard Randel

4

Schauen Sie sich http://www.w3.org/MarkUp/2004/xhtml-faq#need an . Neben der Modularisierung gibt es einige gute Gründe.

Ich bevorzuge XHTML, weil es strenger und übersichtlicher ist. HTML ist schrullig und Browser müssen Dinge wie akzeptieren <b><i>sadasd</b></i>. Dies ist zwar ein wirklich einfaches Beispiel, es könnte jedoch auch verwirrender werden und verschiedene Browser könnten die Dinge unterschiedlich gestalten.

Ich denke auch, dass XHTML "schneller" sein muss, da der Browser diese Art von "Reparationen" nicht durchführen muss.


Browser nicht haben unsachgemäß verschachtelte Tags zu akzeptieren (Ihr Beispiel ist ungültig HTML), aber sie tun - da Autoren sie verwenden, und ist statt Rendern der Seite Fehler an Anwender werfen wenig hilfreich. Selbst als Anwendung / xhtml + xml werden viele Browser in den Text- / HTML-Modus wechseln, wenn sie auf einen wohlgeformten Fehler stoßen.
Quentin

Die Tags <b> und <i> sind in HTML ebenfalls veraltet, da sie präsentativ sind. <strong> und <em> sind die semantischen Äquivalente.
Bayard Randel

@Bayard: <b> und <i> sind trotz Präsentation nicht veraltet. w3.org/TR/REC-html40/present/graphics.html#edef-B (dies hat sich weder in XHTML noch in HTML5 geändert). Natürlich sollten sie nicht verwendet werden, wenn andere Elemente besser geeignet sind, aber HTML hat nicht für alles ein Element, und die Verwendung von <em> für alles, was kursiv ist, ist genauso falsch.
Kornel

3

Einige Unterschiede sind:

  • XHTML-Tags müssen ordnungsgemäß verschachtelt sein
  • Die Dokumente müssen ein Stammelement haben
  • XHTML-Tags werden immer in Kleinbuchstaben geschrieben
  • Tags müssen immer geschlossen sein (z. B. <br>muss die Verwendung des Tags in XHTML ein schließendes Tag <br />oder <br></br>in XHTML haben)

Hier sind einige Links dazu

Wiki XHTML

Wiki HTML vs XHTML


"# XHTML-Tags sind immer in Kleinbuchstaben # Tags müssen immer geschlossen sein (z. B. muss die Verwendung des <BR> -Tags in XHTML das schließende Tag <BR /> oder <BR> </ BR> in XHTML haben)" "Warum ist Ihr <br / > in Großbuchstaben markieren?
Antony Carthy

doh ... es war eine arbeitsreiche Woche! ;) Guter Ort, ich habe es bearbeitet.
Kevchadders

1
HTML-Elemente werden ebenfalls ordnungsgemäß verschachtelt. Manchmal sind Start- oder End-Tags optional oder verboten. HTML-Dokumente müssen ein Stammelement haben.
Quentin

2
Die Frage war nicht über die Unterschiede, ich nehme an, das Plakat kennt sie ...
PhiLho

2

Als Programmierer sollten Sie sich SEHR Sorgen um Ihren Code machen. HTML ist hässlich und folgt nur wenigen Regeln.

XHTML hingegen wandelt HTML nach strengen strukturellen und syntaktischen Regeln in eine geeignete Sprache um.

XHTML ist für alle besser, da es dabei hilft, das Web an einen Punkt zu bringen, an dem sich alle (alle Browser) darauf einigen können, wie eine Webseite angezeigt werden soll.

XHTML ist ein XML-Nachkomme, und dies ist für Parser, die für die Analyse syntaktisch einwandfreier XML-Dokumente entwickelt wurden, viel einfacher.

Wenn Sie den Nutzen von XHTML nicht erkennen können, können Sie auch MS Word zum Erstellen Ihrer HTML-Dokumente verwenden.


4
HTML hat ziemlich strenge syntaktische und semantische Regeln. Sie sind einfach nicht dasselbe wie für XML. Vielleicht möchten Sie die Spezifikation lesen :)
Joey

HTML4 hat. HTML5 hat Regeln (oder zumindest gibt es viele Leute, die dies wünschen), wie Fehler korrigiert werden können, dh es gibt keine strengen syntaktischen und semantischen Regeln mehr. Und das Problem mit HTML4 ist, dass Browser bereits Fehler korrigieren und die "strenge Syntax" zu einem Witz machen.
OregonGhost

2
"Wenn Sie den Nutzen von XHTML nicht erkennen können, können Sie auch MS Word zum Erstellen Ihrer HTML-Dokumente verwenden." .... Ja wirklich?
Paolo Bergantino

Ich kenne die Spezifikation von HTML 4.1, aber ich glaube nicht, dass WebDevHobo danach gefragt hat. Die meisten Leute wissen nicht, dass HTML 4.1 eine Spezifikation ist, also codieren sie, wie sie wollen, einschließlich, wie oben <b> <i> falsch </ b> </ i>. Außerdem habe ich nie gesagt, dass es keine Regeln gibt, nur dass es weniger hat. Bitte überarbeiten Sie -1, da es bei diesem Argument mehr um die Verwendung von Standards geht als um die Tatsache, dass es einen Standard für HTML gibt (teilen Sie dies IE6 mit).
Antony Carthy

2
Sie sagen, HTML ist hässlich ... Ich sage, XML / XHTML ist genauso hässlich und ausführlicher, sodass es mehr von dieser Hässlichkeit verbreitet. Im Wesentlichen sehe ich immer noch nicht, was Browser-Anbieter daran hindern wird, "freundlich" zu sein und ihr (inkompatibles) Bestes zu geben, um mit nicht konformem XHTML umzugehen, genau wie jetzt mit HTML, und uns MSIE6-für-XHTML überall zu geben nochmal.
Dave Sherohman

2

Mit XHTML können alle für XML entwickelten Tools verwendet werden. Unter anderem gibt es XSLT, das Einbetten von SVG usw.


SVG ist theoretisch nett, aber die meisten Webseiten haben das MSIE-Problem, wenn es um SVG geht. (Und die Arbeit wird fortgesetzt, um SVG in HTML5 zu beschreiben)
Quentin

Ich würde nicht sagen erlaubt, macht es aber einfacher. HTML erlaubt SVG über <Objekt> und Daten: URI (nicht so hübsch, aber möglich). XSLT kann HTML ausgeben und es gibt Tools, die HTML analysieren und an den XSLT-Prozessor übergeben können (z. B. müssen Sie in PHP nur loadXML () in loadHTML () ändern, und alles funktioniert).
Kornel

SVG in einem Daten-URI auf Gecko erlaubt zum einen keine Stile (Fehler 308590), was es zu einer Art Nichtstarter macht.
Ken

2

Interessante Entwicklung: XHTML 2-Arbeitsgruppe wird voraussichtlich Ende 2009 die Arbeit einstellen, W3C wird die Ressourcen für HTML 5 erhöhen

2009-07-02: Heute gibt der Direktor bekannt, dass die Charta nicht erneuert wird, wenn die Charta der XHTML 2-Arbeitsgruppe wie geplant Ende 2009 ausläuft. Auf diese Weise und durch die Aufstockung der Ressourcen in der Arbeitsgruppe hofft W3C, den Fortschritt von HTML 5 zu beschleunigen und die Position von W3C in Bezug auf die Zukunft von HTML zu klären. Eine FAQ beantwortet Fragen zur Zukunft der Ergebnisse der XHTML 2-Arbeitsgruppe und zum Status verschiedener Diskussionen im Zusammenhang mit HTML. Erfahren Sie mehr über die HTML-Aktivität.

Nun, ich denke, das macht die Zukunft von HTML ziemlich klar.


1

XHTML zwingt Sie, ordentlich zu sein.

In HTML können Sie beispielsweise Folgendes schreiben:

<img src="image.jpg">

Dies ist nicht sehr logisch, da das imgTag nie geschlossen wird. In XHTML müssen Sie das Tag jedoch wie folgt ordentlich schließen:

<img src="image.jpg" />

Ich benutze gerne etwas, das mich dazu zwingt, ordentlich zu sein.

Steve


Ich denke, es macht Sinn, dass das img-Tag nie geschlossen wird. HTML! = XML und da das img-Tag keinen Inhalt hat, warum sollten Sie es schließen?
Pim Jager

3
Es ist vollkommen logisch - solange Sie es nicht isoliert behandeln. Es gibt keinen Grund für ein img-Element, Inhalt zu haben, daher sagt die DTD, dass es keinen Inhalt haben kann. Da es keinen Inhalt haben kann, können Sie (mit 100% iger Zuverlässigkeit) implizieren, dass sich alles, was nach dem Start-Tag angezeigt wird, außerhalb des Elements befindet. Das Ergebnis ist, dass das End-Tag verboten ist. Dies führt zu einem kleineren Aufschlag. Es ist weniger intuitiv, aber einfacher zu schreiben, wenn Sie die Regeln gelernt haben.
Quentin

2
1) Der Speicherplatz vor dem Beenden des Schrägstrichs ist veraltet. Ich bezweifle, dass noch viele Netscape-Browser ihn benötigen. 2) Sie können mit HTML ordentlich umgehen, indem Sie alle Tags schließen, die einen schließenden Teil akzeptieren. In der Tat könnte die Durchsetzung der Regeln für den Entwickler einfacher sein.
PhiLho

@Pim Jager und @David Dorward: Ich verstehe, was Sie mit einem Bildelement ohne Inhalt sagen, aber ich denke, dass die Vorgehensweise von XHTML logischer und konsistenter ist.
Steve Harrison

@PhiLho: 1) Danke, ich werde das untersuchen. 2) Ich stimme zu.
Steve Harrison

1

Der Untertitel der XHTML 1.0-Empfehlung:

Eine Neuformulierung von HTML 4 in XML 1.0

Heutzutage gibt es viele Tools zur Verarbeitung von XML. Mit XHTML können Sie eine Vielzahl von Tools auf Ihren Seiten bearbeiten und Informationen programmgesteuert extrahieren.

Wenn Sie HTML verwenden würden, wäre dies ebenfalls möglich. Es gibt Tools zum Parsen von HTML-DOM-Bäumen. Diese Tools sind jedoch häufig spezialisierter als die für XML. Möglicherweise finden Sie Ihre bevorzugten XML-Datenverarbeitungswerkzeuge nicht kompatibel mit HTML. Darüber hinaus gibt es heutzutage so viele Verwendungsmöglichkeiten für XML, dass Sie XML möglicherweise für einen anderen Teil einer Anwendung verwenden. Warum nicht auch denselben XML-Parser verwenden, um Ihre Webseiten zu analysieren? Dies ist die Motivation hinter XHTML.

Wenn Sie bereits mit HTML 4.01 vertraut sind, haben Sie ein etabliertes Projekt mit HTML 4 und haben nicht viel Freizeit. Verwenden Sie einfach HTML 4.01. Wenn Sie Freizeit haben, lernen Sie trotzdem XHTML 1.1 und starten Sie Ihre neuen Projekte in XHTML 1.1 - das schadet nichts. Wenn Sie etwas anderes als HTML 4.01 verwenden oder mit HTML 4 sowieso nicht vertraut sind, lernen Sie einfach XHTML 1.1.


Der Schaden bei der Verwendung von XHTML ist entweder mangelnde IE-Kompatibilität oder die Beschränkung auf eine gemeinsame Teilmenge von XHTML und HTML. Beispielsweise können Sie mit dem XML-Serializer "Anhang C" XHTML nicht sicher generieren (z. B. verwirrt <script /> Nicht-XML-Parser).
Kornel

Du hast recht. Ich habe nicht daran gedacht, XHTML zu generieren, als ich meine Antwort schrieb. Und ja, ich habe an die gemeinsame Teilmenge von HTML und XHTML gedacht, um IE-Parsing-Probleme zu vermeiden.
Wesley

1

Wenn Sie XHTML mit dem richtigen DocType verwenden, wird der Browser gezwungen, den Inhalt in einem standardkonformen (strengen) Modus zu rendern. Dadurch verhalten sich die verschiedenen Browser besser und vor allem einander ähnlicher. Dies erleichtert Ihnen die Arbeit als Webentwickler erheblich, da weniger browserspezifische Optimierungen erforderlich sind, damit der Inhalt in allen Browsern gleich aussieht.

Quirksmode.org hat viele gute Informationen zu diesem Thema.


2
Durch die Verwendung von HTML mit dem richtigen Doctype werden Browser auch in den Standardmodus versetzt. Heck, die Verwendung von nonsenseML mit einem verrückten erfundenen Doctype wird das auch tun.
Quentin

0

Meiner Meinung nach ist die Strenge zumindest theoretisch eine gute Sache, denn in HTML müssen Sie nicht streng sein, und aus diesem Grund und aufgrund des HTML5-Mülls verfügen Browser über fortschrittliche Fehlerkorrekturalgorithmen, die das Beste bewirken aus kaputtem HTML. Das Problem ist, dass die Algorithmen nicht genau gleich sind und zu wirklich seltsamem Verhalten führen, das Sie nicht vorhersagen können. Mit XHTML hingegen verfügen Sie normalerweise über feines, gültiges XHTML, sodass die Fehlerkorrekturalgorithmen nicht benötigt werden, dh das gesamte Browserverhalten ist vorhersehbar. Darüber hinaus erleichtert strenger Code Ihren Tools die Arbeit mit dem Code. Sie haben also mit XHTML eigentlich nichts zu verlieren, aber es gibt ein gewisses Gewinnpotential. Mit einfachem HTML wird es noch schlimmer, wenn HTML5 endlich verfügbar ist und "offen sein in dem, was Sie akzeptieren". wird zu dem beschriebenen seltsamen Verhalten führen. Aber zumindest ist es dann ein standardisiertes seltsames Verhalten. Seufzer.

Wenn Sie dagegen eine gute IDE wie Visual Studio verwenden, ist es fast unmöglich, fehlerhaften HTML-Code zu erstellen, sodass das Ergebnis dasselbe ist.


4
Browser haben eine Fehlerkorrektur, weil Leute schlechtes HTML schreiben, nicht weil HTML "weniger streng" ist. XHTML ist nicht anders - die meisten Browser, die es unterstützen, werfen einen Fehler auf nicht wohlgeformte Daten und analysieren sie dann mit dem HTML-Parser. (Und sie werden versuchen, Fehler durch gut ungültiges XHTML zu korrigieren).
Quentin

1
Eigentlich ist das einfach falsch. Browser werden durch einen Fehler bei "nicht wohlgeformten Daten" und hören dann einfach auf zu analysieren. Gemäß Spezifikation. Sie versuchen nicht weiter, es zu analysieren. (Fahren Sie fort und probieren Sie es aus. Holen Sie sich ein zufälliges HTML-Dokument. Ändern Sie den Doctype (oder fügen Sie einen hinzu) zu einem XHTML-Dokument. Öffnen Sie ihn in Firefox. Beobachten Sie, wie Firefox nicht versucht, den ersten Fehler zu beheben. (Wenn dies der Fall ist.) Wenn die Seite angezeigt wird, bedeutet dies, dass der HTML-Code auch für XHTML gültig ist, was normalerweise nicht der Fall ist (BR-, IMG-, HR- oder andere selbstschließende Tags haben unterschiedliche Formen in XHTML und HTML).
Alya

Firefox wirft einen gelben Bildschirm des Todes. Die meisten XHTML-fähigen Browser tun dies nicht. Opera fordert den Benutzer beispielsweise auf, die Seite stattdessen als Text / HTML zu behandeln: realtech.burningbird.net/image-galleries/screenshots/… (und, wenn ich mich recht erinnere, wechselt WebKit einfach ohne Aufforderung zu Text / HTML)
Quentin

@ David: Sie haben Recht, dass der Grund, warum Browser jetzt eine Fehlerkorrektur haben, die schlechte HTML-Sache ist. Aber das spielt keine Rolle, denn wir sind da, wo wir sind. Normales HTML hat eine Fehlerkorrektur in allen Browsern, unabhängig davon, was im Standard definiert ist, und wir werden es niemals zum Verschwinden bringen. Daher ist HTML in den meisten Browsern praktisch weniger streng als XHTML.
OregonGhost

0

Verwenden Sie XHTML

  • Scheitert schnell . Wenn es Inkonsistenzen gibt, werden diese während der Validierung gefunden.
  • Es fördert ein besseres Design, indem semantisches Markup von Präsentation usw. getrennt wird.
  • Es ist strukturiert, was bedeutet, dass Sie es als Datenobjekt behandeln und alle möglichen Abfragen dagegen ausführen können. Beispielsweise könnten Sie alle Adressen oder Zitate auf Ihrer Website finden.
  • Sie können Build-Time-Optimierungen durchführen . Da es sich um wohlgeformtes XML handelt, können Sie Operationen während der Erstellungszeit leicht finden / ersetzen. Oder jede Dokumentenverwaltung und -manipulation.
  • Sie können XSLT oder andere Transformationsskripte schreiben , um Ihr XHTML programmgesteuert für andere Plattformen zu transformieren. Zum Beispiel könnten Sie ein XSLT für das iPhone haben, das alles XHTML transformiert, um es kompatibel oder benutzerfreundlicher für das iPhone zu machen
  • Sie sind zukunftssicher . Die Transformation von XHTML in eine neuere Semantik ist mit der Transformation wieder sehr einfach.
  • Suchmaschinen werden sich weiterentwickeln, um mehr semantische Informationen als Teil des programmierbaren Webs zu sammeln .
  • DOM-Operationen sind zuverlässiger, da sie strukturiert sind.
  • Aus algorithmischer Sicht ergibt sich eine einfachere und schnellere Analyse .

2
Wenn Sie HTML validieren, werden Sie auch diese Inkonsistenzen finden. Die Trennung von Struktur und Präsentation wird besser mit Transitional / Strict und nicht mit HTML / XHTML ausgedrückt. HTML ist auch strukturiert. Sie können diese Operationen auch mit HTML ausführen (Sie können einfach keinen XML-Parser verwenden). XHTML ist nicht strukturierter. Aus algorithmischer Sicht müssen Sie es als Text / HTML bereitstellen, wenn es in MSIE funktionieren soll, damit Browser keinen Nutzen daraus ziehen.
Quentin

@David: Sie können Abfragen ausführen und Operationen an Flatfile-Protokollen ausführen (siehe Protokollparser), aber das bedeutet nicht, dass es für die Aufgabe gut geeignet ist. XML hat eine Vielzahl von Anwendungen und das Ökosystem der Tools ist viel umfangreicher. Wenn Sie beispielsweise NAnt verwenden, können Sie XPath verwenden, um Teilbäume aus einer XHTML-Datei abzurufen und sie beim Erstellen in eine andere einzufügen. MSIE-Probleme sollten nicht bedeuten, dass XHTML schuld ist. Wie bereits erwähnt, haben Sie mit XHTML einige Zukunftssicherungen, wenn sich die Browser verbessern. In beiden Fällen endet es nicht mit Browsern. Es gibt das programmierbare Web und semantische Suchmaschinen.
Aleemb

Validierung! = auf Wohlgeformtheit prüfen. Zeigen Sie mir, wo die XHTML-Spezifikation sagt, dass Semantik von Präsentation getrennt werden soll. Zeigen Sie mir, wo die XHTML-Spezifikation eine andere Struktur als die in HTML4 definiert. Mit Hilfe des HTML / SGML-Parsers kann XSLT HTML lesen und schreiben. XHTML führt keine neue Semantik ein. Google analysiert XHTML wie HTML. RDFa arbeitet in HTML. W3C plant, HTML5 für die nächsten 20 Jahre zu verwenden. Die meisten JS-Bibliotheken funktionieren nicht mit XML-DOM. XML mit Namespaces ist PITA zum Parsen.
Kornel

@porenL, einige interessante Punkte albiet Sie sind pedantisch und müssen sich für die pragmatischen Szenarien öffnen. Für Starts ist XHTML XML, was bedeutet, dass es sich um eine Datenstruktur handelt. Wenn Ihnen die Auswirkungen davon nicht sofort klar sind, stellen Sie sich ein einfaches Szenario vor, in dem Sie einfach eine XHTML-Verbindung an den Server senden können, die sie einfach als XmlFragment-Objekt akzeptiert, weitergibt und möglicherweise sogar direkt an die Datenbank weitergibt oder serialisieren Sie es nach Änderungen zurück auf den Server. All dies geht Ihnen verloren, weil Sie in eine pedantische Debatte über die Spezifikation
verwickelt sind

(... cont) Ich erwähnte Tools wie nAnt, die XPath unterstützen, für die XHTML sehr nützlich ist - ich habe weder die Zeit noch die Neigung, es mit HTML arbeiten zu lassen. Das ist nur ein Werkzeug und ein Szenario, es gibt viele andere. Da es sich um eine Datenstruktur handelt, ist das Mining auch viel einfacher. Ich stimme Ihnen in der Frage der Namespaces zu, bin jedoch nicht auf Probleme mit JS-Bibliotheken gestoßen.
Aleemb

0

XHTMl ist ein guter Standpunkt, denn wenn Sie gültigen Code wünschen, müssen Sie der behinderten Community einen Aspekt der Hilfe bereitstellen, da Bildschirmleser die Alt- und Titelteile der Bild- und Link-Tags benötigen. Das Parsen muss bis zu einem gewissen Grad schneller sein, da der Parser im Gegensatz zu HTML nicht prüfen muss, ob das Tag nicht ordnungsgemäß geschlossen wurde, ob es korrekt verschachtelt wurde usw. Außerdem ist es besser, es zu verwenden, da es streng ist Aber es hilft Ihnen, logischer zu denken (meiner Meinung nach), wenn es darum geht, Programmiersprachen zu lernen.


1
XHTML 1.0, 1,1 und HTML 4.01 haben dieselben Anforderungen und Regeln, wenn es um Alt- und Titelattribute geht. XHTML lässt sich theoretisch schneller analysieren, wenn es als XML behandelt wird. Da der IE dies jedoch nicht unterstützt, müssen Sie es als Text / HTML bereitstellen, damit es funktioniert, sodass der Nutzen nicht realisiert wird.
Quentin

Viele Benutzer von Bildschirmleseprogrammen verwenden den IE (hauptsächlich, weil lange Zeit kein anderer Browser gut mit ihnen zusammengearbeitet hat), und der IE unterstützt XHTML überhaupt nicht (es scheint anders zu sein, wenn Sie nicht den richtigen MIME-Typ senden). Wenn Sie XHTML wirklich verwendet haben, ist die Seite für die meisten Benutzer von Bildschirmleseprogrammen völlig unzugänglich.
Kornel

0

Ich glaube, XHTML ist (oder sollte) schneller zu analysieren. Ein gültiges XHTML-Dokument muss in eine strengere Spezifikation geschrieben werden, da Fehler beim Parsen schwerwiegend sind, während HTML milder ist und vor meinem Kommentar erwähnte Kuriositäten wie nicht in der Reihenfolge befindliche Abschluss-Tags und dergleichen berücksichtigt. Ich fand dies hilfreich, um die Unterschiede zwischen HTML- und XHTML-Analyse aufzudecken:

http://wiki.whatwg.org/wiki/HTML_vs._XHTML#Parsing

Ein Grund, warum Sie XHTML über HTML verwenden könnten, könnte sein, dass Sie mobile Benutzer als Teil Ihrer Zielgruppe haben möchten. Wenn ich mich recht erinnere, verwenden viele Telefone eher einen XML-Parser als einen HTML-Parser, um das Web anzuzeigen. Wenn Sie für Desktop-Browser schreiben, ist HTML wahrscheinlich akzeptabel.

Das heißt, wenn Sie die Daten trotzdem als Text / HTML bereitstellen möchten, sollten Sie HTML verwenden:

http://www.hixie.ch/advocacy/xhtml


1
HTML "erlaubt" nicht, dass das Schließen von Tags nicht in Ordnung ist. Es ist einfach nicht erforderlich, dass Parser einen Fehler auslösen - und ich habe noch nie ein Telefon besessen, das mit XHTML umgehen kann, aber nicht mit HTML (und ich benutze seit vielen Jahren mobiles Internet)
Quentin,
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.