(Entwurf) XHTML: HTML Kompatibilitätsrichtlinien 2.0

[mitaki]

Kurzes Vorwort: Der folgende Text ist zwar meines Wissens bereits vollständig, befindet sich aber noch im Entwurfsstadium. Ich bitte euch daher, mich auf alle Ungenauigkeiten etc. hinzuweisen, damit ich die entsprechenden Absätze überarbeiten kann. Danke.

HTML Kompatibilitätsrichtlinien 2.0a1
Arbeitsentwurf vom 16. November 2007

Übersicht

1. Hintergrund
2. Ist es ein (X)HTML-Dokument?
3. Richtlinien zur HTML-Kompatibilität
   
   1. Angabe der verwendeten Zeichenkodierung
   2. Verarbeitungsanweisungen
   3. Angabe der Elementsprache
   4. Auslagerung von Stil- und Skriptdaten
   5. Elemente mit leerem Inhaltsmodell
   6. Inhaltslose Elemente ohne leerem Inhaltsmodell
   7. Maskierung von (Markup-)Sonderzeichen
   8. Fehlende Attribute in XHTML
   9. Zeilenumbrüche in Attributen
   10. Nur in XML erlaubte Zeichen verwenden
   11. Das tbody-Element
   12. Die Interpretation von Stilangaben
       
       1. Hintergrundfarbe und -Bild des Anzeigebereichs
       2. Die overflow-Eigenschaft des Anzeigebereichs
       3. Groß- und Kleinschreibung
   13. Die Verarbeitung von Skripten
       
       1. document.write()
       2. Verwendung von DOM-Level-2-Methoden
4. Weitere Informationen
   
   1. Das isindex-Element
   2. Boolische Attribute
   3. Definition und Ansteuerung von Sprungzielen
   4. Inkompatibilität zu XHTML 1.1
   5. Zukunftsfähigkeit von XHTML
   6. Ausblick auf XHTML5

Hintergrund

Als Anfang 2000 die erste XHTML-Spezifikation veröffentlich wurde, gab es kaum Browser die XHTML tatsächlich als solches verarbeiten konnten. Genauer gesagt war den Browsern der XHTML-Medientyp „application/xhtml+xml“ unbekannt. Webautoren waren jedoch neugierig und wollten das „neue“ HTML ausprobieren.
Aus diesem Grund enthält die Spezifikation der XHTML-Version 1.0 einen informativen Anhang. Dieser gibt Hinweise, wie XHTML-Quelltext beschaffen sein muss, damit dieser auch von HTML-Browsern verarbeitet werden kann. Damit dies möglich wird, wurde es Dokumenten der XHTML-Version 1.0 (und nur dieser) erlaubt, mit dem HTML-Medientyp „text/html“ versendet zu werden.
Dieser Anhang war nötig, da XHTML auch ein bisschen „Ballast“ von XML mitgenommen hat. Darüberhinaus kann Quelltext in HTML eine andere Bedeutung haben als in XHTML.
Wie bereits angesprochen wurden diese Regeln im Jahr 2000 verfasst. Ende 2002 wurde die XHTML-1.0-Spezifikation, und damit diese Richtlinien, leicht überarbeitet. Dennoch sind diese Hinweise aus heutiger Sicht veraltet, teilweise falsch und vor allem lückenhaft, denn viele problematischen Punkte werden gar nicht erwähnt.

Ist es ein (X)HTML-Dokument?

Damit man mit den Kompatibilitätsrichtlinien vernünftig arbeiten kann, ist es notwendig zu verstehen, ob es sich bei einem Dokument um ein HTML- oder ein XHTML-Dokument handelt. Dies wird durch den Medientyp des Dokuments bestimmt, denn daran erkennt der Browser, wie er das Dokument verarbeiten muss.
HTML-Dokumente sind untrennbar mit dem Medientyp „text/html“ verbunden. Ein XHTML-Dokument dagegen sollte als Medientyp „application/xhtml+xml“ besitzen, kann aber auch als „application/xml“ versendet werden. Früher war auch „text/xml“ möglich, gilt heute aber als veraltet.
Trotz dieser Definition kommt es oft zu Verständnisproblemen. Vielen Autoren ist nicht klar, dass XHTML-Quelltext, der als „text/html“ versendet wird, als HTML verarbeitet wird und daher ein HTML-Dokument ist.
Wir merken uns folgendes:

• Ein Dokument ist ein HTML-Dokument, wenn es mit dem Medientyp „text/html“ versendet wird.
• Ein Dokument ist ein XHTML-Dokument, wenn es mit einem XML-Medientyp wie „application/xhtml+xml“ oder „application/xml“ versendet wird.

Richtlinien zur HTML-Kompatibilität

Dieser Abschnitt führt die Richlinen auf, die beachtet werden müssen, wenn XHTML-Quelltext als HTML verarbeitet werden soll. Zudem wird gezeigt, woher diese Verarbeitungsunterschiede kommen, damit diese besser verstanden werden können.
Achtung: Einige dieser Unterschiede, vor allem im Bereich der Verarbeitung von Stilangaben und Skripten, werden browserweit sehr unterschiedlich interpretiert. Oftmals werden Regeln nicht ausgeführt oder gar gebrochen. Nur die in Diesem Dokument enthaltene Definition ist in diesen Fällen gültig.

1. Angabe der verwendeten Zeichenkodierung
Diese Richtlinie muss befolgt werden.

Die Zeichenkodierung, die das Dokument verwendet, muss so angegeben sein, dass diese sowohl von HTML- als auch von XML-Parsern erkannt werden kann.

Begründung

Dokumente, die keine Informationen über den Zeichensatz enthalten, mit dem sie kodiert wurden, müssen mit der Standardzeichenkodierung verarbeitet werden.

[...] user agents must not assume any default value for the "charset" parameter.

...

HTML-Dokumente besitzen keine Standardzeichenkodierung. Die Spezifikation von HTML 4.01 geht jedoch nicht weiter auf diese Problematik ein. Die Browserhersteller haben daher verschiedene Ansätze entwickelt, um die Kodierung eines Dokuments festzustellen.

[...] (An XML) declaration is required when the character encoding of the document is other than the default UTF-8 or UTF-16 and no encoding was determined by a higher-level protocol.

...

Für XHTML-Dokumente gilt als Standardzeichenkodierung entweder UTF-8 oder UTF-16.

Vorgehensweise

Die verwendete Zeichenkoderung kann innerhalb eines HTML-Dokuments sehr einfach festgelegt werden. Dazu ist es notwendig ein meta-Element mit diesen Informationen als erstes Kind des head-Elements zu erzeugen.

Code:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
 <meta http-equiv="content-type" content="text/html; charset=utf-8" />
 <!-- weiterer Quelltext -->

Die Metaangabe muss an erster Stelle stehen, weil der Titel eines Dokuments bereits Sonderzeichen enthalten kann, die in den zahlreichen Zeichensätzen eine unterschiedliche Bedeutung haben. Daher dürfen vor dieser Angabe auch keine Kommentare stehen, die Sonderzeichen enthalten.
In der Angabe muss der Medientyp „text/html“ angegeben werden. Einerseits, weil das der Wahrheit entspricht, andererseits weil nicht jedes Benutzerprogramm aus einer Metaangabe mit „application/xhtml+xml“ die Zeichenkodierung herauslesen kann.
Wird als Zeichenkodierung UTF-8 oder UTF-16 verwendet ist diese Angabe die einzig notwendige. Wird eine andere Zeichenkodierung verwendet, muss diese für XML-Parser angegeben werden.

Code:

<?xml version="1.0" encoding="iso-8859-1" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
 <meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />
 <!-- weiterer Quelltext -->

Dies geschieht durch die XML-Deklaration, welche vor der Dokumenttypangabe angegeben wird. XML-Parser erkennen die Zeichenkodierung aus der Deklaration, HTML-Parser aus der Metaangabe.
Hinweis: XML-Parser können zusätzlich auch eine Byte-Order-Mark verarbeiten. Da diese aber vor allem bei der Arbeit mit serverseitigen Werkzeugen Probleme verursachen kann, sollte keine Byte-Order-Mark gesetzt werden.

Problemfall: Internet Explorer 6

Aus dieser Richtlinie ergibt sich ein Problem im Zusammenspiel mit dem Internet Explorer. Da der Version 6 die XML-Deklaration unbekannt ist, wird der IE 6 in den Quirksmodus versetzt. Das bedeutet die Darstellung entspricht dem IE 5.5 und all dessen Fehlern wie beispielsweise das falsch berechnete Boxenmodell.
Wird also eine andere Zeichenkodierung als UTF-8 oder UTF-16 verwendet, kann keine browserweit ähnliche Darstellung erreicht werden. Da der Internet Explorer 6 noch über ein Drittel des Marktes beherrscht ist eine abweichende Zeichenkodierung (oder alternativ: XHTML selbst) keine Option.

2. Verarbeitungsanweisungen
Diese Richtlinie muss befolgt werden.

Ein Dokument darf keine Verarbeitungsanweisungen (Processing Instructions) enthalten.
Beispiel: Eine Verarbeitungsanweisung, die eine Stildatei referenziert.

Code:

<?xml-stylesheet href="./stilangaben.css" type="text/css" ?>

Begründung

Verarbeitungsanweisungen versetzen den Internet Explorer bis Version 7 in den Quirksmodus, d.h. eine browserweit ähnliche Darstellung wird unmölich.
Unabhängig davon können können Verarbeitungsanweisungen, wie andere XML-Features, von HTML-Parsern nicht verarbeitet werden (meist werden sie ignoriert).

3. Angabe der Elementsprache
Diese Richtlinie muss befolgt werden.

Wird die Elementsprache definiert, muss diese Information für HTML- und XML-Parser verfügbar und identisch sein.

Begründung

Die Sprache eines HTML-Elements wird mit dem lang-Attribut definiert. Wird das Dokument von einem HTML-Parser verarbeitet ist dieses Attribut ausschlaggebend. Die Elementsprache in XHTML-Dokumenten wird mit dem xml:lang-Attribut definiert. Bei der Verarbeitung mit einem XML-Parser wird nur dieses Attribut beachtet.
Beide Attribute müssen den selben Wert enthalten. Beispielsweise ein Absatz:

Code:

<p lang="de" xml:lang="de">Deutscher Text</p>

Erkennung durch Stilangaben

[...] (in HTML), the language is determined by a combination of the "lang" attribute, the META element, and possibly by information from the protocol (such as HTTP headers). XML uses an attribute called xml:lang, and there may be other document language-specific methods for determining the language.

...

Die Sprachangaben eines Elements können bei der Arbeit mit Stilangaben verwendet werden. Folgender Quelltext angenommen:

Code:

<p lang="de" xml:lang="de">Deutscher und <em>betonter</em> Text.</p>

Die CSS-Pseudoklasse :lang(de) trifft hier sowohl auf das p- als auch das darinliegende em-Element zu, denn dieses erbt die Sprachinformation von seinem Elternelement.
Wird ein Dokument als HTML verarbeitet trifft die :lang-Pseudoklasse auf das lang-Attribut zu, anderfalls auf das xml:lang-Attribut.
Der Attributselektor [lang=de] würde nur das p-Element formatieren. Außerdem würde ein Attributselektor unabhängig von der Verarbeitung des Dokuments zwischen dem lang- und dem xml:lang-Attribut unterscheiden.
Zu beachten ist jedoch, dass das xml:lang-Attribut einerseits in HTML unbekannt ist, andererseits vom Internet Explorer bis Version 7 nicht erkannt wird. Das ist aber kein Problem, da das lang-Attribut beiden Sprachen und dem Internet Explorer bekannt ist.

4. Auslagerung von Stil- und Skriptdaten
Diese Richtlinie muss befolgt werden.

Stilangaben und Skripte (z.B. Javascript) müssen in externen Dateien gelagert werden.

Begründung

Für HTML-Dokumente ist es unproblematisch, Stilangaben und Skripte innerhalb des Dokuments in style- bzw. script-Elemente zu verpacken. Lediglich XHTML-Dokumente haben hier Probleme.
In XHTML wurde das Inhaltsmodell der style- und script-Elemente verändert, so dass Sonderzeichen wie < und &amp; dort eine andere Bedeutung besitzen als in HTML. Würden diese Zeichen verwendet werden, könnte das Dokument nicht angezeigt werden, da die Sonderzeichen laut XML-Regeln „falsch“ eingesetzt wären.
Die aus früheren Zeiten bekannte (und heute überflüssige) Methode, problematischen Inhalt dieser Elemente durch Kommentare zu verstecken, ist in XHTML-Dokumenten nicht möglich, da ein XML-Parser den Kommetarinhalt löschen würde, bevor dieser berücksichtigt wird.
XML bietet für dieses Problem eine Lösung, diese kann aber von HTML-Parsern nicht verarbeitet werden und führt daher wiederum zu Fehlern.

Problemlösung: Guten Stil bewahren

Die Lösung für dieses Problem ist sehr simpel und ist für gute Webautoren längst selbstverständlich, denn Inhalt, Design und Verhalten eines Dokuments sollten stets voneinander getrennt werden. Folgt man diesem Grundsatz, ist eine fehlerfreie Verarbeitung des Dokuments möglich.
Stilangaben und Skripte können sehr einfach im Kopf eines Dokuments eingefügt werden, ohne Probleme zu verursachen:

Code:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
 <meta http-equiv="content-type" content="text/html; charset=utf-8" />
 <link rel="stylesheet" type="text/css" media="screen" href="stilangaben.css" />
 <style type="text/css">@import './stilangaben.css' projection;</style>
 <script type="text/javascript" src="./script.js"></script>
 <!-- weiterer Quelltext -->

5. Elemente mit leerem Inhaltsmodell
Diese Richtlinie muss befolgt werden.

Elemente mit leerem Inhaltsmodell (area-, base-, basefont-, br-, col-, frame-, hr-, img-, input-, isindex-, link-, meta- und param-Elemente) müssen selbstschließend geschrieben werden.

Begründung

Die genannten Elemente dürfen in HTML nur als Start-Tag vorkommen. In XHTML ist eine derartige Definition der Elemente nicht möglich, daher müssen diese Elemente selbstschließend (z.B. <hr/>) oder in einer Start- und End-Tag-Kombination geschrieben werden (z.B. <hr></hr>).
Die Start- und End-Tag-Kombination wird jedoch von HTML-Parsern unterschiedlich interpretiert und führt bei verschiedenen Elementen zu unerwarteten Ergebnissen. Daher hat sich die selbstschließende Schreibweise durchgesetzt.
Bei der selbstschließenden Schreibweise sollte man darauf achten, vor den Solidus ein Leerzeichen einzufügen (z.B. <hr />), da die Schreibweise <hr/> in standardkonformen HTML-Parsern <hr>&gt; entspricht (dies wird aber vom Großteil der HTML-Parser ebenfalls ignoriert).

6. Inhaltslose Elemente ohne leerem Inhaltsmodell
Diese Richtlinie muss befolgt werden.

Elemente, deren Inhaltsmodell nicht leer ist (Elemente mit leerem Inhaltsmodell wurden in Richtlinie 5 besprochen), aber keinen Inhalt besitzen (z.B. <script></script> oder <div></div>), dürfen nicht in der selbstschließenden Schreibweise geschrieben werden.

Begründung

In HTML gibt es keine selbstschließenden Elemente, die Schreibweise <div/> wäre also fehlerhaft. Bei Elementen ohne leerem Inhaltsmodell kann der Parser diesen Fehler aber nicht einfach ignorieren.
Stattdessen werden diese Elemente als Start-Tag interpretiert, d.h. <div/> entspricht <div>. Wird beim parsen des Dokuments kein passendes End-Tag gefunden wird dieses vor Beginn des body-End-Tags eingefügt. In Kombination mit Stilangaben oder Skripten durchaus eine zerstörerische Kraft. Bei script-Elementen ist es ähnlich, denn wird <script/> als Start-Tag interpretiert kann ein Teil des folgenden Quelltextes als Skript verarbeitet werden und für den Betrachter des Dokuments unsichtbar.

7. Maskierung von (Markup-)Sonderzeichen
Diese Richtlinie muss, muss und sollte befolgt werden.

Die Markup-spezifischen Sonderzeichen < (kleiner als), > (größer als), & (kaufmännisches Und) sowie " (das Zollzeichen bzw.) müssen maskiert werden (&lt;, &gt;, &amp; und &quot; respektive).
Das Sonderzeichen ' (Apostroph) darf nicht durch &apos; maskiert werden. Es kann durch die numerische (& #39;) bzw. hexadezimale Schreibweise (&#x27;) maskiert werden.
Andere Sonderzeichen wie die deutschen Umlaute sollten nicht maskiert werden, stattdessen sollte ein entsprechender Zeichensatz für das Dokument gewählt werden.

Begründung

Das kleiner-als-Zeichen leitet ein Element bzw. eine Auszeichnung ein, würde es in einem Text vorkommen, z.B. als 2<3 würde ein XML-Parser auf ein unbekanntes bzw. fehlerhaftes Element treffen und einen Fehler verursachen.
Das kaufmännische Und leitet in den Auszeichnungssprachen eine Entität ein, d.h. die Maskierung eines Sonderzeichens. Unmaskiert wird der darauf folgende Text selbst als Maskierung misverstanden. Für einen XML-Parser grund genug das Parsen abzubrechen und eine Fehler auszuwerfen.
Das größer-als-Zeichen, das Zollzeichen und der Apostroph verursachen in der Regel keine Fehler. Zollzeichen und Apostroph können Attributwerte umschließen und müssen daher maskiert werden, wenn sie selbst innerhalb von Attributwerten vorkommen.
Die Maskierung &apos; für den Apostroph wurde in XML eingeführt, ist HTML-Parsern jedoch unbekannt. Daher muss die numerische bzw. hexadezimale Schreibweise verwendet werden.
Andere Sonderzeichen wie die deutschen Umlaute und Satzzeichen sollten nicht maskiert sondern ein entsprechender Zeichensatz (idealerweise UTF-8) verwendet werden. Einige XML-Werkzeuge prüfen das Dokument nicht auf Gültigkeit nach den Regeln der DTD (der Dokumenttypdefinition), daher sind ihnen die darin definierten Entitäten unbekannt. Das gilt auch für alle HTML-Maskierungen. Stößt ein XML-Werkzeug nun auf eine dieser Maskierungen stellt dieses ein unbekanntes Objekt dar und es wird ein Fehler verursacht, das Dokument kann nicht weiter verarbeitet werden.

8. Fehlende Attribute in XHTML
Diese Richtlinie muss befolgt werden.

In der Variante Strict darf das form-Element kein name-Attribut besitzen. In keiner Variante darf das input-Element das ismap-Attribut besitzen.

Begründung

In den XHTML-DTDs sind diese Attribute nicht definiert, sie können daher in einem XHTML-Dokument nicht verwendet werden.

9. Zeilenumbrüche in Attributen
Diese Richtlinie muss befolgt werden.

Innerhalb von Attributen müssen Zeilenumbrüche vermieden werden.

Begründung

Attributwerte, die Zeilenumbrüche enthalten werden von den Benutzerprogrammen unterschiedlich interpretiert, daher müssen sie vermieden werden.

10. Nur in XML erlaubte Zeichen verwenden
Diese Richtlinie muss befolgt werden.

Das Dokument darf nur aus Zeichen bestehen, die in einem XML-1.0-Dokument ebenfalls erlaubt sind.

Begründung

Zeichen, die in einem XML-Dokument der Version 1.0 (dazu gehören alle XHTML-Dokumente) nicht erlaubt sind, dürfn nicht verwendet werden, da ein XML-Parser sonst einen Fehler wirft.

Beispiel: In HTML wird das Zeichen U+000C (&#xc;) wie ein Leerzeichen behandelt. In XML ist es verboten.

11. Das tbody-Element
Diese Richtlinie muss befolgt werden.

Tabellen (table-Elemente) dürfen keine tr-Elemente als Kindelemente besitzen. tr-Elemente dürfen nur Kinder von thead-, tfoot- und tbody-Elementen sein.

Begründung

In HTML können einige Elemente im Quelltext weg gelassen werden. Sie werden dann nachträglich vom Parser eingefügt. Das gilt z.B. für das html-, body- und tbody-Element. In XHTML (genauer: XML) kann diese Eigenschaft eines Elements nicht ausgedrückt werden, daher ist das html- und das body-Element in XHTML Pflicht. Das tbody-Element jedoch nicht.
Dieser Unterschied ergibt sich nicht direkt aus der Spezifikation, sondern aus den Dokumenttypdefinitionen (DTDs):

Code:

<!ELEMENT TABLE - - (CAPTION?, (COL*|COLGROUP*), THEAD?, TFOOT?, TBODY+)>
<!ELEMENT TBODY - O (TR)+ -- table body -->

...

Code:

<!ELEMENT table (caption?, (col*|colgroup*), thead?, tfoot?, (tbody+|tr+))>

...

Alle wichtigen Eigenschaften des table-Elements sind definiert: In XHTML wird der Elementname klein geschrieben, es kann ein caption-Element beinhalten, ein oder mehrere col- bzw. colgroup-Elemente und auch thead- und tfoot-Elemente. Der letzte Punkt der Elementdefinition macht den Unterschied zwischen HTML und XHTML klar.
In HTML kann ein table-Element keine tr-Elemente als Kind besitzen, dafür ist das tbody-Element pflicht. Das tbody-Element ist jedoch so definiert, dass der Autor es nicht in den Quelltext schreiben muss, der HTML-Parser fügt das Element selbstständig ein.
Da diese Eigenschaft XML-Elementen unbekannt ist wurde die Definition des table-Elements in XHTML leicht verändert: Es kann entweder thead-, tfoot- und tbody-Elemente als Kind haben - dann müssen diese auch in den Quelltext geschrieben werden - oder tr-Elemente.

12. Die Interpretation von Stilangaben
Diese Richtlinie muss befolgt werden.

Stilregeln müssen so definiert werden, dass sie bei der Verarbeitung eines Dokuments als HTML bzw. XML eine identisch Ausgabe erzeugen.

Begründung

Für HTML gibt es eine Reihe von Sonderregelungen, die bei der Interpretation von Stilangaben beachtet werden müssen. In XHTML-Dokumenten werden diese Sonderregelungen jedoch nicht berücksichtigt.

CSS defines different conformance rules for HTML and XML documents; be aware that the HTML rules apply to XHTML documents delivered as HTML and the XML rules apply to XHTML documents delivered as XML.

...

Nicht alle CSS-fähigen Browser setzen diese Regeln korrekt um, das ist mitunter einer der Gründe, warum sich Autoren von XHTML-Quelltext hier der Problematik nicht bewusst sind.
Die Spezifikation von CSS 2.1 ist zwar schon recht ausgereift, aber noch immer in Bearbeitung. Daher könnten diese Sonderregelungen in Zukunft auch wegfallen.
Im einzelnen sind folgende Bereiche betroffen:

12.1 Hintergrundfarbe und -Bild des Anzeigebereichs

For HTML documents whose root HTML element has computed values of 'transparent' for 'background-color' and 'none' for 'background-image', user agents must instead use the computed value of those properties from that HTML element's first BODY element child when painting backgrounds for the canvas, and must not paint a background for that BODY element. Such backgrounds must also be anchored at the same point as they would be if they were painted only for the root element. This does not apply to XHTML documents.

...

In dieser Sonderregelung für HTML stecken viele Informationen. Geht man die Spezifikation der relevanten Eigenschaften und diesen Absatz Schritt für Schritt durch, werden aus der Spezifikation folgende Punkte deutlich:

• Für jedes Element ist der Standardwert der background-color-Eigenschaft transparent (durchsichtig).
• Für jedes Element ist der Standardwert der background-image-Eigenschaft none (keines).
• In HTML wird der Anzeigebereich durch das body-Element definiert, in XML durch das Wurzelelement des Dokuments (in XHTML das html-Element).
• Ist keine dieser Eigenschaften für das html-Element definiert, aber eine oder beide für das body-Element, so werden diese definierten Eigenschaften vom body-Element entfernt und auf das html-Element übertragen.

Wäre eine dieser Eigenschaften also für das body-Element definiert, würde bei der Anzeige des Dokuments als XML tatsächlich nur das body-Element und nicht der Anzeigebereich betroffen sein.

12.2 Die overflow-Eigenschaft des Anzeigebereichs

UAs must apply the 'overflow' property set on the root element to the viewport. HTML UAs must instead apply the 'overflow' property from the BODY element to the viewport, if the value on the HTML element is 'visible'. The 'visible' value when used for the viewport must be interpreted as 'auto'. The element from which the value is propagated must have a used value for 'overflow' of 'visible'.

...

Diese Sonderregelung ähnelt der für die Eigenschaften von Hintergrundfarbe und Bild. Auch hier ergeben sich folgende Punke aus der Spezifikation:

• Für jedes Element ist der Standardwert der overflow-Eigenschaft visible. Das bedeutet, wenn für ein Element Höhe und Breite definiert sind, der Inhalt aber mehr Platz als verfügbar benötigt, wird der Inhalt außerhalb des Elements dargestellt. Sind Höhe und Breite nicht definiert, so vergrößert sich das Element, bis genug Platz für seinen inhalt ist.
• Ist der Wert der overflow-Eigenschaft für das html-Element visible und der Wert der Eigenschaft für das body-Element definiert, so wird der Wert vom body-Element entfernt und auf das html-Element übertragen.
• Das html-Element bestimmt die Beschaffenheit des Anzeigebereichs. Ist der Wert der overflow-Eigenschaft für das html-Element visible, verändert er sich automatisch auf „auto“ (d.h. der Bereich sollte Scrollbar werden, das ist aber vom Darstellungsprogramm abhängig).

12.3 Groß- und Kleinschreibung

Wird ein Dokument als XML verarbeitet spielt die Groß- und Kleinschreibung eine wichtige Rolle. Die trifft auch auf Stilangaben zu. Element- und Attributnamen müssen kleingeschrieben werden.

13. Die Verabeitung von Skripten
Diese Richtlinie muss befolgt werden.

Die write()- bzw. writeln()-Methoden in JavaScript dürfen nicht verwendet werden. Wird mit Methoden des DOM gearbeitet müssen die Namensraum-fähigen Methoden des Level-2-DOMs verwendet werden.
Die Begründung folgt in den Unterpunkten.

13.1 document.write()

Die JavaScript-Funktionen write() und writeln() können in XHTML nicht verwendet werden, da es durch die Definition von XML Skripten verboten ist, während des Parsevorgangs beliebigen neuen Text in das Dokument einzufügen.

13.2 Verwendung von DOM-Level-2-Methoden

Alle XHTML-Elemente und -Attribute befinden sich im XHTML-Namensraum (http://www.w3.org/1999/xhtml). Soll in das Dokument dynamisch ein neues Element eingefügt werden, so muss das einzufügende Element (das gilt auch für Attribute) dem XHTML-Namensraum angehören. Dies ist nur mit den Methoden des DOM-Level-2-Kerns möglich.

DOM Level 1 methods are namespace ignorant.

...

Das bedeutet, fügt man mit der Level-1-Methode createElement() ein p-Element ein, erhält man kein Absatzelement, sondern ein unbekanntes Inlinelemement (Inline deshalb, weil das der Standardwert für undefinierte Elemente ist).
Stattdessen muss man die Namensraum-fähigen Level-2-Methoden verwenden. Diese haben den selben Namen, nur mit „NS“ als Suffix.

Code:

NeuesElement = document.createElementNS('http://www.w3.org/1999/xhtml','p');

Der Vorteil der Level-2-Methoden ist, dass das erzeugte Element sowohl von XML-Parsern als auch von HTML-Parsern verarbeitet werden kann.
Elemente aus dem XHTML-Namensraum werden von üblichen HTML-Parsern als identische HTML-Elemente erkannt. Der tatsächliche HTML-Namensraum wäre aber „null“, da HTML selbst über keinen Namensraum verfügt.

Weitere Informationen
Die folgenden Informationen sind zwar sehr wichtig, haben aber nicht die nötige Relevanz für eine Richtlinie.

1. Das isindex-Element
Das isindex-Element ist veraltet und daher nur in den Varianten Transitional und Frameset erlaubt. Es soll durch das input-Element ersetzt werden, da isindex keine brauchbaren Informationen liefert und nicht browserweit implementiert ist.
Als HTML verarbeitete Dokumente zeigen durch dieses Element ein Eingabefeld für Suchanfragen an. Als XML verarbeitet, wird die Anzeige des Dokuments nicht beeinflusst.
Als Richtlinie wäre dieses Element verboten.

2. Boolische Attribute
In HTML gibt es so genannte boolische Attribute. Das sind Attribute wie compact, nowrap, ismap, declare, noshade, checked, disabled, readonly, multiple, selected, noresize und defer, denen kein Wert zugewiesen wird.
In XHTML muss diesen Attributen ihr Name als Wert zugewiesen werden. Es soll Parser geben, die diese Schreibweise nicht verstehen. Das ist jedoch ein Fehler des Parsers, denn die ausgeschriebene Schreibweise entspricht gültigem HTML.

3. Definition und Ansteuerung von Sprungzielen
Für XHTML ist definiert, was tatsächlich schon für HTML definiert war. Ein Sprungziel wird definiert, indem man einem beliebigen Element eine ID gibt. Als Vereis zu diesem Sprungziel wird die ID mir vorangestelltem Gatterzeichen (#) referenziert.

Code:

<a href="#IDReferenz">Sprungziel ansteuern.</a>
<!-- Quelltext dazwischen -->
<p id="IDReferenz">Sprunziel definieren.</p>

4. Inkompatibilität zu XHTML 1.1
XHTML 1.1 ist inkompatibel zu XHTML 1.0, denn der Wert des usemap-Attributs der img-, input- und object-Elemente muss in den beiden Versionen unterschiedlich Angegeben werden.
In XHTML 1.0 (identisch zu HTML 4.01) muss der Wert eine Hypertext-Referenz sein (identisch zum Ansteuern von Sprunfzielen) z.B. „#map“. Ab XHTML 1.1 muss der Wert eine ID referenzieren und darf nur diese referenzierte ID als Wert enthalten, z.B. „map“.
Das ist einerseits Problematisch, weil die Darstellungsprogramme dieses Verhalten kaum implementiert haben. Zum anderen wird dadurch unklar, wie sich ein XML-Werkzeug verhalten soll, das den XHTML-Namensraum implementiert hat, aber nur ein XHTML-Fragment parst.
XHTML 1.1 basiert offiziell nicht auf dem Sprachschatz von HTML 4.01, daher ist das versenden von XHTML-1.1-Dokumenten als „text/html“ verboten.

5. Zukunftsfähigkeit von XHTML
XHTML 2.0 befindet sich seit Jahren im Entwurfsstadium und plant große Veränderungen im Vergleich zur Vorgängerversion. So werden beispielsweise Formulare durch die XML-Technik XForms ersetzt, p-Elemente sollen Blockelemente enthalten können und nahezu jedes Element wird als Verweis bzw. Bildalternative eingsetzt werden können.
Das hört sich alles sehr gut an, und tatsächlich bietet XHTML 2.0 einige Vortschritte, doch gibt es mehr als einen Wermutstropfen.
Aktuell möchte die XHTML-2.0-Arbeitsgruppe den XHTML 1.x-Namensraum übernehmen. Dies hätte fatale Auswirkungen: Dokumente, die nach den Regeln von XHTML 1.x verfasst wurden könnten so übernacht ungültig werden. Hier tritt erneut das Problem der Verarbeitung auf: Wie soll ein XML-Werkzeug wissen, welche Elementdefinition, wenn es nur ein XHTML-Fragment verarbeitet?
Unabhängig davon haben Browserentwickler bereits kommentiert, dass die Ausweitung der Verweis- und Alternativtechnik für Bilder einen nicht verantwortbaren Aufwand bei der Implementierung darstellen würde.

6. Ausblick auf XHTML5
Auch auf Grund der Problematik von XHTML 2.0 haben sich seit Mitte 2004 die Browserhersteller Mozilla, Opera und Apple zu der WHATWG zusammengeschlossen. Diese Arbeitsgruppe hat sich zum Ziel gesetzt HTML weiterzuentwickeln. Der Arbeitsentwurf, Web Applications 1.0 wurde Anfang 2007 von der HTML-Arbeitsgruppe beim W3C zur Basis für die neue HTML Version 5 gewählt.
HTML5 definiert die Sprache HTML (HTML5), die XML-Formulierung dieser Sprache (XHTML5) und die Darstellung dieser Sprache im DOM (DOM5).
Zwar definiert HTML5 einige Elemente ebenfalls neu, legt dabei aber hohen Wert auf Rückwärtskompatibilität. Der Entwurf der Spezifikation definiert die Syntax von HTML selbst neu, so dass diese in Zukunft von Validatoren besser überprüft werden kann.
Für XHTML5 gelten die Regeln von XML, aber auch hier wird Wert darauf gelegt, die Unterschiede zwischen HTML und XHTML zu verringern (das gilt für die Syntax ebenso wie für die Arbeit mit DOM-Methoden).
Die HTML-Arbeitsgruppe möchte für XHTML5 den XHTML-Namensraum verwenden und steht damit in Konkurrenz zur XHTML-2.0-Arbeitsgruppe. Die HTML-Arbeitsgruppe hat aber angekündgt auch ohne diesen Namensraum zu XHTML 1.0 kompatibel zu bleiben.

[DFYX]

Naja, ein Ansatz wäre gewesen, das auf Dev-Comm zu posten, statt hier im Forum. Dafür gibts die Seite schließlich

[mitaki]

Wäre eine Möglichkeit gewesen, aber ich hab d_o noch nicht erreicht und er hatte ja bereits einen Accoutn für mich eingerichtet.

Ich habs nebenbei auch in einem XHTML-Forum gepostet, aber nur wenig resonanz erhalten, ist wohl auch sehr viel Text geworden..

Wenn du die umformatierung übernimmst, so dass es ins Dev-Comm passt, können wir gerne weiterreden^^

Allerdings fällt mir auf, dass Dev-Comm ebenfalls giftiges XHTML verwendet.

[DFYX]

Den Account hab ich angelegt. Das Passwort kann ich dir gerne per PN schicken. Und die Formatierung unterscheidet sich eigentlich nur unwesentlich von der im Forum. Der einzige Unterschied ist, dass Größenangaben anders funktionieren und dass es für Überschriften [h1], [h2] usw. gibt.

[Manni]

Danke für diesen wie gewohnt guten Artikel

Ich habe glaube ich einiges Neues über XHTML gelernt und werde diesen Artikel in Zukunft als Referenz heranziehen, wenn ich mal wieder XHTML verbreche. Kritik fällt mir eigentlich keine ein, der Artikel ist gut strukturiert und vollständig.

Mal schauen, ob ich demnächst den XHTML Code von Dev-Comm überarbeite

[mitaki]

Danke für diesen wie gewohnt guten Artikel

...

Danke, dabei ist's nur ein Entwurf. An anderer stelle wurde mir Ungenauigkeit vorgeworfen. Aber da gibts ja auch tatsächlich ein paar Stellen, die ich noch überarbeiten werde.

Ich habe glaube ich einiges Neues über XHTML gelernt und werde diesen Artikel in Zukunft als Referenz heranziehen, wenn ich mal wieder XHTML verbreche. Kritik fällt mir eigentlich keine ein, der Artikel ist gut strukturiert und vollständig.

...

Und wenn ich nur einem einizgen was beibringen konnte ist es Genugtuung^^

Mal schauen, ob ich demnächst den XHTML Code von Dev-Comm überarbeite

...

Ich habe meinen ganzen XHTML-Enthusiasmus verloren, auch aufgrund dieser ganzen Richtlinien, die beachtet werden müssen. Dafür nur einen Vorteil zu erhalten ist mir zu wenig. Strengere Validierung ist auch bei HTML möglich und den Rest der möglichen Fehler kann man als guter Autor vermeiden.
Inzwischen überzeugt mich HTML 5 mehr und mehr. Witzigerweise wäre HTML 5 auch eine gute Wahl für Dev-Comm. Schade, dass es noch ein paar Jahre dauert bis man damit vernünftig arbeiten kann...

Nebenbei zu Dev-Comm. Es wäre toll, wenn ein paar der Links zu Webdesign gelöscht werden könnten. Dokumente ohne Doctype und Frames sollten nur in berechtigten Fällen gelehrt werden. Niemals als Einstieg für Anfänger. Das oder ein Bewertungssystem für die Einträge.
Wenn ich die Zeit hätte müsste ich wohl auch mal einen HTML-Kurs schreiben. ^^

[DFYX]

Nebenbei zu Dev-Comm. Es wäre toll, wenn ein paar der Links zu Webdesign gelöscht werden könnten. Dokumente ohne Doctype und Frames sollten nur in berechtigten Fällen gelehrt werden. Niemals als Einstieg für Anfänger. Das oder ein Bewertungssystem für die Einträge.
Wenn ich die Zeit hätte müsste ich wohl auch mal einen HTML-Kurs schreiben. ^^

...

Such uns raus, was weg muss und wir schmeißens raus. Wir hatten nur bei der Masse an Material nicht die Zeit, alles durchzuschaun.

[ive beaten tetris]

gebookmarkt! gut gemacht und wieder hast du verhindert dass ich nach solchen inhalten erst googeln muss ^^

[The Best Isaac]

Hab mir jetzt auch mal die Zeit genommen, den kompletten Artikel durchzulesen. Ist ja nicht ganz wenig. ^^
Auf jeden Fall hat er mir sehr gut gefallen. Gut geschrieben und genauso informativ wie deine anderen Artikel.
Da ich mich sowieso mal mit diesem Thema auseinandersetzen wollte, hast du mir echt geholfen. =)
Könntest du mir vielleicht einen Tipp geben, welche Spezifikation man verwenden sollte? HTML 4.01 in der Strict-Variante ist ja glaube ich immer noch eine gute Wahl, soweit ich das jetzt aus deinen Artikeln herauslesen konnte.

Bleibt mir eigentlich nurnoch zu sagen, dass ich auf weitere gute Artikel von dir gespannt bin. ^^

[mitaki]

Schön zu Wissen, dass der Text dem ein und anderen hilfreich erscheint

Könntest du mir vielleicht einen Tipp geben, welche Spezifikation man verwenden sollte? HTML 4.01 in der Strict-Variante ist ja glaube ich immer noch eine gute Wahl, soweit ich das jetzt aus deinen Artikeln herauslesen konnte.

...

Ja, HTML 4.01 Strict ist die Wahl fürs Web! Allerdings dazu ein paar Hinweise von mir.

• Wenn du das start-Attribut im ol-Element oder das value-Attribut des li-Elements benötigst: Verwende Strict, obwohl es nicht konform ist. Die beiden Attribute können durchaus von Bedeutung für den Inhalt sein. Aber deswegen einen schlechteren Darstellungsmodus im Browser zu aktivieren lohnt sich nicht.
• In Strict dürfen Inline-Elemente nicht lose stehen sondern müssen in Blockelementen stehen. Verwende dazu bitte nicht das div-Element. Das wäre nichts anderes als Tabellen für das Layot zu missbrauchen.
• Verwende David Hammonds Good Practice Checker, damit wird der Quelltext gegen eine strengere DTD geprüft und Spielereien wie optionale Endtags fallen weg. Die Unterschiede zur normalen DTD kann man in einem Blog-Eintrag nachlesen.
  Ich selbst würde aber wieder gegen den letzten Punkt verstoßen, die richtige Zeichenkodierung für HTML zu setzen ist kein Problem (Zum HTTP-Header passende Metaangabe als erstes Kind des head-Elements). Auch das b- und das i-Element würde ich in der Not gelten lassen (span@class=bold ist nicht wirklich besser).

Hammonds Werkzeug erkennt nicht alle möglichen Fehler, aber einen Großteil. Wer auf die drakonische Fehlertoleranz von XML nicht verzichten möchte sollte meiner Meiung nach die Inhalte als XML speichern, diese aber in HTML umtransformieren, bevor diese den Browser erreichen. Das beste aus beiden Varianten nehmen also

[Teelicht]

In Strict dürfen Inline-Elemente nicht lose stehen sondern müssen in Blockelementen stehen. Verwende dazu bitte nicht das div-Element. Das wäre nichts anderes als Tabellen für das Layot zu missbrauchen.

...

Was soll man denn sonst verwenden? Ok, dass man für ein Menü z.b. Listen verwendet, ist klar, aber einen Header? Oder wenn man eine Zentrierte Box haben will, die in zwei Spalten unterteilt wird? Für sowas braucht man schon mal 3 oder mehr Divs, wie willst du es denn anders realisieren?

Auch das b- und das i-Element würde ich in der Not gelten lassen (span@class=bold ist nicht wirklich besser).

...

Man kann ja statt <b> beispielsweise auch <strong> nehmen, das wäre sowieso besser. Ob man <i> durch <em> ersetzen sollte, weiß ich gerade nicht, da ich die Bedeutung von <em> jetzt nicht auswendig weiß - von der Anzeige her sollte es zumindest klappen (und ist <em> nicht für betonte Textteile? Dann wäre es funktionell gesehen auch richtig!)

[mitaki]

Was soll man denn sonst verwenden? Ok, dass man für ein Menü z.b. Listen verwendet, ist klar, aber einen Header? Oder wenn man eine Zentrierte Box haben will, die in zwei Spalten unterteilt wird? Für sowas braucht man schon mal 3 oder mehr Divs, wie willst du es denn anders realisieren?

...

Glaube hier hast du mich falsch verstanden.

In Strict ist nicht erlaubt, dass Inlineelemente lose herumstehen, z.B im body-Element. Nun könnte man mit dem div-Element eine Brücke bauen...

HTML-Code:

<body>
 <div>
  <inlinelement>

Das verändert aber die Bedeutung nicht bzw. dichtet dem div-Element ein unpassende Bedeutung zu.

Das div-Element dient zur Gruppierung mehrerer Elemente, aber nicht um Inlinelemente dort zu erlauben, wo sie eigentlich nicht hingehören. Das hat mit der Zugänglichkeit usw. zu tun.
Die von dir genannten Fälle scheinen diese Regel nicht zu brechen und sind daher natürlich erlaubt.

Man kann ja statt <b> beispielsweise auch <strong> nehmen, das wäre sowieso besser. Ob man <i> durch <em> ersetzen sollte, weiß ich gerade nicht, da ich die Bedeutung von <em> jetzt nicht auswendig weiß - von der Anzeige her sollte es zumindest klappen (und ist <em> nicht für betonte Textteile? Dann wäre es funktionell gesehen auch richtig!)

...

Das kann man grundsätzlich nicht sagen und muss im Einzelfall entschieden werden. Daher wurden diese 4 Elemente in HTML 5 neu definiert bzw. ihre Bedeutung verändert.

<b> und <i> stellen nun Satzteile/Namen/etc. dar, die in der Regel mit dieser Formatierung geschrieben werden. Beispielsweise eine andere Stimmlage bei <i> oder Produktnamen für <b>.
<em> steht zwar weiterhin für Betonung, allerdings wird diese betonung nicht durch <strong> verstärkt sondern durch verschachtelte <em>. Je mehr <em> umso stärker die Betonung.
<strong> dagegen wird für wichtige Abschnitte verwendet, wozu beispielsweise aus Wörter wie „Achtung“ und „Fehler“ gehören.

[Teelicht]

Glaube hier hast du mich falsch verstanden.

...

Ja, stimmt - jetzt verstehe ich, was du gemeint hast. :-)

<b> und <i> stellen nun Satzteile/Namen/etc. dar, die in der Regel mit dieser Formatierung geschrieben werden. Beispielsweise eine andere Stimmlage bei <i> oder Produktnamen für <b>.
<em> steht zwar weiterhin für Betonung, allerdings wird diese betonung nicht durch <strong> verstärkt sondern durch verschachtelte <em>. Je mehr <em> umso stärker die Betonung.
<strong> dagegen wird für wichtige Abschnitte verwendet, wozu beispielsweise aus Wörter wie „Achtung“ und „Fehler“ gehören.

...

Ich nehme an, bei der Umsetzung der Regeln ist das aber noch nicht durchgedrungen, oder? Systeme für Sprachausgabe interpretieren kein <b> und <i>, oder irre ich mich da?

[mitaki]

Ich nehme an, bei der Umsetzung der Regeln ist das aber noch nicht durchgedrungen, oder? Systeme für Sprachausgabe interpretieren kein <b> und <i>, oder irre ich mich da?

...

Das einzige, das ich hier weis ist, dass z.B. Lynx <b> und <i> ebeneso farbig darstellt wie <em> und <strong>. Bei der Anzahl der verwendeten Elemente würde es mich aber nicht wundern, wenn Sprachbrowser sich hier ebenfalls schon angepasst hätten.