edition W3C.de

XHTML 1.0: Die Extensible HyperText Markup Language (Zweite Auflage)

Linkwerk - Wir sind XML

Deutsche Übersetzung

Diese Version:
http://www.edition-w3c.de/TR/2002/REC-xhtml1-20020801
Aktuelle Version:
http://www.edition-w3c.de/TR/xhtml1
Übersetzer:
Judith Muhr (Übersetzung)
Stefan Mintert (Fachlektorat und Kommentierung), Linkwerk

Bei diesem Dokument handelt es sich um eine Übersetzung eines W3C-Textes. Dieser Text ist urheberrechtlich geschützt; bitte beachten Sie die nachfolgenden Hinweise des Originaldokuments. Die Rechte an der Übersetzung liegen bei den Übersetzern und dem Verlag Addison-Wesley. Die Übersetzung hat keine durch das W3C legitimierte, normative Wirkung. Das einzige maßgebliche Dokument ist das englische Original.

Bitte senden Sie Fehler und Korrekturen zur deutschen Fassung an die Übersetzer.

Kommentare der Übersetzer, die als solche gekennzeichnet sind, unterliegen dem Urheberrecht der Übersetzer. Sie sind nicht Bestandteil des Ursprungsdokuments.


W3C

XHTML 1.0: Die Extensible HyperText Markup Language (Zweite Auflage)

Eine Neuformulierung von HTML in XML 1.0

W3C-Empfehlung, 26. Januar 2000, überarbeitet am 1. August 2002

Diese Version:
http://www.w3.org/TR/2002/REC-xhtml1-20020801
Neueste Version:
http://www.w3.org/TR/xhtml1
Vorhergehende Version:
http://www.w3.org/TR/2000/REC-xhtml1-20000126
Version mit hervorgehobenen Änderungen:
http://www.w3.org/TR/2002/REC-xhtml1-20020801/xhtml1-diff.html
Autoren:
Siehe Danksagungen.

Bitte beachten Sie die Errata für dieses Dokument, die normative Korrekturen enthalten können. Siehe auch Übersetzungen.

Dieses Dokument ist auch in folgenden nicht normativen Formaten erhältlich: Mehrteilige XHTML-Dateien, PostScript, PDF, ZIP-Archiv und Gzip/TAR-Archiv .

Inhaltsverzeichnis

1 Was ist XHTML?
1.1 Was ist HTML 4?
1.2 Was ist XML?
1.3 Wozu braucht man XHTML?
2 Definitionen
2.1 Terminologie
2.2 Allgemeine Begriffe
3 Normative Definition von XHTML 1.0
3.1 Konforme Dokumente
3.1.1 Streng konforme Dokumente
3.1.2 XHTML mit anderen Namensräumen verwenden
3.2 Konforme Benutzerprogramme
4 Unterschiede zu HTML 4
4.1 Dokumente müssen korrekt aufgebaut sein
4.2 Element- und Attributnamen müssen in Kleinbuchstaben dargestellt werden
4.3 Für nicht leere Elemente müssen End-Tags angegeben werden
4.4 Attributwerte müssen immer in Anführungszeichen stehen
4.5 Attributminimierung
4.6 Leere Elemente
4.7 Behandlung von Leerraum in Attributwerten
4.8 Script- und Style-Elemente
4.9 SGML-Ausschlüsse
4.10 Die Elemente mit 'id'- und 'name'-Attributen
4.11 Attribute mit vordefinierten Wertemengen
4.12 Entity-Referenzen als hexadezimaler Wert
5 Kompatibilitätsaspekte
5.1 Internet-Medientyp
Anhang A: DTDs
A.1 Dokumenttypdefinitionen
A.1.1. XHTML-1.0-Strict
A.1.2. XHTML-1.0-Transitional
A.1.3. XHTML-1.0-Frameset
A.2 Entity-Mengen
A.2.1. Latin-1 characters
A.2.2. Special characters
A.2.3. Symbols
Anhang B: Element-Ausschlüsse
Anhang C: Richtlinien zur HTML-Kompatibilität
C.1 Verarbeitungsanweisungen und die XML-Deklaration
C.2 Leere Elemente
C.3 Elementminimierung und leerer Elementinhalt
C.4 Eingebettete Stylesheets und Skripte
C.5 Zeilenumbrüche innerhalb von Attributwerten
C.6 Isindex
C.7 Die Attribute lang and xml:lang
C.8 Fragmentbezeichner
C.9 Zeichencodierung
C.10 Boolesche Attribute
C.11 Document Object Model und XHTML
C.12 Die Verwendung von et-Zeichen in Attributwerten (und anderswo)
C.13 Cascading Style Sheets (CSS) und XHTML
C.14 Referenzierung von Style-Elementen bei Verwendung als XML
C.15 Leerraumzeichen in HTML vs. XML
C.16 Die benannte Zeichenreferenz '
Anhang D: Danksagungen
Anhang E: Literaturverzeichnis
Stichwortverzeichnis

Kurzbeschreibung

Diese Spezifikation definiert die zweite Auflage von XHTML 1.0, eine Neufassung von HTML 4 als XML 1.0-Anwendung sowie drei DTDs, die den von HTML 4 definierten DTDs entsprechen. Die Semantik der Elemente und ihre Attribute sind in der W3C-Empfehlung für HTML 4 definiert. Diese Semantiken stellen die Grundlage für die zukünftige Erweiterbarkeit von XHTML dar. Kompatibilität mit existierenden HTML-Benutzerprogrammen ist möglich, wenn einige wenige Richtlinien befolgt werden.

Anmerkung der Übersetzer:

Die Kurzbeschreibung sagt bereits zwei wichtige Dinge: Erstens entspricht XHTML 1.0 inhaltlich HTML 4. Es gibt also keine neuen Elementtypen. Zweitens ist die Bedeutung der Elementtypen in der HTML 4-Spezifikation beschrieben. Aus diesem Grund ist die HTML 4-Spezifikation nicht überflüssig und sollte bekannt sein, wenn Sie mit HTML oder XHTML arbeiten möchten. Die deutsche Übersetzung von HTML 4 ist unter der Adresse http://www.edition-w3c.de/TR/1999/REC-html401-19991224 zu finden.

Status dieses Dokuments

Dieser Abschnitt beschreibt den Status dieses Dokuments zum Zeitpunkt seiner Veröffentlichung. Neue Dokumente können dieses Dokument ersetzen. Der neueste Status dieser Dokumentreihe wird vom W3C verwaltet.

Dieses Dokument ist die zweite Auflage der XHTML 1.0-Empfehlung, die die Korrekturänderungen bis zum 1. August 2002 enthält. Änderungen zwischen dieser Version und der vorhergehenden Empfehlung sind in einer Version mit hervorgehobenen Änderungen dargestellt.

Diese zweite Auflage ist keine neue Version von XHTML 1.0 (zum ersten mal am 26. Januar 2000 veröffentlicht). Die Änderungen in diesem Dokument spiegeln Korrekturen wider, die als Ergebnis von Kommentaren, die von der Öffentlichkeit gemacht wurden, und als Ergebnis der fortschreitenden Arbeit der HTML-Arbeitsgruppe entstanden sind. Es gibt keine substantiellen Änderungen in diesem Dokument – ausschließlich die Integration der verschiedenen Errata.

Die Liste der bekannten Fehler in dieser Spezifikation ist unter http://www.w3.org/2002/08/REC-xhtml1-20020801-errata verfügbar.

Bitte melden Sie Fehler in diesem Dokument an www-html-editor@w3.org (Archiv). Die öffentliche Diskussion von HTML-Eigenschaften findet auf der Mailingliste www-html@w3.org (Archiv) statt.

Dieses Dokument wurde als Teil der W3C HTML Activity hergestellt. Die Ziele der HTML Working Group (nur Mitglieder) werden in der HTML Working Group Charta diskutiert.

Zur Zeit der Veröffentlichung war die Arbeitsgruppe davon überzeugt, dass es keine Patentbekanntmachungen gibt, die für diese Spezifikation relevant sind. Eine aktuelle Liste von Patentbekanntmachungen, die für diese Spezifikation relevant sind, ist auf der Seite für Patentbekanntmachungen der Arbeitsgruppe zu finden.

Eine Liste der aktuellen W3C-Empfehlungen sowie anderer technischer Dokumente finden Sie unter http://www.w3.org/TR.

Anmerkung der Übersetzer:

Eine Liste von deutschen Übersetzungen von W3C-Dokumenten finden Sie unter http://www.edition-w3c.de/.

Was ist XHTML?

Dieser Abschnitt ist informell.

XHTML ist eine Familie aktueller und zukünftiger Dokumenttypen und Module, die HTML 4 nachbilden, eine Untermenge davon bilden bzw. es erweitern [HTML4]. Dokumenttypen aus der XHTML-Familie basieren auf XML und sind letztlich darauf ausgelegt, in Kombination mit auf XML basierenden Benutzerprogrammen eingesetzt zu werden. Detaillierte Informationen zu dieser Familie und ihrer Entwicklung finden Sie in [XHTMLMOD].

XHTML 1.0 (diese Spezifikation) ist der erste Dokumenttyp in der XHTML-Familie. Es handelt sich dabei um eine Neuformulierung der drei HTML 4-Dokumenttypen als Anwendungen von XML 1.0 [XML]. Es ist für die Verwendung als Sprache für Inhalte vorgesehen, die sowohl zu XML konform sind, und die auch, falls sie einigen einfachen Richtlinien folgen, in zu HTML 4 konformen Benutzerprogrammen eingesetzt werden können. Entwickler, die ihre Inhalte auf XHTML 1.0 umstellen, werden die folgenden Vorteile erkennen:

Die XHTML-Familie ist der nächste Schritt in der Evolution des Internet. Wenn die Entwickler von Inhalten heute auf XHTML umsteigen, können sie in die XML-Welt mit allen dort gebotenen Vorteilen vordringen und dennoch darauf vertrauen, dass ihr Inhalt vorwärts- und rückwärtskompatibel ist.

1.1 Was ist HTML 4?

HTML 4 [HTML4] ist eine SGML-Anwendung (Standard Generalized Markup Language), die konform zur internationalen Norm ISO 8879 ist und in weiten Kreisen als Standardpublikationssprache des World Wide Web betrachtet wird.

SGML ist eine Sprache für beschreibende Markup-Sprachen, insbesondere solche, die für den elektronischen Austausch von Dokumenten, die Dokumentverwaltung und die Dokumentveröffentlichung verwendet werden. HTML ist ein Beispiel für eine in SGML definierte Sprache.

SGML gibt es schon seit Mitte der Achtzigerjahre, und sie ist relativ stabil geblieben. Ein Großteil dieser Stabilität resultiert aus der Tatsache, dass die Sprache zum einen zahlreiche Funktionsmerkmale aufweist, gleichzeitig aber auch flexibel ist. Diese Flexibilität hat jedoch ihren Preis, nämlich die Komplexität, die verhindert hat, dass es sich in unterschiedlichsten Umgebungen durchgesetzt hat, unter anderem auch im World Wide Web.

HTML war, wie ursprünglich vorgesehen, eine Sprache für den Austausch wissenschaftlicher und anderer technischer Dokumente, die auch von Benutzern eingesetzt werden konnte, die keine Dokumentspezialisten waren. HTML löst die Probleme, die sich aus der Komplexität von SGML ergeben, indem es eine kleine Menge strukturbildender und semantischer Tags bereitstellt, die für die Auslegung relativ einfacher Dokumente geeignet sind. Um die Dokumentstruktur zu vereinfachen, unterstützt HTML außerdem Hypertext. Multimedia-Fähigkeiten wurden später hinzugefügt.

Innerhalb bemerkenswert kurzer Zeit wurde HTML allgemein beliebt und wuchs schnell über seinen ursprünglichen Zweck hinaus. Seit der Einführung von HTML wurden sehr schnell immer wieder neue Elemente entwickelt, die in HTML (als Standard) eingesetzt werden und die Anpassung von HTML an vertikale, hoch spezialisierte Märkte unterstützten. Diese Vielfalt an neuen Elementen hat zu Problemen bezüglich der Zusammenarbeit von Dokumenten geführt, die über verschiedene Plattformen hinweg verwendet wurden.

Weil sowohl Software als auch Plattformen immer schneller heterogen wurden, ist deutlich, dass das „klassische“ HTML 4 für die Verwendung auf diesen Plattformen gewissen Einschränkungen unterliegt.

1.2 Was ist XML?

XML™ ist die Abkürzung für Extensible Markup Language [XML].

XML war darauf ausgelegt, die Leistungsfähigkeit und Flexibilität von SGML wiederzugewinnen, ohne jedoch deren hohe Komplexität mit sich zu bringen. Obwohl XML eine eingeschränkte Form von SGML ist, weist es trotzdem einen Großteil der Leistungsfähigkeit und Reichhaltigkeit von SGML auf, ebenso wie die gebräuchlichsten Funktionsmerkmale von SGML.

Während XML diese vorteilhaften Leistungsmerkmale beibehält, verzichtet es auf viele der komplexeren Funktionsmerkmale von SGML, die das Schreiben und den Entwurf geeigneter Software schwierig und teuer machen.

1.3 Wozu braucht man XHTML?

Die Vorteile, die ein Umstieg auf XHTML 1.0 mit sich bringt, sind oben beschrieben. Einige der Vorteile beim Wechsel zu XHTML können ganz allgemein wie folgt beschrieben werden:

Definitionen

Dieser Abschnitt ist normativ.

2.1 Terminologie

In dieser Spezifikation werden die nachfolgenden Begriffe verwendet. Diese Begriffe erweitern die Definitionen aus [RFC2119], und basieren auf ähnlichen Definitionen wie in ISO/IEC 9945-1:1990 [POSIX.1]:

Kann, Darf (May)
In Hinblick auf Implementierungen sollte das Wort „kann“ als optionales Funktionsmerkmal betrachtet werden, das in dieser Spezifikation nicht gefordert wird, das jedoch unterstützt werden kann. Was die Konformität des Dokuments betrifft, bedeutet das Wort „kann“, dass das optionale Funktionsmerkmal nicht verwendet werden darf. Der Begriff „optional“ hat dieselbe Definition wie „kann“.
Muss (Must)
In dieser Spezifikation sollte das Wort „muss“ als zwingende Anforderung für die Implementierung betrachtet werden oder für streng konforme XHTML-Dokumente, abhängig vom Kontext. Der Begriff „soll“ hat dieselbe Definition wie „muss“.
Nicht spezifiziert (Unspecified)
Ist ein Wert oder ein Verhalten nicht spezifiziert, definiert die Spezifikation keine Portabilitätsanforderungen für ein Funktionsmerkmal für eine Implementierung, selbst wenn ein Dokument vorliegt, das dieses Funktionsmerkmal nutzt. Ein Dokument, das für einen solchen Fall ein spezielles Verhalten bedingt, statt ein beliebiges Verhalten zu tolerieren, obwohl es dieses Funktionsmerkmal aufweist, ist kein streng konformes XHTML-Dokument.
Optional (Optional)
Siehe „Kann“.
Reserviert (Reserved)
Ein Wert oder Verhalten ist nicht spezifiziert, aber es darf von konformen Dokumenten nicht verwendet und von einem konformen Benutzerprogramm nicht unterstützt werden.
Soll (Shall)
Siehe „Muss“.
Sollte (Should)
Im Hinblick auf Implementierungen sollte das Wort „sollte“ als Empfehlung für die Implementierung, nicht aber als Forderung interpretiert werden. Im Hinblick auf Dokumente sollte das Wort „sollte“ als empfohlene Vorgehensweise bei der Programmierung für Dokumente verstanden werden und als Forderung für streng konforme XHTML-Dokumente.
Unterstützt (Supported)
Bestimmte Funktionsmerkmale in dieser Spezifikation sind optional. Wird ein Funktionsmerkmal unterstützt, verhält es sich, wie in dieser Spezifikation beschrieben.

2.2 Allgemeine Begriffe

Attribut
Ein Attribut ist ein Parameter für ein Element, der in der DTD deklariert ist. Der Typ und der Wertebereich eines Attributs ebenso wie ein möglicher Standardwert, sind in der DTD definiert.

Anmerkung der Übersetzer:

Beispielsweise lautet bei <a href=“buch.html“>...</a> der Attributname „href“. In der XHTML-DTD ist deklariert, dass Elemente vom Typ a Attribute namens „href“ haben können. Der Wert ist in diesem Beispiel der Text „buch.html“.

Benutzerprogramm
Ein Benutzerprogramm ist ein System, das XHTML-Dokumente in Übereinstimmung mit dieser Spezifikation verarbeitet. Weitere Informationen finden Sie in Abschnitt 3.2 über konforme Benutzerprogramme.

Anmerkung der Übersetzer:

Aus dem englischen „User Agent“ ist in unserer Übersetzung das „Benutzerprogramm“ geworden. Eine Begründung und Erläuterung ist in der kommentierten Fassung der CSS2-Spezifikation zu finden.

DTD
Eine DTD (Dokumenttypdefinition) setzt sich aus mehreren XML-Markup-Deklarationen zusammen, die in ihrer Gesamtheit die erlaubte Struktur, Elemente und Attribute definiert, die für die Verwendung in einem Dokument zur Verfügung stehen, das konform zu der DTD ist.

Anmerkung der Übersetzer:

Die DTD legt fest, welche Elemente (und ihre Attribute) in einem Dokument verwendet werden können. Damit stellt die DTD die Grammatik der Sprache (in diesem Fall: XHTML) dar, die definiert wird.

Dokument
Ein Dokument ist ein Datenstrom, der nach der Kombination mit anderen Strömen, auf die er verweist, so strukturiert ist, dass er Informationen enthält, die in Elementen enthalten sind, die wie in der zugehörigen DTD definiert angeordnet sind. Weitere Informationen finden Sie in Abschnitt 3.1 über konforme Dokumente.
Element
Ein Element ist eine Einheit für die Strukturierung eines Dokuments, die in der DTD deklariert ist. Das Inhaltsmodell des Elements ist in der DTD definiert; zusätzliche Semantiken können in der Textbeschreibung des Elements definiert sein.
Funktionsmerkmale
Funktionsmerkmale sind Elemente, Attribute und die diesen Elementen und Attributen zugeordnete Semantik. Wenn eine Implementierung diese Funktionalität unterstützt, sagt man, sie stellt die erforderlichen Funktionsmerkmale bereit.
Implementierung
Siehe Benutzerprogramm.
Parsing
Parsing ist der Vorgang, währenddessen ein Dokument überprüft („gescannt“) und die in dem Dokument enthaltene Information in den Kontext der Elemente gefiltert wird, in dem die Information strukturiert ist.
Rendering
Rendering (Darstellen) ist der Vorgang, bei dem die Information aus einem Dokument dargestellt wird. Diese Darstellung erfolgt in der für die Umgebung am besten geeigneten Form (z.B. akustisch, visuell, gedruckt).
Validierung
Bei der Validierung werden Dokumente im Hinblick auf die zugeordnete DTD überprüft, wobei sichergestellt wird, dass die Verwendung der Elemente sowie der Attribute konsistent mit den Definitionen in der DTD erfolgt.
Wohlgeformtheit
Ein Dokument ist wohlgeformt, wenn es gemäß den in Abschnitt 2.1 definierten Regeln der XML 1.0-Empfehlung [XML] strukturiert ist. Grundsätzlich sagt diese Definition aus, dass Elemente, die durch ihre Start- und Ende-Tags begrenzt sind, korrekt ineinander verschachtelt sein müssen.

Normative Definition von XHTML 1.0

Dieser Abschnitt ist normativ.

3.1 Konforme Dokumente

Diese Version von XHTML stellt eine Definition streng konformer XHTML 1.0-Dokumente bereit, die auf die Elemente und Attribute aus dem XML- und XHTML 1.0-Namensraum beschränkt sind. Weitere Informationen über die Verwendung von XHTML in Kombination mit anderen Namensräumen, wie beispielsweise für das Einbinden von Metadaten, die in RDF ausgedrückt sind, in XHTML-Dokumente, finden Sie in Abschnitt 3.1.2.

Anmerkung der Übersetzer:

Im Gegensatz zur ersten Auflage wird hier zusätzlich vom XML-Namensraum gesprochen. Diese Erweiterung der Aussage hinsichtlich des XML-Namensraums ist schon deshalb notwendig, weil in dieser XHTML-Spezifikation auch das Attribut xml:lang vorkommt.

3.1.1 Streng konforme Dokumente

Ein streng konformes XHTML-Dokument ist ein XML-Dokument, das nur die Funktionsmerkmale benötigt, die in dieser Spezifikation als zwingend erforderlich beschrieben sind. Ein solches Dokument muss alle folgenden Kriterien erfüllen:

  1. Es muss konform zu den Beschränkungen sein, die in einer der drei in Anhang A beschriebenen DTDs und in Anhang B ausgedrückt sind.
  2. Das Wurzelelement des Dokuments muss html sein.
  3. Das Wurzelelement des Dokuments muss eine xmlns–Deklaration für den XHTML-Namensraum enthalten [XMLNAMES]. Der Namensraum für XTHML ist definiert als http://www.w3.org/1999/xhtml. Ein Wurzelelement kann z.B. so aussehen:
    <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
  4. Im Dokument muss es vor dem Wurzelelement eine DOCTYPE-Deklaration geben. Der in der DOCTYPE-Deklaration enthaltene öffentliche Bezeichner muss auf eine der drei in Anhang A beschriebenen DTDs verweisen, und zwar unter Verwendung des betreffenden Formal Public Identifier. Der Systembezeichner kann geändert werden, um lokale Systemkonventionen zu berücksichtigen.
    <!DOCTYPE html 
    PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

    <!DOCTYPE html
    PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

    <!DOCTYPE html
    PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">
5. Die [interne] DTD-Teilmenge darf nicht verwendet werden, um irgendwelche Parameter-Entities der DTD zu überschreiben.

Eine XML-Deklaration ist nicht in allen XML-Dokumenten erforderlich. Den Autoren von XHTML-Dokumenten wird jedoch sehr empfohlen, in all ihren Dokumenten XML-Deklarationen zu verwenden. Eine solche Deklaration ist erforderlich, wenn die Zeichenkodierung des Dokuments nicht die Standardkodierung UTF-8 oder UTF-16 ist und keine Kodierung durch ein Higher-Level-Protokoll bestimmt wurde. Im folgenden Beispiel ist die XML-Deklaration enthalten:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>Virtual Library</title>
</head>
<body>
<p>Moved to <a href="http://example.org/">example.org</a>.</p>
</body>
</html>

Anmerkung der Übersetzer:

Die Namensraumbezeichner (hier http://www.w3.org/1999/xhtml) sehen aus wie URLs. Es handelt sich dabei jedoch ausschließlich um Zeichenketten. Unter der gleichnamigen Adresse muss nicht einmal eine Webseite zu finden sein. Man nutzt hier aus, dass durch den Aufbau einer Namensraumbezeichners in dieser Form weltweite Eindeutigkeit gewährleistet wird.

Der Bezeichner legt die Vermutung nahe, dass bei Zugriff per http auf den Rechner mit dem Namen www.w3.org und Anforderung der Datei namens /1999/xhtml ein Dokument geliefert wird, das den entsprechenden Namensraum in irgendeiner Syntax formal definiert. Dies ist jedoch nicht so, was dazu beiträgt, dass viele Stimmen für eine andere Syntax der Namensraumbezeichner plädieren.

3.1.2 XHTML mit anderen Namensräumen verwenden

Der XHTML-Namensraum kann in Kombination mit anderen XML-Namensräumen verwendet werden, gemäß [XMLNAMES], obwohl solche Dokumente keine streng konformen XHTML 1.0-Dokumente sind, wie oben definiert. Fortlaufende Arbeiten des W3C suchen nach Möglichkeiten, um Konformität für Dokumente mit mehreren Namensräumen zu definieren. Als Beispiel siehe [XHTML+MathML].

Anmerkung der Übersetzer:

Die Kombination von Elementen aus zwei verschiedenen Namensräumen, wie auch im nachfolgenden Beispiel zu sehen, verhindert, dass das Ergebnisdokument gültig bezüglich der einen (etwa XHTML) oder der anderen DTD (etwa MathML) ist.

Das folgende Beispiel zeigt, wie XHTML 1.0 in Kombination mit der MathML-Empfehlung verwendet werden kann:

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>Ein Beispiel aus der Mathematik</title>
</head>
<body>
<p>Das folgende ist MathML-Markup:</p>
<math xmlns="http://www.w3.org/1998/Math/MathML">
<apply> <log/>
<logbase>
<cn> 3 </cn>
</logbase>
<ci> x </ci>
</apply>
</math>
</body>
</html>

Das folgende Beispiel zeigt, wie XHTML 1.0-Markup in einen anderen XML-Namensraum aufgenommen werden könnte:

<?xml version="1.0" encoding="UTF-8"?>
<!--anfänglich ist der Standard-Namensraum "books" -->
<book xmlns='urn:loc.gov:books'
xmlns:isbn='urn:ISBN:0-395-36341-6' xml:lang="en" lang="en">
<title>Im Dutzend billiger</title>
<isbn:number>1568491379</isbn:number>
<notes>
<!-- HTML zum Standard-Namensraum für einen Hypertext-Kommentar machen -->
<p xmlns='http://www.w3.org/1999/xhtml'>
Dies steht auch online <a href="http://www.w3.org/">zur Verfügung</a>.
</p>
</notes>
</book>

3.2 Konforme Benutzerprogramme

Ein konformes Benutzerprogramm muss alle folgenden Kriterien erfüllen:

  1. Um zu der XML 1.0-Empfehlung [XML] konform zu sein, muss das Benutzerprogramm ein XHTML-Dokument auf seinen korrekten Aufbau hin überprüfen. Gibt das Benutzerprogramm an, dass es ein validierendes Benutzerprogramm ist, muss es Dokumente auch gemäß der DTDs überprüfen, auf die darin verwiesen wird, gemäß [XML].
  2. Gibt das Benutzerprogramm an, Funktionsmerkmale zu unterstützen, die innerhalb dieser Spezifikation definiert sind oder die von dieser Spezifikation durch einen normativen Verweis gefordert werden, muss es das konsistent zu der Definition dieser Funktionsmerkmale tun.
  3. Wenn ein Benutzerprogramm ein XHTML-Dokument als generisches XML verarbeitet, soll es nur Attribute des Typs ID (z.B. für die meisten XHTML-Elemente das id-Attribut) als Fragmentbezeichner erkennen.
  4. Wenn ein Benutzerprogramm auf ein Element trifft, das es nicht erkennt, muss es den Inhalt des Elements verarbeiten.
  5. Wenn ein Benutzerprogramm auf ein Attribut trifft, das es nicht erkennt, muss es die gesamte Attributspezifikation ignorieren (d.h. das Attribut und seinen Wert).
  6. Wenn ein Benutzerprogramm auf einen Attributwert trifft, den es nicht erkennt, muss es den Standardattributwert verwenden.
  7. Wenn es auf einen Entity-Verweis trifft (außer eines der in dieser Empfehlung oder in der XML- Empfehlung vordefinierten Entities), für den das Benutzerprogramm keine Deklaration verarbeitet hat (was passieren könnte, wenn sich die Deklaration in der externen Untermenge befindet, die das Benutzerprogramm noch nicht gelesen hat), sollte der Entity-Verweis durch die Zeichen verarbeitet werden (beginnend mit dem Ampersand und endend mit dem Semikolon), aus denen sich der eigentliche Verweis zusammensetzt.
  8. Treffen Benutzerprogramme bei der Verarbeitung von Inhalt auf Zeichen oder Zeichen-Entity-Verweise, die sie erkennen, aber nicht darstellen können, können sie eine andere Darstellung wählen, die die gleiche Bedeutung hat, oder sie müssen das Dokument so darstellen, dass es für den Benutzer offensichtlich ist, dass keine normale Darstellung stattfinden konnte.
  9. Leeraum wird gemäß den folgenden Regeln behandelt. Die folgenden Zeichen sind in [XML] als Leerraumzeichen definiert:
    Der XML-Prozessor normalisiert die Zeilenende-Codes unterschiedlicher Systeme zu einem einzigen Zeilenvorschubzeichen, das an die Applikation weitergegeben wird.
    Das Benutzerprogramm muss die Definition für die Verarbeitung von Leerraumzeichen aus von CSS verwenden [CSS]. Beachten Sie, dass die CSS2-Empfehlung die Behandlung von Leerraum in Nicht-Latin-Zeichensätzen nicht explizit anspricht. Dies wird in einer zukünftigen Version von CSS geschehen, woraufhin diese Spezifikation aktualisiert wird.

Beachten Sie, dass zur Erzeugung eines kanonischen XHTML-Dokuments die obigen Regeln, genauso wie die Regeln in [XMLC14N] auf das Dokument angewendet werden müssen.

Unterschiede zu HTML 4

Dieser Abschnitt ist informell.

Aufgrund der Tatsache, dass es sich bei XHTML um eine XML-Anwendung handelt, müssen einige Vorgehensweisen, die im auf SGML basierenden HTML 4 [HTML4] völlig korrekt waren, geändert werden.

4.1 Dokumente müssen korrekt aufgebaut sein

Der korrekte Aufbau („Wohlgeformtheit“) ist ein neues Konzept, das von [XML] eingeführt wurde. Im Wesentlichen bedeutet es, dass alle Elemente entweder schließende Tags haben müssen oder dass sie in einer speziellen Form geschrieben sein müssen (wie nachfolgend beschrieben), und dass alle Elemente korrekt verschachtelt sein müssen.

Obwohl in SGML keine Überlappungen erlaubt sind, werden sie in existierenden Browsern allgemein toleriert.

RICHTIG: verschachtelte Elemente.
<p>Hier sehen Sie einen betonten <em>Absatz</em>.</p>
FALSCH: überlappende Elemente
<p>Hier sehen Sie einen betonten <em>Absatz.</p></em>

4.2 Element- und Attributnamen müssen in Kleinbuchstaben dargestellt werden

XHTML-Dokumente müssen für alle HTML-Element- und Attributnamen Kleinbuchstaben verwenden. Diese Unterscheidung ist erforderlich, weil XML die Groß-/Kleinschreibung berücksichtigt; <li> und <LI> sind demnach unterschiedliche Tags.

4.3 Für nicht leere Elemente müssen End-Tags angegeben werden

In auf SGML basierendem HTML 4 konnten bestimmte Elemente das End-Tag einfach weglassen; in diesem Fall stellten nachfolgende Elemente einen impliziten Abschluss dar. XML erlaubt das Weglassen von End-Tags nicht. Alle Elemente, die in der DTD nicht als EMPTY deklariert sind, müssen ein End-Tag haben. Elemente, die in der DTD als EMPTY deklariert sind, können ein End-Tag haben oder die Kurzschreibweise verwenden (siehe Leere Elemente).

RICHTIG: abgeschlossene Elemente
<p>Hier sehen Sie einen Absatz.</p><p>Und hier noch einen.</p>
FALSCH: nicht abgeschlossene Elemente
<p>Hier sehen Sie einen Absatz.<p>Und hier noch einen.

4.4 Attributwerte müssen immer in Anführungszeichen stehen

Alle Attributwerte müssen in Anführungszeichen stehen, selbst solche, die scheinbar numerisch sind.

RICHTIG: Attributwerte in Anführungszeichen
<td rowspan="3">
FALSCH: Nicht in Anführungszeichen eingeschlossene Attributwerte
<td rowspan=3>

4.5 Attributminimierung

XML unterstützt keine Attributminimierung. Attribut/Wert-Paare müssen vollständig ausgeschrieben werden. Attributnamen wie beispielsweise compact und checked dürfen in Elementen nicht auftreten, ohne dass ihr Wert zuvor spezifiziert wurde.

RICHTIG: Nicht minimierte Attribute
<dl compact="compact">
FALSCH: Minimierte Attribute
<dl compact>

4.6 Leere Elemente

Leere Elemente müssen ein End-Tag haben, oder das Start-Tag muss mit /> enden, beispielsweise <br/> oder <hr></hr>. Weitere Informationen darüber, wie Sie diese Abwärtskompatibilität zu HTML 4-Benutzerprogrammen sicher stellen, finden Sie in den HTML-Kompatibilitätsrichtlinien (Anhang C).

RICHTIG: Abgeschlossene leere Elemente
<br/><hr/>
FALSCH: Nicht abgeschlossene leere Elemente
<br><hr>

4.7 Behandlung von Leerraum in Attributwerten

Wenn Benutzerprogramme Attribute verarbeiten, so tun sie dies gemäß Abschnitt 3.3.3 in [XML]:

4.8 Script- und Style-Elemente

In XHTML sind die Schrift- und Stilelemente so deklariert, dass sie #PCDATA-Inhalt haben. Demzufolge werden < und & als Anfang des Markups behandelt, und Entities wie beispielsweise &lt; und &amp; werden vom Prozessor als Entity-Verweise für < bzw. & erkannt. Hüllt man den Inhalt des Schrift- oder Stilelements in einen mit CDATA markierten Abschnitt ein, vermeidet man dadurch die Erweiterung dieser Entities.

<script type=“text/javascript“>
<![CDATA[
... nicht maskierter script-Inhalt...
]]>
</script>

CDATA-Abschnitte werden vom XML-Prozessor erkannt und erscheinen als Knoten im Document Object Model (siehe Abschnitt 1.3 der DOM Level 1 Empfehlung [DOM]).

Als Alternative kann man externe Schrift- und Stildokumente verwenden.

4.9 SGML-Ausschlüsse

SGML bietet dem Entwickler einer DTD die Möglichkeit, für spezielle Elemente auszuschließen, dass sie Inhalt eines anderen Elements werden. Solche Ausschlüsse sind in XML nicht möglich.

Die strenge DTD von HTML 4 beispielsweise verbietet, ein 'a'-Element in einem anderen 'a'-Element in einer beliebigen abgeleiteten Tiefe zu verschachteln. In XML ist es nicht möglich, solche Ausschlüsse zu formulieren. Selbst wenn diese Ausschlüsse in der DTD nicht definiert werden können, sollten bestimmte Elemente nicht verschachtelt werden. Einen Überblick über diese Elemente und die Elemente, die nicht darin verschachtelt werden sollten, finden Sie im normativen Anhang B.

4.10 Die Elemente mit 'id'- und 'name'-Attributen

HTML 4 hat das name-Attribut für die Elemente a, applet, form, frame, iframe, img und map definiert. Darüber hinaus hat HTML 4 das id-Attribut eingeführt. Beide Attribute sind für die Verwendung als Fragmentbezeichner vorgesehen.

In XML haben Fragmentbezeichner den Typ ID, und es kann nur ein einziges Attribut des Typs ID pro Element geben. Deshalb ist das id-Attribut in XHTML 1.0 als vom Typ ID definiert. Um sicherzustellen, dass XHTML 1.0-Dokumente korrekt strukturierte XML-Dokumente sind, müssen XTHML 1.0-Dokumente das id-Attribut verwenden, wenn sie Fragmentbezeichner für die o.g. Elemente definieren. Weitere Informationen darüber, wie Sie sicherstellen, dass solche Anker abwärtskompatibel sind, wenn Sie XHTML-Dokumente als Medientyp text/html bereitstellen, finden Sie in den Richtlinien zur HTML-Kompatibilität (Anhang C).

Beachten Sie, dass in XHTML 1.0 das name-Attribut dieser Elemente formal veraltet ist und in einer zukünftigen Version von XHTML entfernt wird.

4.11 Attribute mit vordefinierten Wertemengen

Sowohl HTML 4 als auch XHTML besitzen einige Attribute, die vordefinierte und eingeschränkte Werte haben (z.B. das type-Attribute des input-Elements). In SGML und XML werden sie Aufzählungsattribute genannt. In HTML 4 war die Interpretation dieser Werte von der Groß/Kleinschreibung unabhängig, so dass der Wert „TEXT“ äquivalent zu „text“ ist. Durch XML ist die Interpretation dieser Werte von der Groß/Kleinschreibung abhängig, und in XHTML 1 sind alle diese Werte in Kleinschreibweise definiert.

4.12 Entity-Referenzen als hexadezimaler Wert

Sowohl SGML als auch XML erlauben Zeichenreferenzen in Form von hexadezimalen Werten. In SGML konnten diese Referenzen entweder in &#Xnn; oder &#xnn; geschrieben werden. In XML-Dokumenten müssen Sie die Kleinschreibung verwenden (d.h. &#xnn;).

Kompatibilitätsaspekte

Dieser Abschnitt ist normativ.

Obwohl nicht gefordert wird, dass XHTML 1.0-Dokumente mit existierenden Benutzerprogrammen kompatibel sind, ist dies in der Praxis ganz einfach zu bewerkstelligen. Richtlinien für die Erstellung kompatibler Dokumente finden Sie in Anhang C.

5.1 Internet-Medientyp

XHTML-Dokumente, die den in Anhang C beschriebenen Richtlinien zur Kompatibilität mit HTML folgen, können mit dem Internet-Medientyp "text/html" ausgezeichnet werden [RFC2854], weil sie mit den meisten HTML-Browsern kompatibel sind. Diese Dokumente und alle anderen, die konform zu dieser Spezifikation sind, können außerdem mit dem Internet-Medientyp "application/xhtml+xml" ausgezeichnet werden [RFC3236]. Für weitere Informationen über die Verwendung von Medientypen mit XHTML lesen Sie bitte die informelle Note [XHTMLMIME].

Anhang A: DTDs

Dieser Abschnitt ist normativ.

Diese DTDs und Entity-Mengen bilden einen normativen Teil dieser Spezifikation. Die vollständige Menge der DTD-Dateien zusammen mit einer XML-Deklaration und SGML Open Catalog ist in der Zip-Datei und der Gzip/Tar-Datei für diese Spezifikation enthalten. Benutzer, die lokale Kopien suchen, um damit zu arbeiten, sollten die Archiv-Dateien herunterladen, anstatt mit den nachfolgend referenzierten DTDs zu arbeiten.

A.1 Dokumenttypdefinitionen

Diese DTDs sind den HTML 4 DTDs annähernd gleich. Das W3C empfiehlt, dass Sie die maßgeblichen Versionen dieser DTDs unter ihren definierten Systembezeichnern verwenden, wenn Sie den Inhalt validieren. Wenn Sie diese DTDs lokal benötigen, sollten Sie eines der Archive herunterladen. Zur Vollständigkeit sind die normativen Versionen der DTDs hier zu finden:

A.1.1. XHTML-1.0-Strict

Die Datei DTD/xhtml1-strict.dtd ist ein normativer Bestandteil dieser Spezifikation. Der Vollständigkeit halber ist der kommentierte Inhalt dieser Datei in einem eigenen Abschnitt erhältlich.

A.1.2. XHTML-1.0-Transitional

Die Datei DTD/xhtml1-transitional.dtd ist ein normativer Bestandteil dieser Spezifikation. Der Vollständigkeit halber ist der kommentierte Inhalt dieser Datei in einem eigenen Abschnitt erhältlich.

A.1.3. XHTML-1.0-Frameset

Die Datei DTD/xhtml1-frameset.dtd ist ein normativer Bestandteil dieser Spezifikation. Der Vollständigkeit halber ist der kommentierte Inhalt dieser Datei in einem eigenen Abschnitt erhältlich.

A.2 Entity-Mengen

Die XHTML-Entity-Mengen sind dieselben wie für HTML 4, wurden aber angepasst, so dass sie gültige XML 1.0-Entity-Deklarationen darstellen. Beachten Sie das Entity für das Euro-Währungssymbol (&euro; oder &#8364; oder &#x20AC;), das als Teil der Sonderzeichen definiert ist.

A.2.1. Latin-1 characters

Die Datei DTD/xhtml-lat1.ent ist ein normativer Bestandteil dieser Spezifikation. Der Vollständigkeit halber ist der kommentierte Inhalt dieser Datei in einem eigenen Abschnitt erhältlich.

A.2.2. Special characters

Die Datei DTD/xhtml-special.ent ist ein normativer Bestandteil dieser Spezifikation. Der Vollständigkeit halber ist der kommentierte Inhalt dieser Datei in einem eigenen Abschnitt erhältlich.

A.2.3. Symbols

Die Datei DTD/xhtml-symbol.ent ist ein normativer Bestandteil dieser Spezifikation. Der Vollständigkeit halber ist der kommentierte Inhalt dieser Datei in einem eigenen Abschnitt erhältlich.

Anhang B: Element-Ausschlüsse

Dieser Abschnitt ist normativ.

Die folgenden Elemente weisen Ausschlüsse dahingehend auf, welche Elemente sie enthalten können (siehe Abschnitt 4.9). Diese Ausschlüsse gelten für alle Verschachtelungstiefen, das heißt, sie erstrecken sich auf alle abgeleiteten Elemente.

a
Darf keine anderen a-Elemente enthalten.
pre
Darf nicht die Elemente img, object, big, small, sub oder sup enthalten.
button
Darf nicht die Elemente input, select, textarea, label, button, form, fieldset, iframe oder isindex enthalten.
label
Darf keine anderen label-Elelemente enthalten.
form
Darf keine anderen form-Elemente enthalten.

Anhang C: Richtlinien zur HTML-Kompatibilität

Dieser Abschnitt ist informell.

Dieser Anhang fasst die Design-Richtlinien für Autoren zusammen, die ihre XHTML-Dokumente auf bereits existierenden HTML-Benutzerprogrammen anzeigen wollen. Beachten Sie, dass diese Empfehlung nicht definiert, wie zu HTML konforme Benutzerprogramme HTML-Dokumente verarbeiten sollten. Auch definiert sie nicht die Bedeutung des Internet-Medientyps text/html. Für diese Definitionen lesen Sie bitte [HTML4] bzw. [RFC2854].

C.1 Verarbeitungsanweisungen und die XML-Deklaration

Beachten Sie, dass Verarbeitungsanweisungen auf einigen Benutzerprogrammen dargestellt werden. Außerdem interpretieren einige Benutzerprogramme die XML-Deklaration so, als ob sie unbekanntes XML statt HTML vor sich hätten; und folglich stellen sie das Dokument nicht wie erwartet dar. Zur Kompatibilität mir diesen alten Browsern können Sie auf Verarbeitungsanweisungen und XML-Deklarationen verzichten. Beachten Sie jedoch auch, dass, wenn die XML-Deklaration nicht in ein Dokument aufgenommen ist, das Dokument nur die Standard-Zeichencodierungen UTF-8 oder UTF-16 verwenden kann.

C.2 Leere Elemente

Fügen Sie ein Leerzeichen vor dem führenden / und > leerer Elemente ein. z.B. <br />, <hr /> und <img src="karen.jpg" alt="Karen" />. Verwenden Sie darüber hinaus die minimierte Tag-Syntax für leere Elemente, z.B. <br />, weil die alternative Syntax <br></br>, die von XML erlaubt ist, unsichere Ergebnisse in vielen bereits existierenden Benutzerprogrammen erzeugt.

C.3 Elementminimierung und leerer Elementinhalt

Für eine leere Instanz eines Elements, dessen Inhaltsmodell nicht EMPTY ist (z.B. ein leerer Titel oder Absatz), verwenden Sie nicht die minimierte Form (verwenden Sie z.B. <p> </p>, und nicht <p />).

C.4 Eingebettete Stylesheets und Skripte

Verwenden Sie externe Stylesheets, wenn Ihr Stylesheet < oder & oder ]]> oder verwendet. Verwenden Sie externe Skripts, wenn Ihr Skript < oder & oder ]]> oder verwendet. Beachten Sie, dass XML-Parser den Inhalt von Kommentaren stillschweigend entfernen dürfen. Die bisherige Vorgehensweise, Skripts und Stylesheets innerhalb von „Kommentaren“ zu „verstecken“, um die Dokumente abwärtskompatibel zu machen, funktioniert also sehr wahrscheinlich in auf XML basierenden Benutzerprogrammen nicht, wie erwartet.

C.5 Zeilenumbrüche innerhalb von Attributwerten

Vermeiden Sie Zeilenumbrüche und mehrere aufeinanderfolgende Leerraumzeichen innerhalb von Attributwerten. Sie werden von den Benutzerprogrammen inkonsistent behandelt.

C.6 Isindex

Nehmen Sie nicht mehr als ein isindex-Element in den Dokument-head auf. Das isindex-Element ist veraltet und wird durch das input-Element ersetzt.

C.7 Die Attribute lang and xml:lang

Verwenden Sie für die Angabe der Sprache eines Dokuments die Attribute lang und xml:lang. Der Wert des Attributs xml:lang hat Priorität.

C.8 Fragmentbezeichner

In XML verweisen URI-Referenzen [RFC2396], die mit Fragmentbezeichnern der Form "#foo" enden, nicht auf Elemente mit einem Attribut name="foo"; stattdessen verweisen sie auf Elemente mit einem Attribut, das als vom Typ ID definiert ist, z.B. das id-Attribut in HTML 4. Viele bereits existierende HTML-Clients unterstützen die Verwendung von Attributen vom Typ ID auf diese Weise nicht, deshalb können identische Werte für beide Attribute angegeben werden, um eine maximale Aufwärts- und Abwärtskompatibilität sicherzustellen (z.B. <a id="foo" name="foo">...</a>).

Und weil darüber hinaus die Menge der erlaubten Werte für Attribute des Typs ID viel kleiner als die für den Typ CDATA ist, muss der Typ des name-Attributs in NMTOKEN geändert werden. Dieses Attribut ist beschränkt, weil es nur dieselben Werte wie der Typ ID haben kann oder wie die Name-Produktion in XML 1.0 Abschnitt 2.3 Produktion 5. Leider kann diese Beschränkung in den DTDs von XHTML 1.0 nicht ausgedrückt werden. Aufgrund dieser Änderung muss die Umwandlung existierender HTML-Dokumente äußerst sorgfältig erfolgen. Die Werte dieser Attribute müssen eindeutig innerhalb des Dokuments und gültig sein, und alle Verweise auf diese Fragmentbezeichner (sowohl intern als auch extern) müssen aktualisiert werden, falls sich die Werte während der Umwandlung ändern.

Beachten Sie, dass die Menge der erlaubten Werte in XML 1.0, Abschnitt 2.3, Produktionsregel 5, viel größer ist als das, was duch die in HTML 4 definierten ID- und NAME-Typen erlaubt ist. Wenn Sie Fragmenbezeichner definieren, die abwärtskompatibel sein sollen, sollten nur solche Zeichenketten verwendet werden, die zu dem Muster [A-Za-z][A-Za-z0-9:_.-]* passen. Siehe [HTML4], Abschnitt 6.2 für weitere Informationen.

Beachten Sie schließlich, dass XHTML 1.0 das name-Attribut der Elemente a, applet, form, frame, iframe, img und map als veraltet betrachtet und es in späteren Versionen aus XHTML entfernt wird.

C.9 Zeichencodierung

Historisch wurde die Zeichenkodierung eines HTML-Dokuments entweder durch einen Web-Server durch Angabe des charset-Parameters im HTTP Content Type Header oder durch ein Meta-Element im Dokument selbst angegeben. In einem XML-Dokument wird die Zeichenkodierung des Dokuments durch die XML-Deklaration angegeben (z.B. <?xml version="1.0" encoding="EUC-JP"?>). Der beste Ansatz, um Dokumente mit einer bestimmten Zeichenkodierung möglichst portabel anzubieten, besteht darin, sicherzustellen, dass der Web-Server die korrekten Header verwendet. Wenn das nicht möglich ist, muss ein Dokument, das seine Zeichenkodierung explizit setzen will, sowohl die XML-Deklaration mit Kodierungsdeklaration als auch einen Meta-http-equiv-Ausdruck (z.B. <meta http-equiv="Content-type" content="text/html; charset=EUC-JP" />) angeben. Der Wert des Kodierungsattributs der XML-Verarbeitungsanweisung hat in XHTML-konformen Benutzerprogrammen Priorität.

Hinweis: Beachten Sie, dass ein Dokument, das die Zeichenkodierungsdeklaration in einem Meta-http-equiv-Ausdruck enthalten muss, durch einen HTTP-Server und/oder durch Benutzerprogramme als vom angegebenen Medientyp angesehen werden kann. Wenn ein Dokument unter mehreren Medientypen verschickt werden soll, dann muss der HTTP-Server zum Setzen der Kodierung verwendet werden.

C.10 Boolesche Attribute

Einige HTML-Benutzerprogramme können keine Booleschen Attribute interpretieren, wenn diese in ihrer vollständigen (nicht minimierten) Form auftreten, wie in XML 1.0 gefordert. Beachten Sie, dass dieses Problem keinen Einfluss auf Benutzerprogramme hat, die konform zu HTML 4 sind. Die folgenden Attribute sind betroffen: compact, nowrap, ismap, declare, noshade, checked, disabled, readonly, multiple, selected, noresize, defer.

C.11 Document Object Model und XHTML

Die Document Object Model Level 1 Empfehlung [DOM] definiert Dokumentobjektmodellschnittstellen für XML und HTML 4. Das HTML 4-Dokumentobjektmodell spezifiziert, dass HTML-Element- und Attributnamen in Großbuchstaben zurückgegeben werden. Das XML-Dokumentobjektmodell spezifiziert, dass Element- und Attributnamen so zurückgegeben werden, wie sie angegeben wurden. In XHTML 1.0 werden Elemente und Attribute in Kleinbuchstaben angegeben. Dieser offensichtliche Unterschied kann auf zwei Arten kompensiert werden:

  1. Benutzerprogramme, die auf XHTML-Dokumente zugreifen, die als Internet-Medientyp text/html über das DOM bereitgestellt werden, können das HTML DOM verwenden und davon ausgehen, dass Element- und Attributnamen von diesen Schnittstellen in Großbuchstaben zurückgegeben werden.
  2. Benutzerprogramme, die auf XHTML-Dokumente zugreifen, die als Internet-Medientypen text/xml, application/xml oder application/xhtml+xml bereitgestellt werden, können ebenfalls das XML DOM verwenden. Elemente und Attribute werden in Kleinbuchstaben zurückgegeben. Darüber hinaus kann es sein, dass bestimmte Elemente im Objektbaum erscheinen oder nicht erscheinen, weil einige im Inhaltsmodell optional sind (z.B. das tbody-Element in table). Das passiert, weil in HTML 4 einige Elemente minimiert sein durften, so dass ihre Start- und End-Tags weggelassen werden konnten (ein SGML-Funktionsmerkmal). In XML ist das nicht möglich. Statt von den Dokumentautoren zu fordern, unwesentliche Elemente einzufügen, hat XHTML die Elemente optional gemacht. Benutzerprogramme müssen dies entsprechend übernehmen. Für weitere Informationen siehe [DOM2].

C.12 Die Verwendung von et-Zeichen in Attributwerten (und anderswo)

Sowohl in SGML als auch in XML bezeichnet das et-Zeichen (&) den Anfang einer Entity-Referenz (z.B. &reg; für "®"). Unglücklicherweise haben viele HTML-Benutzerprogramme die unkorrekte Benutzung des et-Zeichens stillschweigend ignoriert. Sie haben et-Zeichen, die nicht wie Entity-Referenzen aussehen, als „wörtliche“ et-Zeichen behandelt. XML-basierte Benutzerprogramme werden diese unkorrekte Verwendung nicht tolerieren. Jedes Dokument, das ein et-Zeichen unkorrekt benutzt, wird nicht gültig sein und folglich nicht konform zu dieser Spezifikation sein. Um sicherzustellen, dass Dokumente mit alten HTML-Benutzerprogrammen und XML-basierten Benutzerprogrammen kompatibel sind, müssen et-Zeichen, die als normale Zeichen behandelt werden sollen, selbst als Entity-Referenzen (d.h. &amp;) geschrieben werden. Verweist beispielsweise das href-Attribut des a-Elements auf ein CGI-Skript, das Parameter entgegennimmt, muss es wie folgt ausgedrückt werden: http://my.site.dom/cgi-bin/myscript.pl?class=guest&amp;name=user, und nicht als http://my.site.dom/cgi-bin/myscript.pl?class=guest&name=user.

C.13 Cascading Style Sheets (CSS) und XHTML

Die Cascading Style Sheets Level 2-Empfehlung [CSS2] definiert Stileigenschaften, die auf den Parsing-Baum des HTML- oder XML-Dokuments angewendet werden. Unterschiede beim Parsing erzeugen unterschiedliche visuelle oder akustische Ergebnisse, abhängig von den verwendeten Selektoren. Die folgenden Hinweise reduzieren diesen Effekt für Dokumente, die ohne Veränderung als beide Medientypen bereitgestellt werden:

  1. CSS-Stylesheets für XHTML sollten für Element- und Attributnamen Kleinbuchstaben verwenden.
  2. In Tabellen wird das tbody-Element durch den Parser eines HTML-Benutzerprogramms abgeleitet, nicht aber vom Parser eines XML-Benutzerprogramms. Deshalb sollten Sie immer explizit ein tbody-Element einfügen, wenn in einem CSS-Selektor darauf verwiesen wird.
  3. Innerhalb des XHTML-Namensraums geht man davon aus, dass Benutzerprogramme das id-Attribut als Attribut des Typs ID erkennen. Deshalb sollten Stylesheets in der Lage sein, die abkürzende Selektorsyntax "#" weiterhin zu erkennen, auch wenn das Benutzerprogramm die DTD nicht liest.
  4. Innerhalb des XHTML-Namensraums erwartet man von den Benutzerprogrammen, dass sie das class-Attribut erkennen. Deshalb sollten die Stylesheets weiterhin in der Lage sein, die abkürzende Selektorsyntax „.“ zu verwenden.
  5. CSS definiert unterschiedliche Konformitätsregeln für HTML- und XML-Dokumente; beachten Sie, dass die HTML-Regeln für XHTML-Dokumente gelten, die als HTML ausgeliefert werden, und die XML-Regeln für XHTML-Dokumente, die als XML ausgeliefert werden.

C.14 Referenzierung von Style-Elementen bei Verwendung als XML

In HTML 4 und in XHTML kann das style-Element benutzt werden, um dokumentinterne Formatierungsregeln zu definieren. In XML wird eine XML-Stylesheet-Deklaration verwendet, um Formatierungsregeln zu definieren. Um mit dieser Konvention kompatibel zu sein, sollten style-Elemente ihren Fragmentbezeichner mit Hilfe des id-Attributs setzen. Eine XML-Stylesheet-Deklaration sollte dieses Fragment referenzieren. Zum Beispiel:

<?xml-stylesheet href="http://www.w3.org/StyleSheets/TR/W3C-REC.css" type="text/css"?>
<?xml-stylesheet href="#internalStyle" type="text/css"?>
<html xmlns="http://www.w3.org/1999/xhtml"
xml:lang="en"
lang="en">
<head>
<title>An internal stylesheet example</title>
<style id="internalStyle">
code {
color: green;
font-family: monospace;
font-weight: bold;
}
</style>
</head>
<body>
<p>
This is text that uses our
<code>internal stylesheet</code>.
</p>
</body>
</html>

C.15 Leerraumzeichen in HTML vs. XML

Einige Zeichen, die in HTML-Dokumenten erlaubt sind, sind in XML-Dokumenten nicht erlaubt. Zum Beispiel wird das Seitenvorschubzeichen (Form-feed, U+000C) in HTML als Leeraum behandelt. In XHTML ist es wegen der Zeichendefinition von XML nicht erlaubt.

C.16 Die benannte Zeichenreferenz &apos;

Die benannte Zeichenreferenz &apos; (das Apostroph, U+0027) wurde in XML 1.0 eingeführt, erscheint aber nicht in HTML. Autoren sollten deshalb &#39; anstelle von &apos; verwenden, damit es wie erwartet mit HTML 4-Benutzerprogrammen läuft.

Anhang D: Danksagungen

Dieser Abschnitt ist informell.

Diese Spezifikation wurde unter Beteiligung der Mitglieder der HTML-Arbeitsgruppe des W3C geschrieben.

Bei Veröffentlichung der zweiten Auflage hatte die Arbeitsgruppe folgende Mitglieder:

Steven Pemberton, CWI/W3C (HTML Working Group Chair); Daniel Austin, Grainger; Jonny Axelsson, Opera Software; Tantek Çelik, Microsoft; Doug Dominiak, Openwave Systems; Herman Elenbaas, Philips Electronics; Beth Epperson, Netscape/ AOL; Masayasu Ishikawa, W3C (HTML Activity Lead); Shin'ichi Matsui, Panasonic; Shane McCarron, Applied Testing and Technology; Ann Navarro, WebGeek, Inc.; Subramanian Peruvemba, Oracle; Rob Relyea, Microsoft; Sebastian Schnitzenbaumer, SAP; Peter Stark, Sony Ericsson

Bei Veröffentlichung der ersten Auflage hatte die Arbeitsgruppe folgende Mitglieder:

Steven Pemberton, CWI (HTML Working Group Chair); Murray Altheim, Sun Microsystems; Daniel Austin, AskJeeves (CNET: The Computer Network bis Juli 1999); Frank Boumphrey, HTML Writers Guild; John Burger, Mitre; Andrew W. Donoho, IBM; Sam Dooley, IBM; Klaus Hofrichter, GMD; Philipp Hoschka, W3C; Masayasu Ishikawa, W3C; Warner ten Kate, Philips Electronics; Peter King, Phone.com; Paula Klante, JetForm; Shin'ichi Matsui, Panasonic (W3C Gast-Ingenieur bis September 1999); Shane McCarron, Applied Testing and Technology (The Open Group bis August 1999); Ann Navarro, HTML Writers Guild; Zach Nies, Quark; Dave Raggett, W3C/HP (HTML Activity Lead); Patrick Schmitz, Microsoft; Sebastian Schnitzenbaumer, Stack Overflow; Peter Stark, Phone.com; Chris Wilson, Microsoft; Ted Wugofski, Gateway 2000; Dan Zigmond, WebTV Networks

Anhang E: Literaturverzeichnis

Dieser Abschnitt ist informell.

[CSS2]
"Cascading Style Sheets, level 2 (CSS2) Specification", B. Bos, H. W. Lie, C. Lilley, I. Jacobs, 12. Mai 1998. Neueste Version unter: http://www.edition-w3c.de/TR/REC-CSS2
[DOM]
"Document Object Model (DOM) Level 1 Specification", Lauren Wood et al., 1. Oktober 1998. Neueste Version unter: http://www.edition-w3c.de/TR/REC-DOM-Level-1
[DOM2]
"Document Object Model (DOM) Level 2 Core Specification ", A. Le Hors, et al. ,13 November 2000. Neueste Version unter: http://www.edition-w3c.de/TR/DOM-Level-2-Core .
[HTML]
"HTML 4.01 Specification", D. Raggett, A. Le Hors, I. Jacobs, 24. Dezember 1999. Neueste Version unter: http://www.edition-w3c.de/TR/html401
[POSIX.1]
"ISO/IEC 9945-1:1990 Information Technology - Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API) [C Language]", Institute of Electrical and Electronics Engineers, Inc, 1990.
[RFC2045]
"Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", N. Freed and N. Borenstein, November 1996. Dieser RFC ersetzt die veralteten RFC1521, RFC1522, und RFC1590.
[RFC2046]
"RFC2046: Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", N. Freed und N. Borenstein, November 1996. Verfügbar unter: http://www.ietf.org/rfc/rfc2046.txt. Beachten Sie, dass nach diesem RFC die RFCs RFC1521, RFC1522 und RFC1590 veraltet sind.
[RFC2119]
"RFC2119: Key words for use in RFCs to Indicate Requirement Levels", S. Bradner, März 1997. Verfügbar unter: http://www.ietf.org/rfc/rfc2119.txt
[RFC2376]
"RFC2376: XML Media Types", E. Whitehead, M. Murata, Juli 1998. Verfügbar unter: http://www.ietf.org/rfc/rfc2376.txt
[RFC2396]
"RFC2396: Uniform Resource Identifiers (URI): Generic Syntax", T. Berners-Lee, R. Fielding, L. Masinter, August 1998. Dieses Dokument aktualisiert RFC1738 und RFC1808. Verfügbar unter: http://www.ietf.org/rfc/rfc2396.txt
[RFC2854]
"RFC2854: The text/html Media Type", D. Conolly, L. Masinter, June 2000. Verfügbar unter: http://www.ietf.org/rfc/rfc2854.txt
[RFC3023]
"RFC3023: XML Media Types", M. Murata, S. St.Laurent, D. Kohn, Januar 2001. Dieses Dokument ersetzt den veralteten [RFC2376]. Verfügbar unter: http://www.ietf.org/rfc/rfc3023.txt
[RFC3066]
"Tags for the Identification of Languages", H. Alvestrand, Januar 2001. Verfügbar unter: http://www.ietf.org/rfc/rfc3066.txt
[RFC3236]
"The 'application/xhtml+xml' Media Type", M. Baker, P. Stark, January 2002. Verfügbar unter: http://www.ietf.org/rfc/rfc3236.txt
[XHTML+MathML]
"XHTML plus Math 1.1 DTD", "A.2 MathML as a DTD Module", Mathematical Markup Language (MathML) Version 2.0. Verfügbar unter: http://www.edition-w3c.de/TR/MathML2/dtd/xhtml-math11-f.dtd
[XHTMLMIME]
" XHTML Media Types ", Masayasu Ishikawa, 1 August 2002. Neueste Version unter: http://www.edition-w3c.de/TR/xhtml-media-types
[XHTMLMOD]
"Modularization of XHTML", M. Altheim et al., 10 April 2001. Neueste Version unter: http://www.edition-w3c.de/TR/xhtml-modularization
[XML]
"Extensible Markup Language (XML) 1.0 Specification", T. Bray, J. Paoli, C. M. Sperberg-McQueen, 10. Februar 1998. Neueste Version unter: http://www.edition-w3c.de/TR/REC-xml
[XMLNAMES]
"Namespaces in XML", T. Bray, D. Hollander, A. Layman, 14.Januar 199. XML-Namensräume stellen eine einfache Methode für die Qualifizierung von Namen dar, die in XML-Dokumenten verwendet werden, indem ihnen Namensräume zugeordnet sind, die durch URI identifiziert werden. Neueste Version unter: http://www.edition-w3c.de/TR/REC-xml-names
[XMLC14N]
"Canonical XML Version 1.0", J. Boyer, 15 March 2001. Dieses Dokument beschreibt ein Verfahren zur Erzeugung einer physischen Repräsentation, die kanonische Form, eines XML-Dokuments. Aktuelle Version erhältlich unter http://www.edition-w3c.de/TR/xml-c14n

Stichwortverzeichnis