XHTML 1.0: Die Extensible HyperText Markup Language

Deutsche Übersetzung

Diese Version:
http://www.websitedev.de/xhtml/xhtml1/20000126/
Neuste Version:
http://www.websitedev.de/xhtml/xhtml1/
Vorherige Version:
keine
Übersetzer:
Björn Höhrmann <bjoern@hoehrmann.de>

Dies ist die deutsche Übersetzung der W3C Empfehlung "XHTML 1.0: The Extensible HyperText Markup Language" vom 26. Januar 2000. Dieses Dokument kann Übersetzungsfehler enthalten. Die normative englische Version des Dokumentes befindet sich unter http://www.w3.org/TR/2000/REC-xhtml1-20000126

Bitte melde Fehler oder Verbesserungsvorschläge zu dieser Übersetzung an den Übersetzer oder die Mailingliste www-trans-de@egroups.com (Archiv).

Ich bedanke mich bei allen, die sich an der Übersetzung direkt oder indirekt beteiligt haben, insbesondere bei Jens Kubieziel und Alan J. Flavell.

Dieses Dokument ist urheberrechtlich geschützt, Copyright © 1999 - 2000 W3C® (MIT, INRIA, Keio), All Rights Reserved. Die Rechte an der Übersetzung liegen beim Übersetzer, Copyright © 2000 Björn Höhrmann.


W3C

XHTML 1.0: Die Extensible HyperText Markup Language

Eine Reformulierung von HTML 4 in XML 1.0

W3C Empfehlung 26. Januar 2000

Diese Version:
http://www.w3.org/TR/2000/REC-xhtml1-20000126
(Postscript version, PDF Version, ZIP Archiv, or Gzip'd TAR Archiv)
Neuste Version:
http://www.w3.org/TR/xhtml1
Vorherige Version:
http://www.w3.org/TR/1999/PR-xhtml1-19991210
Autoren:
Siehe Danksagungen.

Zusammenfassung

Diese Spezifikation definiert XHTML 1.0, eine Reformulierung von HTML 4 als XML 1.0 Anwendung und drei DTDs, die den durch HTML 4 definierten entsprechen. Die Semantik der Elemente und ihrer Attribute wird in der W3C Empfehlung für HTML 4 definiert. Diese Semantik schafft die Grundlage für die zukünftige Erweiterbarkeit von XHTML. Kompatibilität mit vorhandenen HTML Benutzeragenten ist möglich, indem ein kleiner Satz Richtlinien befolgt wird.

Status dieses Dokumentes

Dieser Abschnitt beschreibt den Status dieses Dokumentes zum Zeitpunkt seiner Veröffentlichung. Es kann sein, daß andere Dokumente dieses Dokument ablösen. Der letzte Status dieser Dokumentserie wird beim W3C verwaltet.

Dieses Dokument ist von Mitgliedern des W3C und anderen interessierten Parteien geprüft und vom Direktor als W3C Empfehlung unterstützt worden. Es ist ein stabiles Dokument und kann als Referenzmaterial verwendet oder als normative Referenz von einem anderen Dokument angeführt werden. Die Aufgabe des W3Cs bei der Erstellung der Empfehlung ist es, Aufmerksamkeit auf diese Spezifikation zu lenken und ihre weite Verbreitung zu fördern. Dies verbessert die Funktionalität und die Interoperabilität des Webs.

Dieses Dokument wurde als Teil der W3C HTML Aktivität erstellt. Die Ziele der HTML Arbeitsgruppe (nur für Mitglieder) werden in der Charta der HTML Arbeitsgruppe (nur für Mitglieder) besprochen.

Eine Liste aktueller W3C Empfehlungen und anderer technischer Dokumente kann bei http://www.w3.org/TR gefunden werden.

Öffentliche Diskussionen über HTML Merkmale finden auf der Mailling-Liste www-html@w3.org (Archiv) statt.

Bitte melde Fehler in diesem Dokument bei www-html-editor@w3.org.

Die Liste bekannter Fehler in dieser Spezifikation ist unter http://www.w3.org/2000/01/REC-xhtml1-20000126-errata erhältlich.

Inhalt

1. Was ist XHTML?

XHTML ist eine Familie bestehender und zukünftiger Dokumenttypen und Module die HTML 4 [HTML] reproduzieren, unterteilen und erweitern. Dokumenttypen der XHTML Familie sind XML basierend und letztlich bestimmt, um in Verbindung mit XML-basierenden Benutzeragenten zu arbeiten. Die Einzelheiten dieser Familie und ihre Entwicklung werden detaillierter im Abschnitt über Zukünftige Entwicklungen besprochen.

XHTML 1.0 (diese Spezifikation) ist der erste Dokumenttyp der XHTML Familie. Es ist eine Reformulierung der drei HTML 4 Dokumenttypen als Anwendungen von XML 1.0 [XML]. Es ist beabsichtigt, daß er als Sprache für Inhalte verwendet wird, die sowohl XML-konform sind und, wenn einige einfache Richtlinien befolgt werden, in HTML 4 konformen Benutzeragenten funktionieren. Entwickler, die die Inhalte ihrer Seiten auf XHTML 1.0 umstellen, werden die folgenden Vorteile feststellen:

Die XHTML Familie ist der nächste Schritt in der Weiterentwicklung des Internets. Indem Inhaltsentwickler heute auf XHTML umsteigen, können sie in die XML-Welt mit allen dazugehörigen Vorteilen einsteigen, während sie sich auf die Abwärts- wie auch die zukünftige Kompatibilität ihrer Inhalte verlassen können.

1.1 Was ist HTML 4?

HTML 4 [HTML] ist eine SGML (Standard Generalized Markup Language) Anwendung entsprechend dem Internationalen Standard ISO 8879 und wird allgemein als die Standard-Veröffentlichungssprache des World Wide Web angesehen.

SGML ist eine Sprache zur Beschreibung von Markup Sprachen, insbesondere solcher, die im elektronischen Dokumentaustausch, Dokumentmanagement und der Dokumentveröffentlichung benutzt werden. HTML ist ein Beispiel für eine in SGML definierte Sprache.

SGML gibt es seit Mitte der 80er Jahre und ist ziemlich stabil geblieben. Ein großer Teil dieser Stabilität kommt von der Tatsache, daß die Sprache sowohl merkmalsreich wie auch flexibel ist. Jedoch hat diese Flexibilität auch einen Preis. Dieser Preis ist ein Maß an Komplexität, die ihre Annahme in einer Vielzahl von Umgebungen gehemmt hat, einschließlich des World Wide Web.

HTML, wie ursprünglich erdacht, sollte eine Sprache für den Austausch wissenschaftlicher und anderer technischer Dokumente sein, die sich auch für den Gebrauch durch Nichtdokumentspezialisten eignet. HTML nahm sich dem Problem der Komplexität von SGML an, indem sie einen kleinen Satz struktureller und semantischer Tags festlegt, geeignet um relativ einfache Dokumente zu erstellen. Zusätzlich zum Vereinfachen der Dokumentstruktur fügte HTML Unterstützung für Hypertext hinzu. Multimediafähigkeiten wurden später hinzugefügt.

In einem bemerkenswert kurzen Zeitraum wurde HTML sehr populär und wuchs schnell über ihre ursprüngliche Bestimmung hinaus. Seit der Einführung von HTML hat es einen schnellen Prozess, neue Elemente zum Gebrauch innerhalb von HTML (als Norm) und zur Anpassung von HTML an vertikale, äußerst spezialisierte Märkte zu erfinden, gegeben. Diese Unmenge neuer Elemente hat zu Kompatibilitätsproblemen für Dokumente zwischen verschiedenen Plattformen geführt.

Da sich die Heterogenität sowohl von Software als auch von Plattformen schnell vermehrte, ist klar, daß die Eignung von 'klassischem' HTML 4 zum Gebrauch auf diesen Plattformen ein wenig eingeschränkt ist.

1.2 Was ist XML?

XML ist die Abkürzung für Extensible Markup Language und ein Akronym für Extensible Markup Language [XML].

XML wurde als ein Mittel erdacht, die Stärke und Flexibilität von SGML ohne ihre Komplexität zu erhalten.

Während XML diese nützlichen Merkmale bewahrt, entfernt sie viele der komplexeren Merkmale von SGML, die die Erstellung und Gestaltung geeigneter Software sowohl schwierig als auch teuer machen.

1.3 Warum ist XHTML notwendig?

Die Vorteile, auf XHTML 1.0 umzustellen, werden oben beschrieben. Einige der Vorteile, in XHTML im allgemeinen umzustellen, sind:

2. Definitionen

2.1 Terminologie

Die folgenden Begriffe werden in dieser Spezifikation verwendet. Diese Begriffe erweitern die Definitionen in [RFC2119] basierend auf ähnlichen Definitionen in ISO/IEC 9945-1:1990 [POSIX.1]:

Implementierungsdefiniert (implementation-defined)
Ein Wert oder ein Verhalten sind implementierungsdefiniert, wenn es der Implementierung überlassen wird, die entsprechenden Erfordernisse für richtige Dokumentkonstruktion zu definieren [und zu dokumentieren].
Darf (may)
In bezug auf Implementierungen soll das Wort "darf" als optionales Merkmal interpretiert werden, das nicht von dieser Spezifikation gefordert wird, aber angeboten werden kann. In bezug auf die Dokument-Konformität bedeutet das Wort "darf", daß das optionale Merkmal nicht verwendet werden darf. Der Begriff "optional" hat die gleiche Definition wie "darf".
Muß/darf nicht (must)
In dieser Spezifikation soll das Wort "muß" als verbindliches Erfordernis der Implementierung oder für streng konforme XHTML Dokumente interpretiert werden, abhängig vom jeweiligen Kontext. Der Begriff "soll" hat dieselbe Definition wie "muß".
Reserviert (reserved)
Ein Wert oder ein Verhalten ist unspezifiziert, aber es darf nicht in konformen Dokumenten benutzt, oder von konformen Benutzeragenten unterstützt werden.
Sollte (should)
In bezug auf Implementierungen soll das Wort "sollte" als eine Implementierungsempfehlung interpretiert werden, nicht aber als eine Bedingung. In bezug auf Dokumente soll das Wort "sollte" als empfohlene Programmierungspraxis für Dokumente und als Bedingung für streng konforme XHTML Dokumente interpretiert werden.
Unterstützt (supported)
Bestimmte Fähigkeiten in dieser Spezifikation sind optional. Wenn eine Fähigkeit unterstützt wird, verhält sie sich, wie von dieser Spezifikation angegeben.
Unspezifiziert (unspecified)
Wenn ein Wert oder ein Verhalten unspezifiziert ist, definiert die Spezifikation keine Übertragbarkeitserfordernisse für eine Fähigkeit in einer Implementierung, auch wenn sie mit einem Dokument konfrontiert wird, das die Fähigkeit benutzt. Ein Dokument das ein bestimmtes Verhalten erfordert, anstatt jedes Verhalten zu tolerieren wenn diese Fähigkeit benutzt wird, ist kein streng konformes XHTML Dokument.

2.2 Allgemeine Begriffe

Attribut (attribute)
Ein Attribut ist ein Parameter für ein in der DTD deklariertes Element. Der Typ und Wertbereich eines Attributes, einschließlich eines möglichen Standardwertes, werden in der DTD definiert.
DTD
Eine DTD, oder Dokumenttyp-Definition, ist eine Sammlung von XML Deklarationen, welche, als Gesamtheit, die gültige Struktur, Elemente und Attribute definieren, die für den Gebrauch in einem Dokument zur Verfügung stehen, die der DTD entsprechen.
Dokument (document)
Ein Dokument ist ein Strom aus Daten, der, nachdem er mit allen anderen Datenströmen auf die er verweist kombiniert wurde, so strukturiert ist, daß er Informationen in Elementen enthält, die so organisiert sind, wie es in der dazugehörigen DTD definiert wird. Siehe Dokument-Konformität für weitere Informationen.
Element
Ein Element ist eine Dokumentstrukturierungseinheit, die in der DTD deklariert wird. Das Inhaltsmodell des Elementes ist in der DTD definiert, und zusätzliche Semantik darf in der Kurzbeschreibung (prose description) des Elementes definiert werden.
Fähigkeiten (facilities)
Die Funktionalität beinhaltet Elemente, Attribute und die zu diesen Elementen und Attributen gehörige Semantik. Eine Implementierung, die diese Funktionalität unterstützt, soll die notwendigen Fähigkeiten zur Verfügung stellen.
Implementation (implementation)
Eine Implementation ist ein System, das eine Sammlung von Fähigkeiten und Diensten anbietet, die diese Spezifikation unterstützen. Siehe Benutzeragenten-Konformität für weitere Informationen.
Syntaxanalyse (parsing)
Die Syntaxanalyse ist der Vorgang, bei dem ein Dokument gescannt wird und die in dem Dokument enthaltenen Information in den Kontext der Elemente, in denen die Information strukturiert ist, gefiltert wird.
Wiedergabe (rendering)
Die Wiedergabe ist der Vorgang, durch den die Information in einem Dokument präsentiert wird. Diese Präsentation wird in der Form gemacht, die für die Umgebung am besten geeignet ist (z.B. akustisch, visuell, im Druck).
Benutzeragent (user agent)
Ein Benutzeragent ist eine Implementation, die XHTML Dokumente empfängt und verarbeitet. Siehe Benutzeragenten-Konformität für weitere Informationen.
Validierung (Validation)
Die Validierung ist ein Prozess, durch den Dokumente gegen die dazugehörige DTD überprüft werden, um zu gewährleisten, daß die Struktur, die Benutzung der Elemente und die Benutzung der Attribute mit den Definitionen in der DTD übereinstimmt.
Wohlgeformt (well-formed)
Ein Dokument ist wohlgeformt, wenn es nach den in Abschnitt 2.1 der XML 1.0 Empfehlung [XML] Regeln strukturiert ist. Grundsätzlich gibt diese Definition an, daß Elemente, abgegrenzt durch ihre Start- und End-Tags, richtig ineinander verschachtelt sind.

3. Normative Definition von XHTML 1.0

3.1 Dokument-Konformität

Diese Version von XHTML liefert eine Definition für streng konforme XHTML Dokumente, welche auf Tags und Attribute des XHTML Namensraum beschränkt sind. Siehe Abschnitt 3.1.2 für Informationen über die Verwendung von XHTML mit anderen Namensräumen, zum Beispiel um in RDF ausgedrückte Metadaten in XHTML Dokumente einzubinden.

3.1.1 Streng konforme Dokumente

Ein streng konformes XHTML Dokument ist ein Dokument, das nur die in dieser Spezifikation beschriebenen Fähigkeiten verbindlich erfordert. Ein solches Dokument muß allen folgenden Kriterien entsprechen:

  1. Es muß gegen eine der drei DTDs in Anhang A validieren.

  2. Das Wurzelelement des Dokumentes muß <html> sein.

  3. Das Wurzelelement des Dokumentes muß den XHTML Namensraum mit dem xmlns Attribut [XMLNAMES] festlegen. Der Namensraum für XHTML ist definiert als http://www.w3.org/1999/xhtml.

  4. Es muß eine DOCTYPE Deklaration vor dem Wurzelelement im Dokument geben. Der in die DOCTYPE Deklaration einbezogene Public-Identifier muß auf eine der drei DTDs aus Anhang A verweisen mit Hilfe des jeweiligen Formal-Public-Identifiers. Der System-Identifier darf geändert werden um lokale Konventionen widerzuspiegeln.

    <!DOCTYPE html 
         PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
         "DTD/xhtml1-strict.dtd">
    
    <!DOCTYPE html 
         PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
         "DTD/xhtml1-transitional.dtd">
    
    <!DOCTYPE html 
         PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN"
         "DTD/xhtml1-frameset.dtd">
    

Hier ist ein Beispiel für ein minimales XHTML Dokument.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html 
     PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "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://vlib.org/">vlib.org</a>.</p>
  </body>
</html>

Beachte, daß in diesem Beispiel die XML Deklaration enthalten ist. Eine XML Deklaration, wie die oben, ist nicht in allen XML Dokumenten erforderlich. XHTML Dokumentautoren werden stark ermutigt, XML Deklarationen in allen ihren Dokumenten zu verwenden. Eine solche Deklaration ist erforderlich, wenn die Zeichenkodierung des Dokumentes eine andere als die standardmäßigen UTF-8 oder UTF-16 ist.

3.1.2 XHTML mit anderen Namensräumen benutzen

Der XHTML Namensraum darf zusammen mit anderen XML Namensräumen benutzt werden wie durch [XMLNAMES] definiert, obwohl solche Dokumente keine streng konformen Dokumente wie oben definiert sind. Zukünftige Arbeit des W3C wird Möglichkeiten ansprechen, um Konformität für Dokumente zu spezifizieren, die mehrere Namensräume einbeziehen.

Das folgende Beispiel zeigt den Weg über den XHTML 1.0 zusammen mit der MathML Empfehlung benutzt werden kann.

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
  <head>
    <title>A Math Example</title>
  </head>
  <body>
    <p>The following is 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 den Weg über den XHTML 1.0 Markup in andere XML Namensräume integriert werden kann:

<?xml version="1.0" encoding="UTF-8"?>
<!-- initially, the default namespace is "books" -->
<book xmlns='urn:loc.gov:books'
    xmlns:isbn='urn:ISBN:0-395-36341-6' xml:lang="en" lang="en">
  <title>Cheaper by the Dozen</title>
  <isbn:number>1568491379</isbn:number>
  <notes>
    <!-- make HTML the default namespace for a hypertext commentary -->
    <p xmlns='http://www.w3.org/1999/xhtml'>
        This is also available <a href="http://www.w3.org/">online</a>.
    </p>
  </notes>
</book>

3.2 Benutzeragenten-Konformität

Ein konformer Benutzeragent muß allen folgenden Kriterien entsprechen:

  1. Um mit der XML 1.0 Empfehlung vereinbar zu sein, muß der Benutzeragent ein XHTML Dokument auf Wohlgeformtheit syntaktisch analysieren und beurteilen. Wenn der Benutzeragent behauptet, ein validierender Benutzeragent zu sein, muß er auch Dokumente gegen ihre dazugehörigen DTDs validieren, entsprechend [XML].
  2. Wenn der Benutzeragent behauptet, die in dieser Spezifikation definierten, oder von dieser Spezifikation durch normative Verweise geforderten Fähigkeiten zu unterstützen, muß er das auf eine mit der Definition der Fähigkeit vereinbarenden Weise tun.
  3. Wenn ein Benutzeragent ein XHTML als generisches XML Dokument verarbeitet, sollte er nur Attribute des Typs ID (z.B. das id Attribut der meisten XHTML Elemente) als Fragmentbezeichner akzeptieren.
  4. Wenn ein Benutzeragent auf ein Element stößt, das er nicht erkennt, muß er den Inhalt des Elementes wiedergeben.
  5. Wenn ein Benutzeragent auf ein Attribut stößt, das er nicht erkennt, muß er die ganze Attributspezifikation (d.h. das Attribut und seinen Wert) ignorieren.
  6. Wenn ein Benutzeragent auf einen Attributwert stößt, den er nicht erkennt, muß er den Standardwert des Attributes verwenden.
  7. Wenn er auf eine Entity-Referenz stößt (außer einer der vordefinierten Entities) für die der Benutzeragent keine Deklaration verarbeitet hat (was passieren kann, wenn sich die Deklaration in der externen Untermenge befindet, die der Benutzeragent nicht eingelesen hat), sollte die Entity-Referenz als die Zeichen wiedergegeben werden (beginnend mit dem et-Zeichen (&) und endend mit dem Semikolon), die die Entity-Referenz ausmachen.
  8. Wenn Inhalt wiedergegeben wird, sollten Benutzeragenten, die auf Zeichen oder Entity-Referenzen stoßen, die zwar erkannt werden aber nicht wiedergegeben werden können, das Dokument auf eine Weise darstellen, die es für den Benutzer offensichtlich macht, daß eine normale Wiedergabe nicht stattgefunden hat.
  9. Die folgenden Zeichen werden in [XML] als Leerraum-Zeichen definiert:

    Der XML Prozessor normalisiert Zeilenendsequenzen verschiedener Systeme in ein einzelnes Zeilenvorschub-Zeichen, das der Anwendung übergeben wird. Der XHTML Benutzeragent muß zusätzlich die folgenden Zeichen als Leerraum behandeln:

    In Elementen, wo das 'xml:space' Attribut auf 'preserve' gesetzt ist, muß der Benutzeragent alle Leerräume erhalten (mit Ausnahme von führenden und abschließenden Leerräumen die entfernt werden sollten). Ansonsten werden Leerräume entsprechend den folgenden Regeln behandelt:

    Leerräume in Attributwerten werden entsprechend [XML] verarbeitet.

4. Unterschiede zu HTML 4

Aufgrund der Tatsache, daß XHTML eine XML Anwendung ist, müssen bestimmte Praktiken, die im SGML basierendem HTML 4 [HTML] zulässig waren, geändert werden.

4.1 Dokumente müssen wohlgeformt sein

Wohlgeformtheit ist ein neues Konzept, das durch [XML] eingeführt wurde. Im wesentlichen bedeutet dies, daß alle Elemente entweder abschließende Tags haben müssen, oder in einer speziellen Form geschrieben werden müssen (wie unten beschrieben) und daß alle Elemente korrekt verschachtelt werden müssen.

Obwohl es in SGML illegal ist, zu überlappen, wurde es häufig in vorhandenen Browsern toleriert.

RICHTIG: verschachtelte Elemente

<p>here is an emphasized <em>paragraph</em>.</p>

FALSCH: Überlappende Elemente

<p>here is an emphasized <em>paragraph.</p></em>

4.2 Element- und Attributnamen müssen klein geschrieben werden

XHTML Dokumente müssen Kleinschreibung für alle HTML Element- und Attributnamen verwenden. Dieser Unterschied ist notwendig, da XML Groß-/Kleinschreibungsempfindlich ist, z.B. sind <li> und <LI> unterschiedliche Tags.

4.3 Für nicht-leere Elemente sind End-Tags erforderlich

In SGML basierendem HTML 4 wurde bestimmten Elementen erlaubt, den End-Tag auszulassen; mit dem folgendem Element wurde dessen Schließung impliziert. Diese Auslassung ist nicht erlaubt im XML basierendem XHTML. Alle Elemente außer denen, die in der DTD als EMPTY deklariert wurden, müssen einen End-Tag haben.

RICHTIG: abgeschlossene Elemente

<p>here is a paragraph.</p><p>here is another paragraph.</p>

FALSCH: nicht abgeschlossene Elemente

<p>here is a paragraph.<p>here is another paragraph.

4.4 Attributwerte müssen immer in Anführungszeichen eingeschlossen werden

Alle Attributwerte müssen in Anführungszeichen eingeschlossen werden, sogar jene, die scheinbar numerisch sind.

RICHTIG: In Anführungszeichen gesetzte Attributwerte

<table rows="3">

FALSCH: nicht in Anführungszeichen gesetzte Attributwerte

<table rows=3>

4.5 Attributminimierung

XML unterstützt Attributminimierung nicht. Attribut-Wert Paare müssen ganz ausgeschrieben werden. Attributnamen wie compact und checked können nicht in Elementen auftauchen, ohne daß ihr Wert angegeben wird.

RICHTIG: nicht-minimierte Attribute

<dl compact="compact">

FALSCH: minimierte Attribute

<dl compact>

4.6 Leere Elemente

Leere Elemente müssen entweder einen End-Tag haben oder der Start-Tag muß mit /> enden. Zum Beispiel <br/> oder <hr></hr>. Siehe HTML Kompatibilitätsrichtlinien für Informationen über Möglichkeiten Abwärtskompatibilität zu HTML 4 Benutzeragenten sicherzustellen.

RICHTIG: abgeschlossene leere Elemente

<br/><hr/>

FALSCH: nicht-abgeschlossene leere Elemente

<br><hr>

4.7 Leerraum-Behandlung in Attributwerten

In Attributwerten werden Benutzeragenten führende und abschließende Leerräume von Attributwerten entfernen und aus Folgen aus einer oder mehrerer Leerraum-Zeichen (inklusive Zeilenumbrüchen) ein einzelnes Zwischenwort-Leerzeichen (ein ASCII Leerzeichen für westliche Skripte) machen. Siehe Abschnitt 3.3.3 von [XML].

4.8 Script- und Style-Elemente

In XHTML sind die Script- und Style-Elemente als Elemente mit #PCDATA Inhalt deklariert. Folglich werden < und & als Anfang von Markup behandelt und Entities wie &lt; und &amp; vom XML Prozessor als Entity-Referenzen für < respektive & erkannt. Man kann die Expansion dieser Entities vermeiden, indem man den Inhalt des Script- oder Style-Elementes in einen als CDATA markierten Abschnitt verpackt.

<script>
 <![CDATA[
 ... ungeschützter (unescaped) Scriptinhalt ...
 ]]>
 </script>

CDATA Abschnitte werden vom XML Prozessor erkannt und erscheinen als Knoten im Dokumentobjektmodell, vgl. Abschnitt 1.3 der DOM Level 1 Empfehlung [DOM].

Eine Alternative ist es, externe Skript- und Style-Dokumente zu verwenden.

4.9 SGML Ausschlüsse

SGML gibt dem Verfasser einer DTD die Möglichkeit bestimmte Elemente davon auszuschließen, in einem Element enthalten zu sein. Solche Verbote (Ausschlüsse genannt) sind in XML nicht möglich.

Zum Beispiel verbietet die HTML 4 Strict DTD die Verschachtelung eines 'a' Elementes in einem anderen 'a' Element jeder Nachkommenstiefe. Es ist nicht möglich solche Verbote in XML auszusprechen. Obwohl diese Verbote nicht in der DTD definiert werden können, sollten bestimmte Elemente nicht verschachtelt sein. Eine Zusammenfassung solcher Elemente und der Elemente, die in ihnen nicht verschachtelt sein sollten, findet sich im normativen Anhang B.

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

HTML 4 definiert das name Attribut für die Elemente a, applet, form, frame, iframe, img und map. HTML 4 führte auch das id Attribut ein. Beide Attribute wurden entworfen, um als Fragmentbezeichner benutzt zu werden.

In XML sind Fragmentbezeichner vom Typ ID und es kann nur ein einzelnes Attribut des Typs ID pro Element geben. Deshalb wird das id Attribut in XHTML 1.0 als vom Typ ID definiert. Um zu gewährleisten, daß XHTML 1.0 Dokumente wohlstrukturierte XML Dokumente sind, MÜSSEN XHTML 1.0 Dokumente das id Attribut verwenden, wenn sie Fragmentsbezeichner definieren, auch für Elemente die historischer Weise auch ein name Attribut gehabt haben. Vgl. die HTML Kompatibilitätsrichtlinien für Informationen um sicherzustellen, daß solche Anker abwärtskompatibel sind, wenn XHTML Dokumente als Medientyp text/html geliefert werden.

Beachte das in XHTML 1.0 das name Attribut dieser Elemente formal mißbilligt (deprecated) wurde und in anschließenden Versionen aus XHTML entfernt werden wird.

5. Kompatibilitätsangelegenheiten

Obwohl es kein Erfordernis für XHTML 1.0 Dokumente gibt, kompatibel mit vorhandenen Benutzeragenten zu sein, ist es in Praxis leicht, dies zu erreichen. Richtlinien für das Erstellen kompatibler Dokumente können in Anhang C gefunden werden.

5.1 Internet Medientyp

Zum Zeitpunkt der Veröffentlichung dieser Empfehlung muß die allgemein empfohlene MIME Kennzeichnung für XML basierte Anwendungen erst noch beschlossen werden.

Jedoch dürfen XHTML Dokumente, die den Richtlinien aus Anhang C, "HTML Kompatibilitätsrichtlinien", folgen mit dem Internet Medientyp "text/html" gekennzeichnet werden, da sie zu den meisten HTML Browsern kompatibel sind. Dieses Dokument macht keine Empfehlung über MIME Kennzeichnung von anderen XHTML Dokumenten.

6. Zukünftige Entwicklungen

XHTML 1.0 liefert die Basis für eine Familie von Dokumenttypen die XHTML erweitern und unterteilen werden, um eine große Breite neuer Geräte und Anwendungen zu unterstützen, indem Module definiert werden und einen Mechanismus um diese Module zu kombinieren zu spezifizieren.

6.1 HTML Modularisieren

Sowie sich die Verwendung von XHTML von den traditionellen Desktop-Benutzeragenten zu anderen Plattformen verlagert, ist es klar, daß nicht alle der XHTML Elemente auf allen Plattformen benötigt werden. Zum Beispiel ein Handheld-Gerät oder ein Mobiltelefon kann nur eine Untermenge der XHTML Elemente unterstützen.

Der Prozeß der Modularisierung spaltet XHTML in eine Serie kleinerer Elementsätze auf. Diese Elemente können dann wieder kombiniert werden, um den Bedarf verschiedener Interessensgruppen zu decken.

Diese Module werden in einem späteren W3C Dokument definiert.

6.2 Untermengen und Erweiterbarkeit

Die Modularisierung bringt mehrere Vorteile mit sich:

6.3 Dokumentprofile

Ein Dokumentprofil spezifiziert Syntax und Semantik eines Dokumentsatzes. Konformität zu einem Dokumentprofil liefert eine Basis für Interoperabilitätsgarantien. Das Dokumentprofil spezifiziert die notwendigen Fähigkeiten Dokumente dieses Typs zu verarbeiten, z.B. welche Bildformate benutzt werden können, Ebenen des Scriptings, Stylesheet-Unterstützung und so weiter.

Für Produktdesigner erlaubt dies, verschiedenen Gruppen ihr eigenes Standardprofil zu definieren.

Für Autoren wird dies der Notwendigkeit vorbeugen, mehrere verschiedene Versionen von Dokumenten für verschiedene Clients zu schreiben.

Für bestimmte Gruppen wie Chemiker, Ärzte oder Mathematiker erlaubt dies, ein spezielles Profil zu erstellen, mit Hilfe von Standard HTML Elementen zuzüglich einer Gruppe auf die Bedürfnisse der Spezialisten abgestimmter Elemente.

Anhang A. DTDs

Dieser Anhang ist normativ.

Diese DTDs und Entitätssätze formen einen normativen Teil dieser Spezifikation. Der vollständige Satz der DTD Dateien zusammen mit einer XML Deklaration und dem SGML Open Catalog ist in der zip Datei für diese Spezifikation enthalten.

A.1 Dokumenttyp-Definitionen

Diese DTDs entsprechen in etwa den HTML 4 DTDs. Es ist wahrscheinlich, daß, wenn die DTDs modularisiert werden, eine Methode zur DTD Konstruktion verwandt wird, die eher HTML 4 entspricht.

A.2 Entity Sätze

Die XHTML Entity Sätze sind dieselben wie für HTML 4, wurden aber verändert um gültige XML 1.0 Entity Deklarationen zu sein. Beachte, daß das Entity für das Euro Währungssymbol (&euro; oder &#8364; oder &#x20AC;) als Teil der Sonderzeichen definiert wird.

Anhang B. Elementverbote

Dieser Anhang ist normativ.

Die folgenden Elemente haben Beschränkungen, welche Elemente sie enthalten können (vgl. Abschnitt 4.9). Dieses Verbot gilt für alle Tiefen der Verschachtelung, d.h. es enthält alle Nachkommenelemente.

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

Anhang C. HTML Kompatibilitätsrichtlinien

Dieser Anhang ist nicht normativ.

Dieser Anhang faßt Entwurfsrichtlinien für Autoren zusammen, die möchten, daß ihre XHTML Dokumente von vorhandenen HTML Benutzeragenten wiedergegeben werden.

C.1 Verarbeitungsanweisungen

Beachte, daß Verarbeitungsanweisungen von einigen Benutzeragenten wiedergegeben werden. Beachte jedoch auch, daß, wenn die XML Deklaration nicht in ein Dokument einbezogen wird, das Dokument nur die Standard-Zeichenkodierung UTF-8 oder UTF-16 verwenden kann.

C.2 Leere Elemente

Füge ein Leerzeichen vor dem abschliessenden / und > leerer Elemente ein, z.B. <br />, <hr /> und <img src="karen.jpg" alt="Karen" />. Ebenfalls, benutze die minimierten Tag-Syntax für leere Elemente, z.B. <br /> da die von XML erlaubte alternative Syntax <br></br> zu unsicheren Ergebnissen in vielen vorhandenen Benutzeragenten führt.

C.3 Element-Minimierung und Inhalt leerer Elemente

Ist ein Exemplar eines Elementes gegeben, dessen Inhaltsmodell nicht EMPTY (zum Beispiel ein leerer Titel oder Absatz) ist, verwende die reduzierte Form nicht (z.B. verwende <p> </p> und nicht <p />).

C.4 Eingebettete Stylesheets und Scripts

Benutze externe Stylesheets, wenn Dein Stylesheet < oder & oder ]]> oder -- benutzt. Benutze externe Scripts, wenn dein Script < oder & oder ]]> oder -- benutzt. Beachte, daß XML Parser stillschweigend den Inhalt von Kommentaren entfernen dürfen. Deshalb ist zu erwarten, daß die historische Praxis, Scripts und Stylesheets innerhalb von Kommentaren zu "verstecken", um die Dokumente abwärtskompatibel zu machen, nicht wie erwartet in XML-basierenden Implementationen funktioniert.

C.5 Zeilenumbrüche in Attributwerten

Vermeide Zeilenumbrüche und mehrfache Leerräume in Attributwerten. Diese werden von Benutzeragenten uneinheitlich behandelt.

C.6 Isindex

Füge nicht mehr als ein isindex Element in den Dokumentkopf ein. Das isindex Element wird zugunsten des input Elementes nicht mehr verwendet.

C.7 Die lang und xml:lang Attribute

Benutze sowohl das lang als auch das xml:lang Attribut zum Festlegen der Sprache eines Elementes. Der Wert des xml:lang Attributes besitzt Vorrang.

C.8 Fragmentbezeichner

In XML beziehen sich URIs [RFC2396], die mit einem Fragmentbezeichner in der Form "#foo" enden, nicht auf Elemente mit dem Attribut name="foo", sondern beziehen sich auf Elemente mit einem Attribut, das als Typ ID definiert wurde, z.B. das id Attribut in HTML 4. Viele vorhandene Benutzeragenten unterstützen die Benutzung von Attributen des Typs ID auf diese Weise nicht, daher darf für diese beiden Attribute identische Werte angegeben werden um einen größtmöglichen Grad an Kompatibilität zu gewährleisten (z.B. <a id="foo" name="foo">...</a>).

Da der Satz gültiger Werte für Attribute des Typs ID viel kleiner ist, als für die des Typs CDATA, wurde der Typ des name Attributes zu NMTOKEN geändert. Dieses Attribut ist so eingeschränkt, daß es nur die gleichen Werte wie der Typ ID oder wie die Name Produktion in XML 1.0 Abschnitt 2.5, Produktion 5. Leider kann diese Vorgabe nicht in den XHTML 1.0 DTDs ausgedrückt werden. Wegen dieser Änderung muß Sorge getragen werden, wenn vorhandene HTML Dokumente konvertiert werden. Die Werte diese Attribute müssen innerhalb des Dokumentes eindeutig und gültig sein und jede Referenz zu diesen Fragmentbezeichnern (sowohl interne wie externe) muß aktualisiert werden, sollte sich der Wert während der Konvertierung geändert haben.

Schließlich beachte, daß XHTML 1.0 das name Attribut der a, applet, form, frame, iframe, img und map Elemente mißbilligt (deprecated) hat und es aus XHTML in anschließenden Versionen entfernt wird.

C.9 Zeichenkodierung

Um eine Zeichenkodierung im Dokument anzugeben, benutze sowohl die Kodierungsattribut-Spezifikation der XML Deklaration (z.B. <?xml version="1.0" encoding="EUC-JP"?>) als auch eine meta http-equiv Angabe (z.B. <meta http-equiv="Content-Type" content='text/html; charset="EUC-JP"' />). Der Wert des encoding Attributes der XML Verarbeitungsanweisung besitzt Vorrang.

C.10 Boolesche Attribute

Einige HTML Benutzeragenten sind außerstande, boolesche Attribute zu interpretieren, wenn diese in ihrer vollen (nicht-minimierten) Form erscheinen, wie von XML 1.0 gefordert. Beachte, daß dieses Problem keine Benutzeragenten betrifft, die HTML 4 befolgen. Die folgenden Attribute sind betroffen: compact, nowrap, ismap, declare, noshade, checked, disabled, readonly, multiple, selected, noresize, defer.

C.11 Das Dokumentobjektmodell und XHTML

Die Document Object Model Level 1 Empfehlung [DOM] definiert Dokumentobjektmodell-Schnittstellen für XML und HTML 4. Das HTML 4 Dokumentobjektmodell legt fest, daß HTML Element- und Attributnamen in Großschreibung zurückgeliefert werden. Das XML Dokumentobjektmodell legt fest, daß Element- und Attributnamen in der Schreibweise zurückgeliefert werden, in der sie angegeben werden. In XHTML 1.0 sind Element- und Attributnamen in Kleinschreibung festgelegt. Dieser offensichtliche Unterschied kann auf zwei Weisen angesprochen werden:

  1. Anwendungen, die auf XHTML Dokumente, die als Internet Medientyp text/html angeboten werden, über das DOM zugreifen können das HTML DOM benutzen und sich darauf verlassen, daß Element- und Attributnamen in Großschreibung von diesen Schnittstellen zurückgeliefert werden.
  2. Anwendungen, die auf XHTML Dokumente, die als Internet Medientyp text/xml oder application/xml angeboten werden, zugreifen, können auch das XML DOM benutzen. Elemente und Attribute werden in Kleinschreibung zurückgeliefert. Auch können einige XHTML Elemente nicht in der Objektbaumstruktur erscheinen, weil sie im Inhaltsmodell optional sind (z.B. das tbody Element innerhalb von table). Dies passiert, weil in HTML 4 einige Elemente minimiert werden können, so daß ihre Start- und End-Tags beide ausgelassen werden können (ein SGML Merkmal). Dies ist nicht möglich in XML. Anstatt von Dokumentautoren zu verlangen, unwesentliche Elemente einzufügen, hat XHTML diese Elemente optional gemacht. Anwendungen müssen sich dementsprechend anpassen.

C.12 Et-Zeichen in Attributwerten verwenden

Wenn ein Attributwert ein Et-Zeichen enthält, muß es als Entity-Referenz (z.B. "&amp;") ausgedrückt werden. Als Beispiel, wenn ein href Attribut eines a Elementes auf ein CGI Script verweist, daß Parameter annimmt, muß es als http://my.site.dom/cgi-bin/myscript.pl?class=guest&amp;name=user ausgedrückt werden statt 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 welche auf den Parse-Baum von HTML oder XML Dokumenten angewandt werden. Unterschiede im Parsing werden unterschiedliche visuelle oder akustische Ergebnisse erzeugen, abhängig von den benutzten Selektoren. Die folgenden Hinweise werden diesen Effekt für Dokumente die ohne Veränderung als beide Medientypen angeboten werden verringern:

  1. CSS Stylesheets für XHTML sollten kleingeschriebene Element- und Attributnamen verwenden.
  2. In Tabellen wird von dem Parser eines HTML Benutzeragenten nicht aber vom Parser eines XML Benutzeragenten das tbody Element automatisch gefolgert. Daher solltest Du immer explizit ein tbody Element hinzufügen, wenn darauf in einem CSS Selektor verwiesen wird.
  3. Innerhalb des XHTML Namensraumes wird es erwartet, daß Benutzeragenten das "ID" Attribut als Attribut von Typ ID anerkennen. Deshalb sollten Stylesheets in der Lage sein, den Kurzschrift "#" Selektor weiterhin zu benutzen, auch wenn der Benutzeragent die DTD nicht liest.
  4. Innerhalb des XHTML Namensraumes wird von Benutzeragenten erwartet, das "class" Attribut zu erkennen. Deshalb sollten Stylesheets in der Lage sein, weiterhin den Kurzschrift "." Selektor Syntax zu benutzen.
  5. CSS definiert unterschiedliche Konformitätsregeln für HTML und XML Dokumente; beachte, daß die HTML Regeln für XHTML Dokumente gelten, die als HTML geliefert werden und die XML Regeln für XHTML Regeln gelten die als XML geliefert werden.

Anhang D. Danksagungen

Dieser Anhang ist nicht normativ.

Diese Spezifikation wurde mit der Beteiligung der Mitglieder der W3C HTML Arbeitsgruppe geschrieben:

Steven Pemberton, CWI (Vorsitzender der HTML Arbeitsgruppe)
Murray Altheim, Sun Microsystems
Daniel Austin, AskJeeves (CNET: The Computer Network im 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 besuchender Ingenieur im September 1999)
Shane McCarron, Applied Testing and Technology (The Open Group im August 1999)
Ann Navarro, HTML Writers Guild
Zach Nies, Quark
Dave Raggett, W3C/HP (W3C Leitung für HTML)
Patrick Schmitz, Microsoft
Sebastian Schnitzenbaumer, Stack Overflow
Peter Stark, Phone.com
Chris Wilson, Microsoft
Ted Wugofski, Gateway 2000
Dan Zigmond, WebTV Networks

Anhang E. Referenzen

Dieser Anhang ist nicht normativ.

[CSS2]
"Cascading Style Sheets, level 2 (CSS2) Specification", B. Bos, H. W. Lie, C. Lilley, I. Jacobs, 12. Mai 1998.
Neuste Version verfügbar unter: http://www.w3.org/TR/REC-CSS2
[DOM]
"Document Object Model (DOM) Level 1 Specification", Lauren Wood et al., 1. Oktober 1998.
Neuste Version verfügbar unter: http://www.w3.org/TR/REC-DOM-Level-1
[HTML]
"HTML 4.01 Specification", D. Raggett, A. Le Hors, I. Jacobs, 24. Dezember 1999.
Neuste Version verfügbar unter: http://www.w3.org/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.
[RFC2046]
"RFC2046: Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", N. Freed and N. Borenstein, November 1996.
Verfügbar unter http://www.ietf.org/rfc/rfc2046.txt. Beachte das dieser RFC RFC1521, RFC1522 und RFC1590 veraltet.
[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
[XML]
"Extensible Markup Language (XML) 1.0 Specification", T. Bray, J. Paoli, C. M. Sperberg-McQueen, 10. Februar 1998.
Neuste Version verfügbar unter: http://www.w3.org/TR/REC-xml
[XMLNAMES]
"Namespaces in XML", T. Bray, D. Hollander, A. Layman, 14. Januar 1999.
XML Namensräume bieten eine einfache Methode Namen in XML Dokumenten zu qualifizieren indem man sie mit durch ein URI mit Namensräumen verbindet.
Neuste Version verfügbar unter: http://www.w3.org/TR/REC-xml-names

Level Triple-A conformance icon, W3C-WAI Web Content Accessibility Guidelines 1.0