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

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.

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.

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.

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).

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.

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.

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).

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.

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

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.

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

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.

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

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.

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.

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.

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 .

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.

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