XHTML kompakt: Von Besonderheiten über Semantik zu Validierung

Artikel vom 12. Februar 2004 (↻ 7. September 2006). ISSN 1614-3124, #4. Schwerpunkt: (RSS-Feed für alle Themen).

Dieser Artikel ist stellenweise veraltet; manche technologische Entwicklung, wie beispielsweise HTML 5, war zum Zeitpunkt seines Entstehens nicht zu antizipieren und damit unmöglich zu berücksichtigen.

Dieses Dokument beschreibt in kurzer Form den Hintergrund und technische Charakteristika der Seitenbeschreibungssprache XHTML (Extensible HyperText Markup Language). Es soll eine gewisse Grundkenntnis der Technologieprinzipien vermitteln.

Inhalt

  1. Anmerkungen
  2. Geschichte und Hintergrund
  3. Charakteristika
    1. Unterschiede zu HTML
    2. MIME-Typ
    3. Encoding
  4. Semantik
  5. Praxis
    1. Erstellung
    2. Validierung
  6. Epilog

Anmerkungen

Aus technischer Sicht wird sich in diesem Dokument (sofern nicht anders definiert oder von besonderer Relevanz) beim Begriff XHTML auf XHTML 1.0 Transitional und bei HTML auf HTML 4.01 Transitional bezogen, da diese Dokumenttypen (»Doctypes«) aus semantischer Sicht (von der Bedeutung ihrer Elemente und Attribute) die größten Gemeinsamkeiten aufweisen und es nicht erforderlich ist bzw. zu aufwendig wäre, auf weitere Typen einzugehen. Dieses Dokument verzichtet des weiteren auf den Begriff Benutzeragent oder Browser zugunsten von User-Agent.

Geschichte und Hintergrund

XHTML basiert auf XML (Extensible Markup Language) und offeriert unterschiedliche Dokumenttypen und Module (wie zum Beispiel das Listen-, Formular- oder Ruby-Modul), die HTML nachbilden und erweitern. Die erste Version von XHTML, XHTML 1.0, wurde im Januar 2000 als W3C-Spezifikation veröffentlicht und im August 2002 in einer revidierten Fassung erneut aufgelegt. XHTML 1.0 bietet drei unterschiedliche Dokumenttypen, Frameset, Transitional und Strict. Eine weitere Version, XHTML 1.1, erschien im Mai 2001 und offeriert nur noch einen Dokumenttyp.

XHTML oder »die Neuformulierung von HTML in XML-Syntax« hat prinzipiell folgende Vorteile: XHTML ist durch seine strengeren Regeln leichter zu erstellen und zu warten, es ist einfacher zu erlernen, es kann sofort via XSL verändert und transformiert werden, es eignet sich besser für die unterschiedlichsten Endgeräte und es ist (soweit möglich) zukunftssicher, da es leicht zukünftigen Versionen angeglichen werden kann (zum Beispiel über ein entsprechendes XSL-Stylesheet).

Charakteristika

Unterschiede zu HTML

XHTML unterscheidet sich syntaktisch in einigen wenigen, aber entscheidenden Punkten von seinem Vorgänger HTML:

Des weiteren sind zumindest zwei weitere Punkte zu beachten: Zum einen wird das name- vom id-Attribut abgelöst und ist somit veraltet (»deprecated«); zum anderen ist erwähnenswert, dass vordefinierte Attributswerte (zum Beispiel beim type-Attribut des input-Elements) grundsätzlich kleingeschrieben werden müssen, da XML case-sensitive ist und diese Werte in XHTML in Kleinbuchstaben definiert werden.

MIME-Typ

Während in HTML erstellte Dokumente grundsätzlich nur als text/html (MIME-Typ, »Multi-Purpose Internet Mail Extension«) ausgegeben werden dürfen, trifft dies bei XHTML im Allgemeinen nicht zu, die einzige bedingte Ausnahme stellen Seiten mit dem Dokumenttyp XHTML 1.0 Transitional dar, wo ebenfalls text/html gebraucht werden darf.

Generell sollte bei allen als XHTML deklarierte Dokumente der MIME-Typ application/xhtml+xml verwendet werden, auch wenn gemäß Spezifikation sowohl application/xml als auch text/xml ebenfalls erlaubt sind.

Der MIME-Typ kann auf drei unterschiedlichen Wegen definiert werden (mit absteigender Priorität):

Zwar erfordert es die XHTML-Spezifikation, den MIME-Typ als application/xhtml+xml zu definieren, jedoch sind User-Agents, die tatsächlich mit Dokumenten diesen Typs umgehen können (wie auf der Gecko-Engine basierende Browser), immer noch nicht ausreichend verbreitet. Diese Problematik kann umgangen werden, indem abgefragt wird, ob ein User-Agent diesen MIME-Typ versteht (bzw. dies vorgibt), und die angeforderten Dokumente entsprechend zurückgegeben werden, wobei text/html noch als Default definiert werden sollte.

Dennoch: XHTML-Dokumente, die als text/html ausgeliefert werden, sind keine XHTML-, sondern HTML-Dokumente.

Encoding

Da in HTML/XHTML und XML verfasste Dokumente alle auf dem UCS (Universal Character Set) basieren, aber durchaus unterschiedliche Kodierungen (Encodings) verwenden können, ist es zwingend erforderlich, dies ebenfalls zu definieren. Die Zeichenkodierung kann auf vier verschiedene Arten festgelegt werden (ebenfalls von der Priorität her absteigend geordnet), wovon das W3C alle vier Methoden anerkennt, aber die ersten beiden Versionen empfiehlt:

Jede der dargestellten Methoden zeichnet sich durch besondere Charakteristika sowie ihre Vor- und Nachteile aus; beispielsweise empfiehlt sich eine serverseitige Definition nicht bei Dokumenten, die weiter distribuiert werden (zum Beispiel auf Wechselmedien wie CDs), da dann möglicherweise gar kein Encoding definiert wird, auch leidet die XML-Deklaration unter dem Manko, dass Microsoft-User-Agents hier in den Kompatibilitätsmodus springen. Für weitere Informationen zu diesem durchaus komplexen Thema wird auf einen besonders empfehlenswerten Artikel von Richard Ishida verwiesen.

Semantik

Ein entscheidender Punkt, der meistens vernachlässigt wird, ist die Semantik der in HTML und XHTML definierten Elemente, und dieser Aspekt betrifft nicht erst XHTML, sondern auch die Entwicklung mit HTML. In beiden Seitenbeschreibungssprachen haben alle Elemente eine bestimmte Bedeutung, und gemäß dieser Bedeutung bzw. Semantik sind alle Elemente auch zu verwenden. Dies ist per se auch kein besonders kompliziertes Thema, da eigentlich alle zur Verfügung stehenden Elemente von ihrem Namen her bereits Zweck und Bedeutung demonstrieren.

Ein weit verbreitetes Problem stellt hierbei unter anderem der (oftmals übertriebene) Einsatz und Missbrauch von Tabellen dar, die eigentlich dem Zweck dienen, linear darstellbare Daten wie zum Beispiel Statistiken zu repräsentieren, in der Praxis aber dazu verwendet werden, ganze Seitenlayouts wiederzugeben. Dieses populäre Vorgehen führt dabei nicht nur zur »Bedeutungsleere« des Dokuments, sondern auch zu Problemen hinsichtlich der Barrierefreiheit der entsprechenden Seite, u.a, da zum Beispiel Bildschirmlesesoftware (wie JAWS) zeilenweise vorliest und Seiten damit unter Umständen gar keinen Sinn für Menschen mit eingeschränkter Sehkraft machen.

Andere ebenfalls oft zu beobachtende Faux-Pas’ sind Konstrukte wie <span class="headline">foo</span>, für die HTML und XHTML spezielle Elemente bereitstellen (hier: h1 bis h6). Da sich das hier nur knapp angerissene Spektrum nahezu endlos fortsetzen lässt, unter anderem auch, was veraltete Elemente (wie font) oder den Verzicht auf durchaus angebrachte Elemente betrifft (wie zum Beispiel das selten verwendete address-Element), sollen diese Beispiele vorerst genügen, um den »falschen« Weg zu illustrieren.

Derzeit tritt bei den wachsenden Bemühungen um tabellenlose Layouts auch ein anderer unerfreulicher Trend auf, nämlich nahezu alles in Form von div- und span-Elementen zu versorgen. Diese Methode ist aus dem Grund unerfreulich, da besagte Elemente über keine Bedeutung verfügen und die entsprechend aufgesetzten Dokumente ähnlich semantisch nutzlos sind wie ihre ausschließlich aus Tabellen bestehenden Pendants. Ein weiterer Hinweis gebührt an dieser Stelle auch immer noch beliebten und rein präsentationsbezogenen Attributen (wie zum Beispiel bgcolor), auf die durch den dringend anzuratenden (konsequenten) Einsatz von CSS zu verzichten ist, um eine vollständige Trennung von Struktur und Präsentation zu erzielen.

Einen weiteren Einblick erhalten Sie durch Heike Edinger und Timo Wirth: Semantischer Code – Definitionen, Methoden, Zweifel.

Praxis

Erstellung

Prinzipiell sollte ein zu kreierendes Dokument nicht nur valid sein, sondern auch die im vorherigen Bereich angesprochene Semantik beinhalten. Ein relativ einfaches XHTML-Dokument, welches alle die in dieser Ausarbeitung definierten Punkte berücksichtigt, könnte beispielsweise so aussehen, wenn es »from scratch« entworfen wird: 

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xml:lang="de">
  <head>
    <title>Test</title>
    <link rel="stylesheet" type="text/css" href="IRI" />
  </head>
  <body>
    <h1>Ăśberschrift oder Tagline</h1>
    <ul>
      <li><a href="IRI">MenĂĽpunkt 1</a></li>
      <li><a href="IRI">MenĂĽpunkt 2</a></li>
      <li><a href="IRI">MenĂĽpunkt 3</a></li>
    </ul>
    <h2>Eine weitere Ăśberschrift</h2>
    <div><img src="IRI" alt="Bildbeschreibung." /></div>
    <p>Ein Absatz.</p>
    <p>Ein Absatz.</p>
    <h2>Noch eine Ăśberschrift</h2>
    <p>Ein Absatz.</p>
    <p>Ein Absatz.</p>
    <p xml:lang="en">A paragraph.</p>
    <hr />
    <address>Autor, Adresse</address>
  </body>
</html>

Zu beachten ist, dass das dargestellte Dokument jedes Element gemäß seiner Bedeutung gebraucht und die Präsentation vom zugehörigen Stylesheet gesteuert wird. Auch verzichtet es gänzlich auf style- (ab XHTML 2.0 voraussichtlich veraltet), id- und class-Attribute, was hier zwar möglich, in der Praxis aber zumindest bei komplexeren Dokumenten so meist (noch) nicht durchführbar ist.

Validierung

Um sicherzugehen, dass Dokumente valid sind (also nach Spezifikation entworfen wurden), ist es unerlässlich, seine Seiten zu … validieren. Dies minimiert unter anderem das Risiko von Fehldarstellungen (zum Beispiel durch die durchaus unterschiedliche Interpretation von nicht geschlossenen Elementen), garantiert die Interoperabilität (unter anderem mit anderen XML-Formaten) und schult natürlich erheblich das Verständnis für die Syntax der gebrauchten Sprache (bzw. des verwendeten Dokumenttyps).

Das W3C (W3C MarkUp Validation Service) sowie die Web Design Group (WDG HTML Validator) stellen beide entsprechende Validierungsdienste bereit.

Epilog

It is required that HTML be a common language between all platforms. This implies no device-specific markup, or anything which requires control over fonts or colors, for example. This is in keeping with the SGML ideal.

– Tim Berners-Lee: Design Constraints (1992).

Wie bereits Geschichte und Hintergrund aufzeigen, birgt XHTML mitunter Vorteile gegenüber seinem Vorgänger HTML, und es ist von der Syntax her einfach zu erlernen. Die in XHTML zur Verfügung stehenden Elemente und Attribute sind prinzipiell auf alle möglichen Anwendungsfälle zugeschnitten, und es wird empfohlen, diese auch gemäß ihrer Bedeutung (Semantik) zu verwenden, um Sinn und Struktur eines Dokuments vermitteln zu können und um letztlich auch Menschen mit Behinderungen den Zugriff auf Informationen zu erleichtern.

Durch seinen Ursprung in XML ist XHTML des weiteren leicht erweiterbar, wobei sich an der grundsätzlichen Syntax nichts ändern wird. Die derzeitige Erarbeitung des zu XHTML 1.0/1.1 nicht mehr kompatiblen XHTML 2.0 wird jedoch gravierende Änderungen mit sich bringen, da einige Elemente wegfallen (wie möglicherweise br), einige ersetzt (wie möglicherweise hr durch separator) und neue hinzukommen werden (wie l oder section), und die Trennung von Struktur und Präsentation mehr oder minder »erzwungen« wird, nicht zuletzt durch den ersatzlosen Wegfall diverser präsentationsbezogener Attribute.

Eine Umstellung auf XHTML bedeutet nicht nur die Adaption jetziger Standards, da XHTML mehr und mehr die veraltete Seitenbeschreibung mit HTML wie beabsichtigt ablöst, sondern auch eine Erleichterung im Hinblick auf zukünftige Standards wie das erwähnte XHTML 2.0. Und mit jetzigen und weiteren Versionen von CSS hat man das geeignete Instrument in der Hand, um an einer einzigen Stelle geräte- und medienspezifische Formatierungen und Layouts zu schaffen, ohne bei späteren Anpassungen seine Dokumente überhaupt berühren zu müssen.

War dies nützlich oder interessant? Teile (toote) diesen Beitrag, oder lad mich vielleicht auf einen Kaffee ein. Danke!

Ăśber mich

Jens Oliver Meiert, am 30. September 2021.

Ich bin Jens, und ich bin ein Engineering Lead und Autor. Ich habe als technischer Leiter für Firmen wie Google und als Engineering Manager für Firmen wie Miro gearbeitet, bin W3C und WHATWG verbunden und schreibe und prüfe Fachbücher für O’Reilly und Frontend Dogma.

Mit meinem aktuellen Umzug nach Spanien bin ich offen für eine neue Führungsposition im Frontend-Bereich. Beachte und empfehle gerne meinen Lebenslauf oder mein LinkedIn-Profil.

Ich experimentiere gerne, nicht nur in der Webentwicklung, sondern auch in anderen Bereichen wie der Philosophie. Hier auf meiert.com teile ich einige meiner Ansichten und Erfahrungen.