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.
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.
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:
- XHTML Dokumente sind XML konform. Als solche können sie ohne
weiteres mit Standard-XML-Werkzeugen betrachtet, bearbeitet und
validiert werden.
- XHTML Dokumente können 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 können Anwendungen nutzen (z.B. Skripte oder
Applets) die entweder vom HTML Dokumentobjektmodell oder vom XML
Dokumentobjektmodell [DOM] abhängig sind.
- Sowie sich die XHTML Familie weiterentwickelt, werden XHTML 1.0
konforme Dokumente eher zusammen mit und innerhalb verschiedener XHTML
Umgebungen arbeiten können.
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.
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.
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.
Die Vorteile, auf XHTML 1.0 umzustellen, werden oben beschrieben.
Einige der Vorteile, in XHTML im allgemeinen umzustellen, sind:
- Dokumententwickler und Benutzeragentenentwickler entdecken ständig
neue Möglichkeiten, ihre Ideen durch neues Markup auszudrücken. In XML
ist es relativ leicht, neue Elemente oder zusätzliche Attribute
einzuführen. 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 Merkmalssätze erlauben, wenn Inhalte
entwickelt werden und wenn neue Benutzeragenten entworfen werden.
- Alternative Möglichkeiten, auf das Internet zuzugreifen, werden
ständig eingeführt. Einige Schätzungen zeigen an, daß bis zum Jahr 2002
75% der Internetdokumentbetrachtungen auf diesen alternativen
Plattformen ausgeführt werden. Die XHTML Familie wurde im Gedanken an
eine generelle Benutzeragenten-Interoperabilität entworfen. Durch ein
neues Benutzeragenten- und Dokument-Profilierungssystem werden Server,
Proxies und Benutzeragenten in der Lage sein, bestmögliche
Inhaltstransformationen durchzuführen. Letztlich wird es möglich sein,
XHTML-konformen Inhalt zu entwickeln, der durch jeden XHTML-konformen
Benutzeragenten verwendbar ist.
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.
- 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.
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.
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:
-
Es muß gegen eine der drei DTDs in Anhang A
validieren.
-
Das Wurzelelement des Dokumentes muß <html>
sein.
-
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.
-
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.
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>
Ein konformer Benutzeragent muß allen folgenden Kriterien
entsprechen:
- 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].
- 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.
- 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.
- Wenn ein Benutzeragent auf ein Element stößt, das er nicht erkennt,
muß er den Inhalt des Elementes wiedergeben.
- 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.
- Wenn ein Benutzeragent auf einen Attributwert stößt, den er nicht
erkennt, muß er den Standardwert des Attributes verwenden.
- 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.
- 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.
- Die folgenden Zeichen werden in [XML] als
Leerraum-Zeichen definiert:
- Leerzeichen ( )
- Tabulator (	)
- Wagenrücklauf (
)
- Zeilenvorschub (
)
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:
- Seitenvorschub ()
- Leerzeichen mit der Breite Null (​)
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:
- Alle Leerräume, die Block-Elemente umgeben, sollten entfernt
werden.
- Kommentare werden ganz entfernt und beeinflussen die Behandlung von
Leerräumen nicht. Ein Leerraum-Zeichen auf jeder Seite des Kommentars
wird wie zwei Leerzeichen behandelt.
- Führende und abschließende Leerräume innerhalb eines Block
Elementes müssen entfernt werden.
- Zeilenvorschub-Zeichen innerhalb eines Block Elementes müssen 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 für die Sprache, in der der Inhalt
geschrieben wurde, geeignet ist. In Sprachen deren primäres 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, können 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, können typographischen
Leerraum mit einem Leerzeichen kodieren, können aber auch Leerzeichen
der Breite Null benutzen, um 'interne' grammatische Grenzen abzugrenzen
(was wie Worte in Arabisch für 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.
Leerräume in Attributwerten werden entsprechend [XML] verarbeitet.
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.
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>
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.
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.
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>
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>
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>
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].
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 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.
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.
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.
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.
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.
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.
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.
Die Modularisierung bringt mehrere Vorteile mit sich:
-
Es liefert einen formellen Mechanismus für die Unterteilung von
XHTML.
-
Es liefert einen formellen Mechanismus für das Erweitern von
XHTML.
-
Es vereinfacht die Transformation zwischen Dokumenttypen.
-
Es fördert die Wiederverwendung von Modulen in neuen
Dokumenttypen.
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.
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.
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.
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
(€ oder € oder
€) als Teil der Sonderzeichen definiert
wird.
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.
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:
- 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.
- 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. "&") 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&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:
- CSS Stylesheets für XHTML sollten kleingeschriebene Element- und
Attributnamen verwenden.
- 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.
- 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.
- 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.
- 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.
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
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
