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 fr HTML 4 definiert. Diese Semantik schafft die Grundlage fr die zuknftige Erweiterbarkeit von XHTML. Kompatibilitt mit vorhandenen HTML Benutzeragenten ist mglich, indem ein kleiner Satz Richtlinien befolgt wird.

Status dieses Dokumentes

Dieser Abschnitt beschreibt den Status dieses Dokumentes zum Zeitpunkt seiner Verffentlichung. Es kann sein, da andere Dokumente dieses Dokument ablsen. Der letzte Status dieser Dokumentserie wird beim W3C verwaltet.

Dieses Dokument ist von Mitgliedern des W3C und anderen interessierten Parteien geprft und vom Direktor als W3C Empfehlung untersttzt worden. Es ist ein stabiles Dokument und kann als Referenzmaterial verwendet oder als normative Referenz von einem anderen Dokument angefhrt werden. Die Aufgabe des W3Cs bei der Erstellung der Empfehlung ist es, Aufmerksamkeit auf diese Spezifikation zu lenken und ihre weite Verbreitung zu frdern. Dies verbessert die Funktionalitt und die Interoperabilitt des Webs.

Dieses Dokument wurde als Teil der W3C HTML Aktivitt erstellt. Die Ziele der HTML Arbeitsgruppe (nur fr Mitglieder) werden in der Charta der HTML Arbeitsgruppe (nur fr 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 [email protected] (Archiv) statt.

Bitte melde Fehler in diesem Dokument bei [email protected].

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

Inhalt

1. Was ist XHTML?

XHTML ist eine Familie bestehender und zuknftiger 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 Zuknftige 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 fr 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:

• XHTML Dokumente sind XML konform. Als solche knnen sie ohne weiteres mit Standard-XML-Werkzeugen betrachtet, bearbeitet und validiert werden.
• XHTML Dokumente knnen so geschrieben werden, da sie genauso gut oder besser in bestehenden HTML 4 Benutzeragenten funktionieren wie in neuen, XHTML 1.0 konformen Benutzeragenten.
• XHTML Dokumente knnen Anwendungen nutzen (z.B. Skripte oder Applets) die entweder vom HTML Dokumentobjektmodell oder vom XML Dokumentobjektmodell [DOM] abhngig sind.
• Sowie sich die XHTML Familie weiterentwickelt, werden XHTML 1.0 konforme Dokumente eher zusammen mit und innerhalb verschiedener XHTML Umgebungen arbeiten knnen.

Die XHTML Familie ist der nchste Schritt in der Weiterentwicklung des Internets. Indem Inhaltsentwickler heute auf XHTML umsteigen, knnen sie in die XML-Welt mit allen dazugehrigen Vorteilen einsteigen, whrend sie sich auf die Abwrts- wie auch die zuknftige Kompatibilitt ihrer Inhalte verlassen knnen.

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-Verffentlichungssprache des World Wide Web angesehen.

SGML ist eine Sprache zur Beschreibung von Markup Sprachen, insbesondere solcher, die im elektronischen Dokumentaustausch, Dokumentmanagement und der Dokumentverffentlichung benutzt werden. HTML ist ein Beispiel fr eine in SGML definierte Sprache.

SGML gibt es seit Mitte der 80er Jahre und ist ziemlich stabil geblieben. Ein groer Teil dieser Stabilitt kommt von der Tatsache, da die Sprache sowohl merkmalsreich wie auch flexibel ist. Jedoch hat diese Flexibilitt auch einen Preis. Dieser Preis ist ein Ma an Komplexitt, die ihre Annahme in einer Vielzahl von Umgebungen gehemmt hat, einschlielich des World Wide Web.

HTML, wie ursprnglich erdacht, sollte eine Sprache fr den Austausch wissenschaftlicher und anderer technischer Dokumente sein, die sich auch fr den Gebrauch durch Nichtdokumentspezialisten eignet. HTML nahm sich dem Problem der Komplexitt von SGML an, indem sie einen kleinen Satz struktureller und semantischer Tags festlegt, geeignet um relativ einfache Dokumente zu erstellen. Zustzlich zum Vereinfachen der Dokumentstruktur fgte HTML Untersttzung fr Hypertext hinzu. Multimediafhigkeiten wurden spter hinzugefgt.

In einem bemerkenswert kurzen Zeitraum wurde HTML sehr populr und wuchs schnell ber ihre ursprngliche Bestimmung hinaus. Seit der Einfhrung von HTML hat es einen schnellen Prozess, neue Elemente zum Gebrauch innerhalb von HTML (als Norm) und zur Anpassung von HTML an vertikale, uerst spezialisierte Mrkte zu erfinden, gegeben. Diese Unmenge neuer Elemente hat zu Kompatibilittsproblemen fr Dokumente zwischen verschiedenen Plattformen gefhrt.

Da sich die Heterogenitt 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 eingeschrnkt ist.

1.2 Was ist XML?

XML^™ ist die Abkrzung fr Extensible Markup Language und ein Akronym fr Extensible Markup Language [XML].

XML wurde als ein Mittel erdacht, die Strke und Flexibilitt von SGML ohne ihre Komplexitt zu erhalten.

Whrend XML diese ntzlichen 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:

• Dokumententwickler und Benutzeragentenentwickler entdecken stndig neue Mglichkeiten, ihre Ideen durch neues Markup auszudrcken. In XML ist es relativ leicht, neue Elemente oder zustzliche Attribute einzufhren. Die XHTML Familie wurde entworfen, um diese Erweiterungen durch XHTML Module und Techniken in Einklang zu bringen und um neue XHTML-konforme Module zu entwickeln (beschrieben in der bevorstehenden XHTML Modularisierung Spezifikation). Diese Module werden die Kombination vorhandener und neuer Merkmalsstze erlauben, wenn Inhalte entwickelt werden und wenn neue Benutzeragenten entworfen werden.
• Alternative Mglichkeiten, auf das Internet zuzugreifen, werden stndig eingefhrt. Einige Schtzungen zeigen an, da bis zum Jahr 2002 75% der Internetdokumentbetrachtungen auf diesen alternativen Plattformen ausgefhrt werden. Die XHTML Familie wurde im Gedanken an eine generelle Benutzeragenten-Interoperabilitt entworfen. Durch ein neues Benutzeragenten- und Dokument-Profilierungssystem werden Server, Proxies und Benutzeragenten in der Lage sein, bestmgliche Inhaltstransformationen durchzufhren. Letztlich wird es mglich sein, XHTML-konformen Inhalt zu entwickeln, der durch jeden XHTML-konformen Benutzeragenten verwendbar ist.

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 fr 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-Konformitt 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 fr streng konforme XHTML Dokumente interpretiert werden, abhngig 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 untersttzt 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 fr Dokumente und als Bedingung fr streng konforme XHTML Dokumente interpretiert werden.

Untersttzt (supported)

Bestimmte Fhigkeiten in dieser Spezifikation sind optional. Wenn eine Fhigkeit untersttzt wird, verhlt sie sich, wie von dieser Spezifikation angegeben.

Unspezifiziert (unspecified)

Wenn ein Wert oder ein Verhalten unspezifiziert ist, definiert die Spezifikation keine bertragbarkeitserfordernisse fr eine Fhigkeit in einer Implementierung, auch wenn sie mit einem Dokument konfrontiert wird, das die Fhigkeit benutzt. Ein Dokument das ein bestimmtes Verhalten erfordert, anstatt jedes Verhalten zu tolerieren wenn diese Fhigkeit benutzt wird, ist kein streng konformes XHTML Dokument.

2.2 Allgemeine Begriffe

Attribut (attribute)

Ein Attribut ist ein Parameter fr ein in der DTD deklariertes Element. Der Typ und Wertbereich eines Attributes, einschlielich eines mglichen Standardwertes, werden in der DTD definiert.

DTD

Eine DTD, oder Dokumenttyp-Definition, ist eine Sammlung von XML Deklarationen, welche, als Gesamtheit, die gltige Struktur, Elemente und Attribute definieren, die fr den Gebrauch in einem Dokument zur Verfgung stehen, die der DTD entsprechen.

Dokument (document)

Ein Dokument ist ein Strom aus Daten, der, nachdem er mit allen anderen Datenstrmen auf die er verweist kombiniert wurde, so strukturiert ist, da er Informationen in Elementen enthlt, die so organisiert sind, wie es in der dazugehrigen DTD definiert wird. Siehe Dokument-Konformitt fr weitere Informationen.

Element

Ein Element ist eine Dokumentstrukturierungseinheit, die in der DTD deklariert wird. Das Inhaltsmodell des Elementes ist in der DTD definiert, und zustzliche Semantik darf in der Kurzbeschreibung (prose description) des Elementes definiert werden.

Fhigkeiten (facilities)

Die Funktionalitt beinhaltet Elemente, Attribute und die zu diesen Elementen und Attributen gehrige Semantik. Eine Implementierung, die diese Funktionalitt untersttzt, soll die notwendigen Fhigkeiten zur Verfgung stellen.

Implementation (implementation)

Eine Implementation ist ein System, das eine Sammlung von Fhigkeiten und Diensten anbietet, die diese Spezifikation untersttzen. Siehe Benutzeragenten-Konformitt fr 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 prsentiert wird. Diese Prsentation wird in der Form gemacht, die fr die Umgebung am besten geeignet ist (z.B. akustisch, visuell, im Druck).

Benutzeragent (user agent)

Ein Benutzeragent ist eine Implementation, die XHTML Dokumente empfngt und verarbeitet. Siehe Benutzeragenten-Konformitt fr weitere Informationen.

Validierung (Validation)

Die Validierung ist ein Prozess, durch den Dokumente gegen die dazugehrige DTD berprft werden, um zu gewhrleisten, 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. Grundstzlich 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-Konformitt

Diese Version von XHTML liefert eine Definition fr streng konforme XHTML Dokumente, welche auf Tags und Attribute des XHTML Namensraum beschrnkt sind. Siehe Abschnitt 3.1.2 fr Informationen ber die Verwendung von XHTML mit anderen Namensrumen, zum Beispiel um in RDF ausgedrckte 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 Fhigkeiten 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 fr 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 gendert 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 fr 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 standardmigen UTF-8 oder UTF-16 ist.

3.1.2 XHTML mit anderen Namensrumen benutzen

Der XHTML Namensraum darf zusammen mit anderen XML Namensrumen benutzt werden wie durch [XMLNAMES] definiert, obwohl solche Dokumente keine streng konformen Dokumente wie oben definiert sind. Zuknftige Arbeit des W3C wird Mglichkeiten ansprechen, um Konformitt fr Dokumente zu spezifizieren, die mehrere Namensrume 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 Namensrume 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-Konformitt

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 dazugehrigen DTDs validieren, entsprechend [XML].
2. Wenn der Benutzeragent behauptet, die in dieser Spezifikation definierten, oder von dieser Spezifikation durch normative Verweise geforderten Fhigkeiten zu untersttzen, mu er das auf eine mit der Definition der Fhigkeit 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 stt, das er nicht erkennt, mu er den Inhalt des Elementes wiedergeben.
5. Wenn ein Benutzeragent auf ein Attribut stt, das er nicht erkennt, mu er die ganze Attributspezifikation (d.h. das Attribut und seinen Wert) ignorieren.
6. Wenn ein Benutzeragent auf einen Attributwert stt, den er nicht erkennt, mu er den Standardwert des Attributes verwenden.
7. Wenn er auf eine Entity-Referenz stt (auer einer der vordefinierten Entities) fr 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 stoen, die zwar erkannt werden aber nicht wiedergegeben werden knnen, das Dokument auf eine Weise darstellen, die es fr den Benutzer offensichtlich macht, da eine normale Wiedergabe nicht stattgefunden hat.
9. Die folgenden Zeichen werden in [XML] als Leerraum-Zeichen definiert:
   • Leerzeichen ( )
   • Tabulator (	)
   • Wagenrcklauf (
)
   • Zeilenvorschub (
)

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

   • Seitenvorschub ()
   • Leerzeichen mit der Breite Null (​)

   In Elementen, wo das 'xml:space' Attribut auf 'preserve' gesetzt ist, mu der Benutzeragent alle Leerrume erhalten (mit Ausnahme von fhrenden und abschlieenden Leerrumen die entfernt werden sollten). Ansonsten werden Leerrume entsprechend den folgenden Regeln behandelt:

   • Alle Leerrume, die Block-Elemente umgeben, sollten entfernt werden.
   • Kommentare werden ganz entfernt und beeinflussen die Behandlung von Leerrumen nicht. Ein Leerraum-Zeichen auf jeder Seite des Kommentars wird wie zwei Leerzeichen behandelt.
   • Fhrende und abschlieende Leerrume innerhalb eines Block Elementes mssen entfernt werden.
   • Zeilenvorschub-Zeichen innerhalb eines Block Elementes mssen in ein Leerzeichen konvertiert werden (es sei denn, das 'xml:space' Attribut ist auf 'preserve' gesetzt).
   • Eine Sequenz aus Leerraum-Zeichen mu auf ein einzelnes Leerzeichen reduziert werden (es sei denn, das 'xml:space' Attribut ist auf 'preserve' gesetzt).
   • In Hinblick auf die Darstellung sollte der Benutzeragent den Inhalt auf eine Weise wiedergeben, die fr die Sprache, in der der Inhalt geschrieben wurde, geeignet ist. In Sprachen deren primres Skript lateinisch ist, wird das ASCII Leerzeichen normalerweise dazu benutzt, sowohl grammatikalische Wortgrenzen als auch typographischen Leerraum zu kodieren; in Sprachen, deren Skript mit Nagari (z.B. Sanskrit, Thai, usw.) verwandt ist, knnen grammatikalische Grenzen mit dem 'Leerzeichen' der Breite Null kodiert werden, werden aber normalerweise nicht als typographischer Leerraum in der Wiedergabe dargestellt; Sprachen die arabische Skripte benutzten, knnen typographischen Leerraum mit einem Leerzeichen kodieren, knnen aber auch Leerzeichen der Breite Null benutzen, um 'interne' grammatische Grenzen abzugrenzen (was wie Worte in Arabisch fr ein englisches Auge aussieht, z.B. 'kitAbuhum' = 'kitAbu-hum' = 'Buch ihnen' == 'ihr Buch'); Sprachen in der chinesischen Skripttradition kodieren normalerweise weder solche Grenzen noch benutzten sie typographischen Leerraum auf diese Weise.

   Leerrume in Attributwerten werden entsprechend [XML] verarbeitet.

4. Unterschiede zu HTML 4

Aufgrund der Tatsache, da XHTML eine XML Anwendung ist, mssen bestimmte Praktiken, die im SGML basierendem HTML 4 [HTML] zulssig waren, gendert werden.

4.1 Dokumente mssen wohlgeformt sein

Wohlgeformtheit ist ein neues Konzept, das durch [XML] eingefhrt wurde. Im wesentlichen bedeutet dies, da alle Elemente entweder abschlieende Tags haben mssen, oder in einer speziellen Form geschrieben werden mssen (wie unten beschrieben) und da alle Elemente korrekt verschachtelt werden mssen.

Obwohl es in SGML illegal ist, zu berlappen, wurde es hufig in vorhandenen Browsern toleriert.

4.2 Element- und Attributnamen mssen klein geschrieben werden

XHTML Dokumente mssen Kleinschreibung fr 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 Fr 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 Schlieung impliziert. Diese Auslassung ist nicht erlaubt im XML basierendem XHTML. Alle Elemente auer denen, die in der DTD als EMPTY deklariert wurden, mssen einen End-Tag haben.

4.4 Attributwerte mssen immer in Anfhrungszeichen eingeschlossen werden

Alle Attributwerte mssen in Anfhrungszeichen eingeschlossen werden, sogar jene, die scheinbar numerisch sind.

4.5 Attributminimierung

XML untersttzt Attributminimierung nicht. Attribut-Wert Paare mssen ganz ausgeschrieben werden. Attributnamen wie compact und checked knnen nicht in Elementen auftauchen, ohne da ihr Wert angegeben wird.

4.6 Leere Elemente

Leere Elemente mssen entweder einen End-Tag haben oder der Start-Tag mu mit /> enden. Zum Beispiel <br/> oder <hr></hr>. Siehe HTML Kompatibilittsrichtlinien fr Informationen ber Mglichkeiten Abwrtskompatibilitt zu HTML 4 Benutzeragenten sicherzustellen.

4.7 Leerraum-Behandlung in Attributwerten

In Attributwerten werden Benutzeragenten fhrende und abschlieende Leerrume von Attributwerten entfernen und aus Folgen aus einer oder mehrerer Leerraum-Zeichen (inklusive Zeilenumbrchen) ein einzelnes Zwischenwort-Leerzeichen (ein ASCII Leerzeichen fr 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 < und & vom XML Prozessor als Entity-Referenzen fr < 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[   ... ungeschtzter (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 Ausschlsse

SGML gibt dem Verfasser einer DTD die Mglichkeit bestimmte Elemente davon auszuschlieen, in einem Element enthalten zu sein. Solche Verbote (Ausschlsse genannt) sind in XML nicht mglich.

Zum Beispiel verbietet die HTML 4 Strict DTD die Verschachtelung eines 'a' Elementes in einem anderen 'a' Element jeder Nachkommenstiefe. Es ist nicht mglich solche Verbote in XML auszusprechen. Obwohl diese Verbote nicht in der DTD definiert werden knnen, 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 fr die Elemente a, applet, form, frame, iframe, img und map. HTML 4 fhrte 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 gewhrleisten, da XHTML 1.0 Dokumente wohlstrukturierte XML Dokumente sind, MSSEN XHTML 1.0 Dokumente das id Attribut verwenden, wenn sie Fragmentsbezeichner definieren, auch fr Elemente die historischer Weise auch ein name Attribut gehabt haben. Vgl. die HTML Kompatibilittsrichtlinien fr Informationen um sicherzustellen, da solche Anker abwrtskompatibel sind, wenn XHTML Dokumente als Medientyp text/html geliefert werden.

Beachte das in XHTML 1.0 das name Attribut dieser Elemente formal mibilligt (deprecated) wurde und in anschlieenden Versionen aus XHTML entfernt werden wird.

5. Kompatibilittsangelegenheiten

Obwohl es kein Erfordernis fr XHTML 1.0 Dokumente gibt, kompatibel mit vorhandenen Benutzeragenten zu sein, ist es in Praxis leicht, dies zu erreichen. Richtlinien fr das Erstellen kompatibler Dokumente knnen in Anhang C gefunden werden.

5.1 Internet Medientyp

Zum Zeitpunkt der Verffentlichung dieser Empfehlung mu die allgemein empfohlene MIME Kennzeichnung fr XML basierte Anwendungen erst noch beschlossen werden.

Jedoch drfen XHTML Dokumente, die den Richtlinien aus Anhang C, "HTML Kompatibilittsrichtlinien", 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. Zuknftige Entwicklungen

XHTML 1.0 liefert die Basis fr eine Familie von Dokumenttypen die XHTML erweitern und unterteilen werden, um eine groe Breite neuer Gerte und Anwendungen zu untersttzen, 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 bentigt werden. Zum Beispiel ein Handheld-Gert oder ein Mobiltelefon kann nur eine Untermenge der XHTML Elemente untersttzen.

Der Proze der Modularisierung spaltet XHTML in eine Serie kleinerer Elementstze auf. Diese Elemente knnen dann wieder kombiniert werden, um den Bedarf verschiedener Interessensgruppen zu decken.

Diese Module werden in einem spteren W3C Dokument definiert.

6.2 Untermengen und Erweiterbarkeit

Die Modularisierung bringt mehrere Vorteile mit sich:

• Es liefert einen formellen Mechanismus fr die Unterteilung von XHTML.

• Es liefert einen formellen Mechanismus fr das Erweitern von XHTML.

• Es vereinfacht die Transformation zwischen Dokumenttypen.

• Es frdert die Wiederverwendung von Modulen in neuen Dokumenttypen.

6.3 Dokumentprofile

Ein Dokumentprofil spezifiziert Syntax und Semantik eines Dokumentsatzes. Konformitt zu einem Dokumentprofil liefert eine Basis fr Interoperabilittsgarantien. Das Dokumentprofil spezifiziert die notwendigen Fhigkeiten Dokumente dieses Typs zu verarbeiten, z.B. welche Bildformate benutzt werden knnen, Ebenen des Scriptings, Stylesheet-Untersttzung und so weiter.

Fr Produktdesigner erlaubt dies, verschiedenen Gruppen ihr eigenes Standardprofil zu definieren.

Fr Autoren wird dies der Notwendigkeit vorbeugen, mehrere verschiedene Versionen von Dokumenten fr verschiedene Clients zu schreiben.

Fr bestimmte Gruppen wie Chemiker, rzte oder Mathematiker erlaubt dies, ein spezielles Profil zu erstellen, mit Hilfe von Standard HTML Elementen zuzglich einer Gruppe auf die Bedrfnisse der Spezialisten abgestimmter Elemente.

Anhang A. DTDs

Dieser Anhang ist normativ.

Diese DTDs und Entittsstze formen einen normativen Teil dieser Spezifikation. Der vollstndige Satz der DTD Dateien zusammen mit einer XML Deklaration und dem SGML Open Catalog ist in der zip Datei fr 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.

• XHTML-1.0-Strict

• XHTML-1.0-Transitional

• XHTML-1.0-Frameset

A.2 Entity Stze

Die XHTML Entity Stze sind dieselben wie fr HTML 4, wurden aber verndert um gltige XML 1.0 Entity Deklarationen zu sein. Beachte, da das Entity fr das Euro Whrungssymbol (€ oder € oder €) als Teil der Sonderzeichen definiert wird.

• Latin-1 Zeichen

• Sonderzeichen

• Symbole

Anhang B. Elementverbote

Dieser Anhang ist normativ.

Die folgenden Elemente haben Beschrnkungen, welche Elemente sie enthalten knnen (vgl. Abschnitt 4.9). Dieses Verbot gilt fr alle Tiefen der Verschachtelung, d.h. es enthlt 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 Kompatibilittsrichtlinien

Dieser Anhang ist nicht normativ.

Dieser Anhang fat Entwurfsrichtlinien fr Autoren zusammen, die mchten, 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

Fge 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 fr leere Elemente, z.B. <br /> da die von XML erlaubte alternative Syntax <br></br> zu unsicheren Ergebnissen in vielen vorhandenen Benutzeragenten fhrt.

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 drfen. Deshalb ist zu erwarten, da die historische Praxis, Scripts und Stylesheets innerhalb von Kommentaren zu "verstecken", um die Dokumente abwrtskompatibel zu machen, nicht wie erwartet in XML-basierenden Implementationen funktioniert.

C.5 Zeilenumbrche in Attributwerten

Vermeide Zeilenumbrche und mehrfache Leerrume in Attributwerten. Diese werden von Benutzeragenten uneinheitlich behandelt.

C.6 Isindex

Fge 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 untersttzen die Benutzung von Attributen des Typs ID auf diese Weise nicht, daher darf fr diese beiden Attribute identische Werte angegeben werden um einen grtmglichen Grad an Kompatibilitt zu gewhrleisten (z.B. <a id="foo" name="foo">...</a>).

Da der Satz gltiger Werte fr Attribute des Typs ID viel kleiner ist, als fr die des Typs CDATA, wurde der Typ des name Attributes zu NMTOKEN gendert. Dieses Attribut ist so eingeschrnkt, 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 ausgedrckt werden. Wegen dieser nderung mu Sorge getragen werden, wenn vorhandene HTML Dokumente konvertiert werden. Die Werte diese Attribute mssen innerhalb des Dokumentes eindeutig und gltig sein und jede Referenz zu diesen Fragmentbezeichnern (sowohl interne wie externe) mu aktualisiert werden, sollte sich der Wert whrend der Konvertierung gendert haben.

Schlielich beachte, da XHTML 1.0 das name Attribut der a, applet, form, frame, iframe, img und map Elemente mibilligt (deprecated) hat und es aus XHTML in anschlieenden 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 auerstande, 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 fr XML und HTML 4. Das HTML 4 Dokumentobjektmodell legt fest, da HTML Element- und Attributnamen in Groschreibung zurckgeliefert werden. Das XML Dokumentobjektmodell legt fest, da Element- und Attributnamen in der Schreibweise zurckgeliefert 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 knnen das HTML DOM benutzen und sich darauf verlassen, da Element- und Attributnamen in Groschreibung von diesen Schnittstellen zurckgeliefert werden.
2. Anwendungen, die auf XHTML Dokumente, die als Internet Medientyp text/xml oder application/xml angeboten werden, zugreifen, knnen auch das XML DOM benutzen. Elemente und Attribute werden in Kleinschreibung zurckgeliefert. Auch knnen 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 knnen, so da ihre Start- und End-Tags beide ausgelassen werden knnen (ein SGML Merkmal). Dies ist nicht mglich in XML. Anstatt von Dokumentautoren zu verlangen, unwesentliche Elemente einzufgen, hat XHTML diese Elemente optional gemacht. Anwendungen mssen sich dementsprechend anpassen.

C.12 Et-Zeichen in Attributwerten verwenden

Wenn ein Attributwert ein Et-Zeichen enthlt, mu es als Entity-Referenz (z.B. "&") ausgedrckt 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&name=user ausgedrckt 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, abhngig von den benutzten Selektoren. Die folgenden Hinweise werden diesen Effekt fr Dokumente die ohne Vernderung als beide Medientypen angeboten werden verringern:

1. CSS Stylesheets fr 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 hinzufgen, 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 Konformittsregeln fr HTML und XML Dokumente; beachte, da die HTML Regeln fr XHTML Dokumente gelten, die als HTML geliefert werden und die XML Regeln fr 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 fr 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 verfgbar 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 verfgbar 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 verfgbar 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.
Verfgbar 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, Mrz 1997.
Verfgbar unter: http://www.ietf.org/rfc/rfc2119.txt

[RFC2376]

"RFC2376: XML Media Types", E. Whitehead, M. Murata, Juli 1998.
Verfgbar 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.
Verfgbar 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 verfgbar unter: http://www.w3.org/TR/REC-xml

[XMLNAMES]

"Namespaces in XML", T. Bray, D. Hollander, A. Layman, 14. Januar 1999.
XML Namensrume bieten eine einfache Methode Namen in XML Dokumenten zu qualifizieren indem man sie mit durch ein URI mit Namensrumen verbindet.
Neuste Version verfgbar unter: http://www.w3.org/TR/REC-xml-names