Kontakt aufnehmen
Jan-Hendrik Rauh

Jan-Hendrik Rauh

Geschäftsführer
Digital Solutions
+49 531 3796005514

    Ich habe die Datenschutzerklärung gelesen und erkläre mich damit einverstanden, dass die von mir im Kontaktformular eingegebenen Daten elektronisch erhoben und gespeichert werden.

    HTML und XHTML

    Stand: 29.11.2022

    HTML und XHTML

    Vielleicht haben Sie bereits von XHTML gehört und kennen Aussage wie die, dass man kein HTML mehr verwenden solle, sondern nur noch XHTML. In diesem Zusammenhang sollten Sie ein paar grundsätzliche Hintergründe kennen.

    SGML und XML

    HTML ist ein wohldefinierter Standard. Die Regeln für korrektes HTML werden jedoch nicht mithilfe natürlicher Sprache, sondern in einer ebenfalls computerlesbaren Meta-Sprache namens SGML (Structured Generalized Markup Language) formuliert.
    Die Computerlesbarkeit ist wichtig, damit z.B. ein Programm eine in HTML geschriebene Webseite gegen die in SGML formulierten HTML-Regeln auf syntaktische Korrektheit testen kann. Diesen Vorgang nennt man Validierung (Gültigkeitsüberprüfung).
    SGML ist sehr leistungsfähig, aber auch recht komplex und für viele praktische Anwendungsfälle überdimensioniert. Als praxisnähere Alternative zu SGML hat sich mittlerweile XML (Extensible Markup Language) etabliert. XML ist wie SGML eine computerlesbare
    Meta-Sprache zum Formulieren der Regeln von Markup-Sprachen wie HTML.

    XHTML (Version 1.0) ist zunächst einmal nichts anderes als eine Neuformulierung der Sprachregeln von HTML

    (Version 4.01) in XML. Mit XHTML 1.0 können Sie also nicht mehr und nicht weniger und nichts anderes tun als mit der aktuellen HTML-Version 4.01: nämlich die Inhalte Ihrer Webseiten strukturieren. Es gibt in diesem Stadium von XHTML auch keine wesentlich
    anderen Sprachbestandteile als in HTML. Da allerdings die Markup-Regeln von XML etwas anders aussehen als die von SGML, gibt es einige syntaktische Abweichungen und Besonderheiten.

    Interpretation von HTML und XHTML

    Ein Parser leistet die Verarbeitung von Markup-Sprachen entsprechend der Regeln der Markup-Sprache. Jeder Browser, der eine Webseite am Bildschirm anzeigt, muss deren HTML-Quelltext parsen. Aus dem Markup geht hervor, aus welchen Elementen
    die Webseite besteht und welche Elemente innerhalb welcher anderer Elemente vorkommen. So kann beispielsweise ein einzelnes Wort wie „Mensch“ Inhalt einer Kopfzelle einer Tabelle sein, die sich in einem bestimmten Bereich innerhalb des Dateikörpers befindet.
    Zum Verarbeiten von HTML verfügt jeder Browser über einen HTML-Parser. Bei XHTML ist die Angelegenheit etwas komplizierter: Wenn das HTML-Dokument vom Browser als HTML akzeptiert wird, verwendet der Browser seinen HTML-Parser. Wird es jedoch
    als XML-Dokument akzeptiert, so wird der XML-Parser verwendet, sofern der Browser über einen entsprechenden Parser verfügt. In der Darstellung kann dies erhebliche Auswirkungen haben. So stellen einige Browser XML-geparste Dokumente nur als Markup-Strukturbaum
    dar, also letztlich als eine sauber formatierte Quelltextansicht. Andere bieten XML- geparste Dokumente möglicherweise nur zum Download an und stellen gar nichts dar.

    Ob ein Browser bei einem XHTML-Dokument den HTML-Parser oder den XML-Parser verwendet,

    hängt in erster Linie vom zugewiesenen Mime-Type ab. Der Mime-Type legt den Datentyp fest. Jeder Browser hat lokal eine eigene Liste von Mime-Typen gespeichert, mit deren Hilfe er z.B. Dateiendungen und Datentypen zuordnen kann. Beim
    MS Internet Explorer ist diese Liste eng verzahnt mit den Dateiendungsverknüpfungen des Betriebssystems. Wird eine beliebige Datei im Browser lokal geöffnet, kann dieser an Hand seiner Mime-Type-Liste entscheiden, wie er mit der Datei verfahren soll.
    Anders sieht es aus, wenn der Browser Daten von einem Webserver anfordert und empfängt. In diesem Fall übermittelt der Webserver Kopfdaten an den Browser, in denen unter anderem eine Angabe zum Mime-Type der übertragenen Daten stehen kann, die dem Browser
    zur Orientierung dient. Für HTML-Dokumente lautet der Mime-Type text/html. Für XHTML sollte jedoch laut Spezifikation nicht dieser Mime-Type verwendet werden, sondern application/xhtml+xml. Alternativ dazu sind auch die Angaben
    text/xml und application/xml möglich. Dies führt jedoch je nach Server- und Browser-Einstellungen zu Problemen. Der immer noch am weitesten verbreitete MS Internet Explorer kann mit dem Mime-Type application/xhtml+xmlsogar bei angepasster Server-Konfiguration nichts anfangen und bietet ein Dokument mit diesem Mime-Type zum Download an. Daher wird in der Praxis doch noch der Mime-Type text/html verwendet. Wenn Sie sichergehen wollen, dass Ihre XHTML-Seiten
    als Webseiten im Browser erscheinen, dann weisen Sie statischen XHTML-Dateien am besten ebenso wie HTML-Dateien die Dateiendung .htm oder .html zu.

    Argumente für XHTML

    Bei neu zu erstellenden Webseiten sprechen durchaus einige Gründe dafür, von vorneher- ein XHTML statt „herkömmlichem“ HTML zu verwenden. Diese Gründe hängen letztlich alle mit der Integration von XHTML in der XML-Welt zusammen:

    • Kombination mit anderen XML-Sprachen: In einem XHTML-Dokument können Sie beispielsweise direkt mathematisch/naturwissenschaftliche Formeln in MathML oder Vektorgrafiken in SVG notieren. Der Grund ist, dass in XML-basierende Dokumente,
      zu denen XHTML-Dokumente ja gehören, Daten aus beliebigen anderen XML-basierenden Sprachen eingebettet werden können.
    • Konvertierung in andere XML-Sprachen oder Ausgabeformate: Mithilfe von XSLT, einer standardisierten, XML-basierten Markup-Sprache zum Übertragen von Inhalten aus XML-basierten Sprachen in andere XML-basierten Sprachen oder beliebige
      andere Ausgabeformate ist XHTML optimal für die Konvertierung in andere Ausgabeformate gerüstet. Dies ist beispielsweise für Inhalte sinnvoll, die nicht nur als Webseite, sondern z.B. auch als Print-Dokument veröffentlicht werden sollen.
    • Zukunftssicherheit: Die Spezifikation zu XHTML wird in jedem Fall weiterentwickelt. So ist XHTML 2.0 bereits in Entwicklung. Eine parallele Weiterentwicklung von herkömmlichem HTML ist dagegen nicht vorgesehen. Zwar ist XHTML 2.0
      für die aktuelle Praxis noch irrelevant, doch kann sich dies in wenigen Jahren ändern. Eine Konvertierung von XHTML-1.0-Dokumenten nach XHTML 2.0 ist vermutlich unproblematischer zu bewerkstelligen als eine Konvertierung von herkömmlichem HTML
      4.01 auf XHTML 2.0.

    Andererseits ist sauberes HTML auch nicht zwangsläufig schlechter konvertierbar als sauberes XHTML. Die Einbettung anderer XML-Formate ist ebenfalls nur schöne Theorie, die in den heutigen Browsern höchstens ansatzweise funktioniert. So betrachtet spricht
    aus Basiswissen HTML und CSS praktischer Sicht nichts gegen die Verwendung von HTML. Die Quelltexte auf dieser Webseite verwenden ebenfalls „gewöhnliches“ HTML.

    Modularisierung von XHTML

    HTML 4.0 und XHTML 1.0 sind – auch wenn sie von unwissenden Schwätzern gerne wegen ihrer Schlichtheit belächelt werden – eigentlich sehr umfangreiche Sprachen mit einem nicht ganz einfachen Regelwerk aus über 80 Elementen, ihren möglichen Attributen,
    Verschachtelungsregeln und einer ganzen Reihe benannter Zeichen. Beide Sprachen bieten damit ein brauchbares Arsenal für Hypertext-Dokumente an. Egal ob einfache Porträt-Homepages oder wissenschaftliche Abhandlungen – der Strukturvorrat von HTML/XHTML ist durchaus reichhaltig und fur die meisten Zwecke ausreichend. Allerdings nicht für alle Zwecke.

    Der Umfang beider Sprachen und ihre nicht ganz trivialen Regeln stellen andererseits hohe Anforderungen an die auslesende Software und deren Darstellungsfähigkeiten. Von einem modernen Webbrowser, der auf einem modernen PC läuft, kann man diese Fähigkeiten
    verlangen. Aber von Software, die beispielsweise in einem Handy einem Pocket-Computer oder einem simplen Sprachwiedergabegerät läuft, kann man nicht unbedingt die gleichen Fähigkeiten erwarten.

    HTML/XHTML decken also einerseits trotz ihres beträchtlichen Sprachumfangs nicht alle denkbaren Wünsche ab,

    und andererseits sind sie fur manche Zwecke schlichtweg überdimensioniert. Aus diesem Grund gehen die überlegungen des W3-Konsortiums in die Richtung, zumindest bei XHTML zu ermöglichen, dass sowohl abgespecktere als auch erweiterte Sprachvarianten davon
    möglich sind. Handy-Software könnte dann beispielsweise eine abgespecktere Sprachvariante interpretieren, während ein Mathematiker, der seine Arbeit publizieren möchte, XHTML um Elemente aus einer speziellen Auszeichnungssprache für mathematische Formeln
    erweitern kann. Das Konzept zum Abspecken und Erweitern von XHTML wird als Modularisierung bezeichnet. Dass es nur bei XHTML und nicht bei HTML angewendet werden soll, liegt daran, dass für die Modularisierung XML-typische Techniken angewendet
    werden sollen. Die Modularisierung stellt nämlich bestimmte formale Regein zur Verfügung, die abgespeckte oder erweiterte Varianten von XHTML einhalten müssen.

    In wieweit sich das Konzept der Modularisierung durchsetzen wird, bleibt abzuwarten.

    Denn wer sich mit dem Design eigener Auszeichnungssprachen befasst, kann schließlich auch direkt die Möglichkeiten von XML nutzen, um entsprechende Sprachen zu entwerfen. Und „einfacher“ als XML ist das Konzept der Modularisierung sicher nicht – im Gegenteil:
    Es setzt im Grunde die Beherrschung von XML voraus und reizt dessen Möglichkeiten aus.

    Die Module von XHTML 1.1

    Die folgende Tabelle listet die Module auf, aus denen XHTML 1.1 besteht. Auf die Praxis als XHTML-Anwender hat diese Modularisierung keinen Einfluss. Sie können Ihre XHTML-Dokumente schreiben wie gewohnt – mit der Einschränkung, dass
    Sie nichts mehr verwenden dürfen, was noch aus den HTML-Varianten „Transitional“ und „Frameset“ stammt.

    Name des Moduls Elemente Erläuterung
    Structure body head html title Modul für die Elemente, die das Grundgerüst eines XHTML-Dokuments bilden.
    Text abbr acronym address blockquote br cite code dfn div em h1 h2 h3 h4 h5 h6 kbd p pre q samp span strong var Modul für alle Block- und Inline-Elemente, die Text enthalten können und logische Auszeichnungen darstellen, also keinen Hinweis auf ihre visuelle Darstellung enthalten.
    Hypertext a Modul für Anker und Verweise innerhalb des Dokuments.
    List dl dt dd ol ul li Modul für nummerierte Listen, Aufzählungslisten und Definitionslisten (Glossarlisten).
    Object object param Modul für Multimedia-Referenzen.
    Presentation b big hr i small sub sup tt Modul für Elemente, die Text enthalten können und physische Auszeichnungen darstellen, also einen Hinweis auf ihre visuelle Darstellung enthalten.
    Edit del ins Modul für änderungsmarkierungen im Text.
    Bidirectional Text bdo Modul für mehrsprachige Dokumente, die Text in Sprachen mit unterschiedlicher Schreibrichtung enthalten.
    Forms button fieldset form input label legend select optgroup option textarea Modul für Formulare und Formularelemente.
    Table caption col colgroup table tbody td tfoot th thead tr Modul für Tabellen und Tabellenelemente.
    Image img Modul für Grafikreferenzen.
    Client-side Image Map area map Modul für Grafiken mit verweis-sensitiven Flächen, vom Browser allein darzustellen.
    Server-side Image Map ismap (bei img) Modul für Grafiken mit verweis-sensitiven Flächen, vom Browser in Kommunikation mit dem Web-Server darzustellen.
    Intrinsic Events on* (Event-Handler-Attribute) Modul für alle Event-Handler, die als Attribut in Elementen notiert werden können und eine Schnittstelle für Script-Sprachen bilden.
    Meta-Information meta Modul für Meta-Daten für Suchmaschinen und Browser.
    Scripting noscript script Modul für Script-Bereiche und Bereiche für Browser, die keine Scripts ausführen können.
    Stylesheet style (Element) Modul für Bereiche, in denen zentrale Stylesheet-Formate definiert werden.
    Style Attribute style (Attribut) Modul für das style-Attribut.
    Link link Modul für logische Beziehungen zu anderen Dateien.
    Base base Modul für Adressbasis und Zielfensterbasis.
    Ruby Annotation ruby rbc rtc rb rt rp Modul für Ruby-Text. Die entsprechenden Elemente sind neu. Ruby-Text ist eine Textform, die in fernöstlichen Sprachen verwendet wird, um Silben- oder Wortzeichen mit zusätzlichen Bedeutungshinweisen zu versehen.
    Über den Autor
    Jan-Hendrik Rauh
    Jan-Hendrik Rauh’s DNA ist agil, kraftvoll und digital. Schon seit 2007 arbeitet Jan in den neuen Medien und hat sich seit dem auf Online-Marketing, den dazugehörigen Konzepten und der dazu notwendigen Technologie spezialisiert.

     

    Was ist der Unterschied zwischen XHTML und HTML?

    XHTML ist eine striktere Version von HTML, die sich enger an die XML-Syntax hält. XHTML wurde entwickelt, um für Geräte wie Mobiltelefone und PDAs zugänglicher zu sein, die möglicherweise nicht alle Funktionen von HTML interpretieren können.
    HTML ist der ältere, am häufigsten verwendete Standard. Er ist weniger streng als XHTML und lässt mehr Flexibilität bei der Darstellung von Inhalten zu. HTML eignet sich besser für die Anzeige von Inhalten im Webbrowser, ohne dass sie in ein anderes Format umgewandelt werden müssen.

    Für was steht XHTML?

    XHTML steht für Extensible HyperText Markup Language. Es handelt sich dabei um eine Variante von HTML, die XML besser widerspiegelt und dennoch mit den aktuellen Browsern kompatibel ist. XHTML wird in erster Linie für die Webentwicklung verwendet und bietet Entwicklern mehr Flexibilität bei der Erstellung von Seiten, die sowohl zugänglich sind als auch den Webstandards entsprechen.

    Was ist die Metasprache für XHTML?

    Die Metasprache für XHTML ist HTML. HTML ist die Metasprache für XML, und XML ist die Metasprache für JSON. Theoretisch kann also jede dieser Sprachen für die Erstellung einer Webseite verwendet werden. In der Praxis ist es jedoch meist am besten, sich an HTML zu halten, da es das am meisten unterstützte Format ist.

     

    Auch interessant:

     

    Ihr Kontakt zu uns
    Adresse
    Löwenstark Digital Group GmbH
    Petzvalstraße 38,
    38104 Braunschweig

      Jetzt kostenlose Analyse anfordern

      * Pflichtfeld