Die XHTML-gegen-HTML-Debatte hat nun vollends an Fahrt aufgenommen, nachdem Dave Shea angekündigt hat das X links liegen zu lassen. Und einige Tage später gab es auch in der deutschsprachigen Twitter-Community eine Diskussion, was man denn nun verwenden sollte. (Ich habe sie mal im Wiki dokumentiert.)

Da ich zusammen mit Thomas Scholz pro HTML und Michael Jendryschik pro XHTML argumentierte, möchte ich hier noch einmal einige Argumente anführen.

Als die Webstandards-Bewegung an Fahrt aufnahm war XHTML die Zukunft des Webs. Das W3C hatte die HTML-Arbeitsgruppe eingestellt und entwickelte XHTML1.1 und auch die Arbeiten an XHTML2.0 begannen recht zügig.

„Six years ago, many of us thought XHTML would be the future of the web and we’d be living in an XML world by now.“ Dave Shea

Heute ist von dieser XML-Euphorie nichts mehr übrig. Die Erweiterungsfähigkeit von XHTML ist dank der miesen Browserunterstützung genauso ein feuchter Webentwickler-Traum wie die verlässliche externe Verarbeitung von XHTML-Dokumenten. XHTML wird leider immer noch mit dem Mime-Type text/html ausgeliefert (weil der IE das nicht versteht), ein entsprechender XML-Parser muss also immer davon ausgehen, das das Dokument fehlerhaft ist (und in der Tat sind dies die überwiegende Mehrheit der Dokumente bis dato).

In XHTML ist vorgeschrieben, dass bei einem Fehler die Verarbeitung des Dokuments abgebrochen wird und eine Fehlermeldung ausgegeben wird. In HTML ist momentan genau das Gegenteil davon der Fall, Parser sind dazu angehalten möglichst fehlertolerant zu sein. Da aber die Art, wie Fehler korrigiert werden, nirgendwo vorgeschrieben wurde hatten die Browserhersteller dort freie Hand und es ist ein Wunder, dass die Fehlerbehebung einigermaßen ähnlich in den Browsern ist.

Noch ein Argument, das man immer wieder hört: HTML sei Tag Soup, es erlaubt unsauberen Code zu schreiben. Ich möchte das klarstellen: HTML hat aufgrund seiner SGML-Abstammung mehr Variationen in der Schreibweise als XML erlaubt, so können Attribute sofern sie kein Leerzeichen enthalten ohne Anführungszeichen geschrieben werden, z.B. <span class=warning>. Hier liegt es an jedem HTML-Autor sich für eine Notation zu entscheiden, die für ihn sinnvoll ist. Ich persönlich schreibe durchgehend mit Hochkommata in meinen HTML-Dokumenten und verwende Kleinschreibung. (Das gilt übrigens auch, wenn ich jemandem HTML beibringe, schließlich lehre ich Best-Practices, nicht All-Practices.)

Dinge, die in HTML einfacher geregelt sind, sind so genannte „Elemente ohne End-Tag“, also <img>, <br> usw. Sie werden ohne abschließenden Vorwärtsschrägstrich / geschrieben. In XHTML wird dieser Schrägstrich zur Kennzeichnung von Elementen ohne Inhalt benutzt. In der Regel dürfen diese aber Inhalte haben und die dann eben mit getrennten Start- und End-Tags gekennzeichnet werden. Bei den XHTML-Elementen ist das alles nur Fassade um XHTML-Parser-gerecht zu arbeiten. Wer dann aber den Schrägstrich benutzt und das Dokument dennoch mit dem text/html-Mimetype ausliefert, verlässt sich darauf, das der Parser den Slash ignoriert und ihn nicht SGML-konform interpretiert.

Letztlich ist es eine Stilfrage, was man schreibt, schließlich sind XHTML1 und HTML4 aus Spezifikationssicht deckungsgleich. XHTML1.1 bzw. dessen Fähigkeit zur Erweiterung wurde nie umgesetzt, ich würde empfehlen es zu vermeiden. Der Umstieg von HTML4/XHTML1 auf HTML5 ist übrigens kein Problem. Zum einen erlaubt HTML5 dezidiert den schließenden Vorwärtsschrägstrich, zum anderen kann man HTML5 für Maschinen mit dem Mimetype application/xml rausschicken. Dieses X-HTML5 (Arbeitstitel) muss dann aber wohlgeformtes XML sein.

Weiterführende Links:

Hinweis

Diese Webseite benutzt (zum Zeitpunkt der Veröffentlichung des Artikels) Pseudo-XHTML, liefert also XHTML als text/html aus. Dies wird sich in naher Zukunft ändern.

20 Gedanken zu „Aufs falsche Pferd gesetzt.

  1. hmmm, wenn es deinem Meinung nach egal ist, wie man Tags und Attribute zu schreiben hat, macht es nicht das parsen für die Browser noch schwerer ?

    Und selbst wenn das nicht der Fall ist: Wie steht es denn mit der Wiederverwendbarkeit ?

    Ich bin kein XML-Verfechter, aber ich schätze die Grunregeln von XML sehr. Um es etwas laxer auszudrücken: bei deiner Art von Notation krieschplack! Wenn schon Back to the future, so sollte man doch wenigstens zeigen / erkennen, dass man etwas gelernt hat.

    Nimm das bitte nicht persönlich. Aber für beleidigte Leberwurst ist doch eigentlich keine Zeit oder ?

  2. Für mich ist der MIME-Type keine Glaubensfrage, denn Browsern ist er letztlich schnurzegal. Ein text/html MIME-Type macht aus sauberem Code noch keine Tagsuppe. Umgekehrt aber sorgt bei einem XMLMIME-Type ein einziger Fehler im XHTML dafür, daß ein gelber Fehlerscreen im Firefox angezeigt wird. In einem CMS kann das immer vorkommen, weswegen ein XMLMIME-Type in kundengepflegten Projekten nicht in Frage kommt.

    Ich schreibe aber valides XHTML und denke, die XML-Syntax ist besser geeignet, um sauberen Code in einem Team von Entwicklern zu forcieren: well-formedness, Attribute in Anführungszeichen etc. In alten HTML-Projekten waren Nachlässigkeiten an diesen Stellen oft die Ursachen für Probleme.

    Und letztlich darf man ja auch HTML 5 wohlgeformt schreiben. Darum den Tod von XHTML auszurufen und auf fehlertolerierendes HTML 4 zurückzuwechseln halte ich für ignorant. Ebenso ist der Hype um HTML 5 keine Gewähr, zum jetzigen Zeitpunkt diese experimentelle Version in Kundenprojekten einsetzen zu können. Man muß nur @WHATWG followen, um zu sehen, daß sich an diesem Standardentwurf beinahe täglich etwas ändert.

  3. Was Du da in Richtung XML und den leider unerfüllten Träumen ansprichst, sehe ich mittlerweile auch als generelles Problem einer “Auszeichnungssprachen-Suppe”. Für die einen mag es vielleicht positiv sein, dass XML gute, vielleicht sogar bessere Konkurrenten bekommen hat… im Web ja allen Voran JSON und Konsorten. Aber wirklich spassig ist das nicht. XML hat vor Allem im professionellen Umfeld ja dann doch gehörig an Fahrt gewonnen und ist dort, wo es nicht zwingend um Websites geht, ein gern genommenes Format, um Daten zu transportieren. Irgendwie merkwürdig, dass es trotzdem ständig versucht wird irgendwie zu umgehen, vor Allem weil die Syntax ja nun wirklich absolut simpel ist.

    Aus Deinem Artikel lese ich vor Allem wieder das Problem der Probleme schlechthin heraus: Den Internet Exploder ;-) Nehmen wir mal an, der IE wäre von Anfang an mit application+xml klargekommen. Wäre diese Situation dann überhaupt eingetreten, würden die meisten Argumente kontra XHTML dann überhaupt noch greifen? Vielleicht hätte man ohne den IE, bzw. mit einem besseren IE, dann ja wirklich ein besseres Web gehabt, in dem sogar die validen XHTML-Dokumente inkl. Mime-Type funktioniert hätten. Aber so wie es sich liest, kann ich diese gesamte Problematik ja wirklich auf diese Probleme runtersummieren. Wobei runtersummieren schon ein merkwürdiges Wort ist.

    Ich bin auch gerade dabei, den Wechsel von XHTML 1.0 Transitional zu HTML5 zu wagen. Ich gestehe, dass es bei mir da vor Allem “Trendsache” ist, ich am Zahn der Zeit bleiben will. Für eine ernsthafte Diskussion, einen Shootout zwischen HTML5 und XHTML stecke ich nicht tief genug in der Argumentationskette.

    Talking ‘bout revolution… hast Du ein oder zwei gute Quellen für HTML5-Roundups, quasi einen Schnellüberblick über die “New HTML5 best practices”, vor Allem in Sachen semantisches Markup, nicht zwingend Syntax?

    Anyway, guter Artikel und vielen Dank!

  4. Huch, da waren schon zwei, die genau ansprachen, was ich vergessen habe.

    Ja, genau diese Fehlerintoleranz von XML ist doch eigentlich das, was wir wollen, oder nicht? Und auch ein Grund, warum man von HTML4 auf XHTML umgestiegen ist. Ich wäre super glücklich darüber, wenn die Browser eben KEINE Fehlertoleranz eingebaut hätten. Wenn Entwickler jeglicher Art, seien es die CMS-Bauer, die Frontend-Entwickler oder auch die WYSIWYG-Editor-Männchen dazu gezwungen wären, sauberen Code auszugeben, dann gäbe es einen Großteil unserer Probleme doch gar nicht. Fehlertoleranz gibt den Browserherstellern doch nur eine Waffe mehr, um ihr eigenes Süppchen zu kochen, von daher verstehe ich diesen Part der Argumentation dann wirklich nicht.

    Das Böse an XHTML ist sicher nicht, dass es keine Fehler zulässt. Und andersherum ist der Umkehrfall sicher nicht der Vorteil von HTML5.

  5. Hier dreht sich die Diskussion immer noch um Fragen, die man endlich mal ad acta legen sollte, um sich der Praxis zuzuwenden. Wir sind im Jahr 2009, jetzt könnte man mal in eine neue Phase übergehen.

    »XHTML wird leider immer noch mit dem Mime-Type text/html ausgeliefert«

    Wieso denn »leider«? Es ist okay und völlig unproblematisch, XHTML als text/html auszuliefern. Ich wüsste nicht, warum man einen XMLMIME-Typ verwenden sollte – ich kenne keine praktischen Argumente. Strikte Fehlerbehandlung im Browser vereinfacht mir die Webentwicklung nicht, ich sehe sie nicht als Fortschritt an. Ich picke mir das von XHTML heraus, was mir die Webentwicklung vereinfacht. Wenn ich Martins Kommentar richtig verstanden habe, sieht er das ähnlich pragmatisch.

    Insofern redet die (selbsternannte) »pro HTML«-Fraktion offenbar völlig an den Leuten vorbei, die XHTML zu ihrem Gewinn verwenden, daraus aber kein Heilsversprechen machen.

    »Letztlich ist es eine Stilfrage«

    Ist es leider, so wie sie üblicherweise diskutiert wird. Sollte es aber nicht. Es sollte eine Frage von Vorteilen für den jeweiligen Autor und den jeweiligen Anwendungsfall sein. Das, was derzeit unter der Rückkehr zu HTML 4 verhandelt wird, ist gelinde gesagt unreflektiert.

  6. @Micha:
    Browser parsen doch jetzt schon alles was du ihnen vorwirfst, schwerer wird es nicht. Im Gegenteil, HTML5 spezifiziert genau was ein Parser mit welchem Fehler machen soll.

    @Martin:
    Es spricht doch nichts dagegen, das man auch unter HTML4 wohlgeformt schreibt. Man testet das eben dann nicht mit einem Validator sondern mit einem Tidy. Und HTML5 in Kundenprojekten habe ich auch nicht empfohlen (wobei eigentlich nix passieren kann, den Parsern ist es eh wurschtegal)

    @Arne:
    Ich glaube nicht, dass sich application/xml durchgesetzt hätte, da einfach die Tools nicht sicher valides XHTML ausgeben, und als Bank z.B. willst du einfach nicht, das deine Seite wegen einem nicht-kodierten &-Zeichennicht erreichbar ist.

    Im Übrigen geht es hier nicht um das Datenspeicherformat XML, das ist durchaus gut (wenn auch ein bisschen sehr groß, verglichen mit JSON, alles hat seine Berechtigung und für verschiedene Einsatzgebiete sind andere Formate sinnvoll).

  7. @molily:
    Klar. Aber wir wollten MathML und SVG und wer weiß noch was alles benutzen. Das geht mit @text/html@ alles nicht, abgesehen von der Browserunterstützung. Und ich finde Pseudo-XHTML nicht so unproblematisch wie du. Ich benutze ja auch (Achtung, kruder Vergleich folgt) nicht mehr als 256 Farben in einem .gif, weil ich mich darauf verlasse, das der Browser es trotzdem interpretiert.

  8. Ich setzte jetzt HTML5 ein, auch in Kundenprojekten, natürlich nicht die Deklarationen, die noch nicht alle Browser verstehen. Aber schon wegen des einfachen Doctypes war der Wechsel einfach naheliegend. Solange der Browser den Standard Compliance Mode benutzt, ist doch alles kein Ding.

  9. Soll doch jeder so schreiben, wie er mag. Ich selbst nutze XHTML, weil ich die Schreibweise einfach schöner finde. Da kommt bei mir auch der Programmierer durch. Dass ich anderen dann eher XHTML als HTML (4) beibringe, liegt auf der Hand. Und so lange es egal ist (weil XHTML und HTML 4 deckungsgleich sind) habe ich doch die Wahl. ;-)

    Und mal ganz ehrlich: Entscheidend ist einzig nur das, was auf dem Endgerät dargestellt wird, und nicht das, worin es geschrieben ist. Und mich machen darüber hinaus glücklich, die ihren Code sauber schreiben. Mir ist voll egal, ob das HTML 4, 5 oder XHTML ist.

  10. Ich denke, ich werde in Zukunft meine Dokumente als HTML5 deklarieren und als text/html ausliefern lassen, trotzdem alles mit XML-konformer Schreibweise tippen.

    Sollte XHTML dann doch irgendwann wieder en vogue sein, kann man schnell wieder zurückwechseln!

  11. Ich finde leider, dass die Diskussion etwas am Kern vorbeigeht. Was sind denn die wahren Vorteile von XML gegenüber SGML? Es sind: Erweiterbarkeit (Namespaces), Transformation (XSLT) und einfaches Selektieren (XPath).
    All diese Standards sind seit langem vorhanden und ausgereift.
    Und ich persönliche finde diese Tools äußerst nützlich.

    Wenn wir uns einer Diskussion XML vs. SGML widmen, dann sollten wir doch nicht darauf schauen, was die Browser aktuell können oder was sie nicht können, sondern vielmehr wo wir in Zukunft hin wollen.

    Gerade die Erweiterbarkeit ist und wird ein großes Thema sein, ich möchte hier SVG, MathML und vor allem RDFa erwähnen.
    Es ist jetzt schon abzusehen, dass mit der aktuellen Spezifikation von HTML5 RDFa und Konsorten auf der Strecke bleiben.

  12. Was mich an dieser Diskussion wundert: – Die aufgeführte Twitter-Diskussion im Wiki hat kaum fachliche Argumente, dafür sehr viel Polemik. – Die Aussage “yatil: So, jetzt genug damit. Die Realität hat doch schon längst entschieden, XHTML ist tot. Und in der Nachbetrachtung war es das schon immer. “ finde ich in sofern sehr interessant, weil genau die gleichen Leute (nicht yatiö persönlich) vor Jahren pro XHTML geschrieben haben als ob ein Leben davon abhängt. – Diese Seite folgenden Doctype hat “//W3C//DTD XHTML 1.0 Strict//EN” also “tot” ist.

    Nach meiner Meinung ist es einigen selbsternannten Gurus zu ruhig geworden und es muss mal wieder ein neuer Hype her – viel Spaß!

  13. @Mario:
    Es geht doch gar nicht um XML als strukturierte Datenspeicherungssprache. Da hat sie ihren Sinn und Zweck und funktioniert ja auch gut. Ich bezweifle aber, dass XHTML oft zur Datenspeicherung und anschließender Transformation benutzt wird oder jemand wirklich Namespaces nutzt. Ich suche seit einer geraumen Zeit nach diesen Anwendungsmöglichkeiten, Beispielen in der Praxis und habe noch keine gefunden.

    SVG, MathML und RDFa haben bisher keine Verbreitung gefunden und werden es in XHTML1.1/2.0 auch nicht, weil es eben einen Browser gibt, der das alles nicht unterstützt. Da hilft auch die theoretische Erweiterbarkeit nichts, die uns ja erlauben würde den XML-Parsern diese Dinge über XML Schemata usw. beizubringen.

    HTML5 versucht im Moment händeringend eine Lösung für XML-Inhalte inklusive Namespaces zu finden, doch das ist gar nicht so einfach. Für gute Vorschläge ist die Arbeitsgruppe jederzeit offen und ich bin zuversichtlich, dass das schon irgendwie funktionieren wird.

    @Michael:
    Ich kann dir nicht folgen, ich finde es positiv, wenn sich Menschen auch über vermeintlich unwichtige Probleme oder Fragestellungen Gedanken machen.

    @Alle:
    Letztlich bleibt es jedem selbst überlassen was und wie er schreibt. Ich möchte niemanden davon überzeugen irgendetwas zu tun.

  14. Es kann nicht gut sein, wenn Browser sehr fehlertolerant sind. Das fördert schliesslich das Fehler machen und die unterschiedliche Darstellung in Browsern. Wenn – wie bei XHTML – die Verarbeitung abgebrochen wird, so erzielt man hiermit auch einen Lerneffekt. Ich bevorzuge XHTML, auch wegen der schöneren und leserlicheren Schreibweise.

  15. @Nico: Das Argument der schöneren Schreibweise und besseren Lesbarkeit von XHTML ist sicherlich Geschmacksache. Ich persönlich verstehe dieses Argument jedoch wirklich nicht, vielleicht kannst du mir da die Augen öffnen.

    Beispiel 1: Wird ein img-Tag oder ein br-Tag durch die Nicht-Verwendung eines Slash weniger übersichtlich?

    Beispiel 2: Wieso soll beim Weglassen z. B. des p-End-Tags das Dokument unübersichtlicher werden? Es ist von der Spezifikation her klar geregelt, wann Tags weggelassen werden können und wann nicht.

    Worauf ich hinaus will: Das Weglassen von Code hat nicht zwangsläufig Unübersichtlichkeit zur Folge, eher im Gegenteil. Ein mit vielen Möbeln vollgestopftes Zimmer ist doch nicht übersichtlicher und strukturierter als ein Zimmer mit nur einem Bett, einem Esstisch und einem Spiegel.

  16. @Eric Ich kann dein Argument nicht ganz nachvolllziehen. Jede HTML-Seite enthält doch Daten. Der Trend geht doch ganz klar in Richtung semantische Formate (Microformats, RDFa, etc.). Ich sehe es nicht so, dass der Browser alle Namespaces, die ich einbinden kann unterstützen muss. Natürlich muss er das für Namespaces bei denen es um die Darstellung an sich geht (MathML, SVG), aber nicht bei RDFa. Dort geht es doch um Daten die in HTML eingebettet werden, die den Browser erstmal gar nicht unbedingt interessieren müssen. An denen aber andere evtl. interessiert sind.
    Und wie du schon sagtest HTML5 auf Namespaces zu erweitern ist nicht ganz einfach und ich fürchte dass hier keine besonders elegante Lösung herauskommt.

  17. Ich verwende XHTML, weil ich, wie bereits von einem Vorredner erwähnt, den Code in einer Teamarbeit besser unter Kontrolle habe. Zudem kann der Validator bei XHTML Fehler genauer definieren (meine ich zumindest, wenn es auch nicht immer der Fall ist – manchmal wünsche ich, der W3C-Validator könnte präziser/“intelligenter” arbeiten).

    Servus
    Leo

  18. Ich halte das XHTMLXML Konzept für zukunftsweisend. Mit absoluter Sicherheit wird er aber nicht umfassend durchgesetzt werden. Dennoch bietet er in Verbindung mit dem DOM für Webentwickler wunderbare Möglichkeiten, dem Marketingwort “Ajax” digitales Leben einzuhauchen. Viele Anwendungen werden so deutlich einfacher. Ich hoffe, dass die künftigen Browsergenerationen diesen Standard vollständig und kohärent interpretieren werden.

  19. Da das DOM genauso auch in HTML vorhanden ist, gibt es keinen Grund wegen AJAX XHTML einzusetzen.

    Zu deiner Hoffnung mit dem XHTML-Standard und der Implementation: Es gibt keinen Browserhersteller, der vor hat in absehbarer Zeit (20+ Jahre) XHTML zu unterstützen. Sie stehen alle hinter HTML5.

Kommentare sind geschlossen.