Der DOCTYPE-Modusauswahlmechanismus bekannter Browser

Dokumentumfang

Dieser Artikel behandelt den Moduswechsel für Firefox und andere Gecko-basierte Browser, Safari, Chrome und andere Webkit-basierte Browser, Opera, Konqueror, Internet Explorer für Mac, Internet Explorer für Windows und den eingebetteten IE-Browser. Vermeiden Sie die Erwähnung des Namens der Browser-Engine. Nennen Sie stattdessen den Namen des bekanntesten Browsers, der diese Engine verwendet.

Dieser Artikel konzentriert sich auf den Mechanismus der Modusauswahl und nicht auf die Dokumentation des genauen Verhaltens jedes Modus.

Modell

Die verschiedenen Modi sind:

Modus mit Inhaltstyp Text/HTML

Die Modusauswahl für Text-/HTML-Inhalte basiert auf Doctype-Sniffing (wird später in diesem Artikel besprochen). Im IE8 hängt der Modus auch von anderen Faktoren ab. Allerdings ist in IE8 der Modus für Nicht-Intranet-Sites, die nicht auf der von Microsoft bereitgestellten Blacklist stehen, standardmäßig vom Dokumenttyp abhängig.

Es kann nicht genug betont werden, dass das genaue Verhalten der Modi von Browser zu Browser unterschiedlich ist, auch wenn sie in diesem Artikel einheitlich besprochen werden.

Quirks-Modus

Im Quirks-Modus verletzen Browser moderne Web-Formatierungskonventionen, um ein „Beschädigen“ von Seiten zu vermeiden, die nach den in den späten 1990er Jahren beliebten Methoden erstellt wurden. Verschiedene Browser implementieren unterschiedliche Eigenheiten in ihrem Verhalten. In Internet Explorer 6, 7 und 8 ist der Quirks-Modus in IE 5.5 effektiv eingefroren. In anderen Browsern ist der Quirks-Modus eine kleine Abweichung vom Standardmodus.

Wenn Sie neue Seiten erstellen, sollten Sie die entsprechenden Spezifikationen (insbesondere CSS 2.1) einhalten und den Standardmodus verwenden.

Standards-Modus

Im Standardsmodus versucht der Browser, standardkonforme Dokumente spezifikationsgerecht zu verarbeiten, soweit dies im jeweiligen Browser möglich ist.

Verschiedene Browser durchlaufen unterschiedliche Phasen, der Standardmodus ist also kein einheitliches Ziel.

HTML5 nennt diesen Modus „No Quirks-Modus“

Fast-Standardmodus

Safari, Chrome, Opera (ab 7.5) und IE8 verfügen außerdem über einen Modus namens „Quasi-Standardmodus“, der die vertikale Größe von Tabellenzellen nach herkömmlichen Verfahren implementiert, anstatt sich strikt an die CSS2-Spezifikation zu halten. Mac IE5, Windows IE6 und 7, Opera vor 7.5 und Konqueror erfordern keinen Near-Standards-Modus, da sie der CSS2-Spezifikation für die vertikale Größenanpassung von Tabellenzellen zumindest in ihren jeweiligen Standardmodi nicht strikt folgen. Tatsächlich ähnelt ihr Standardmodus eher dem Semistandardmodus von Mozilla als dem Standardmodus von Mozilla.

HTML5 nennt diesen Modus „Modus mit eingeschränkten Eigenheiten“.

IE7-Modus

IE8 verfügt über einen Modus, der im Wesentlichen eine Kopie des Standardmodus von IE7 einfriert. Andere Browser haben keinen solchen Modus und er ist in HTML5 nicht spezifiziert.

Modus mit Inhaltstyp application/xhtml+xml (XML-Modus)

In Firefox, Safari, Chrome und Opera löst der HTTP-Inhaltstyp application/xhtml+xml (nicht das Metaelement oder der Doctype!) den XML-Modus aus. Im XML-Modus versuchen Browser, XML-Dokumente spezifikationsgerecht zu verarbeiten, soweit dies im jeweiligen Browser möglich ist.

IE6, 7 und 8 unterstützen application/xhtml+xml nicht, ebenso wenig wie Mac IE5.

Im WebKit-basierten Nokia S60-Browser löst der HTTP-Inhaltstyp application/xhtml+xml den XML-Modus nicht aus, da der Schwerpunkt in mobilen Walled Gardens auf der Kompatibilität mit nicht standardmäßigen Inhalten liegt. (Ältere „mobile Browser“ können keinen echten XML-Parser verwenden, da der nicht standardmäßige Inhalt als XML gekennzeichnet ist.)

Ohne Konqueror vollständig getestet zu haben, kann ich nicht genau sagen, was in diesem Browser passieren wird.

Nicht-Web-Modi

Einige Engines haben Modi, die nichts mit Webinhalten zu tun haben. Sie werden hier nur der Vollständigkeit halber erwähnt. Opera hat einen WML2.0-Modus. WebKit unter Leopard verfügt über einen speziellen Modus für ältere Dashboard-Widgets.

Beeinflussen

Dies sind die wichtigsten Auswirkungen dieser Modi:

Layout

Der Text/HTML-Modus beeinflusst hauptsächlich das CSS-Layout. Beispielsweise ist es eine Eigenart, dass Tabellen keine Stile erben. Im Quirks-Modus einiger Browser wird das Box-Modell zum IE5.5-Box-Modell. In diesem Dokument werden nicht alle Layout-Eigenheiten aufgeführt.

Im Semistandardmodus (in Browsern, die über einen solchen Modus verfügen) ist die Höhe von Tabellenzellen, die nur Bilder enthalten, anders als im Standardmodus.

Im XML-Schema weisen Selektoren unterschiedliche Verhaltensweisen hinsichtlich der Groß- und Kleinschreibung auf. Darüber hinaus gelten bestimmte Regeln für das HTML-Body-Element nicht für ältere Browser, in denen die neuesten CSS 2.1-Änderungen nicht implementiert wurden.

Analyse

Es gibt auch einige Macken, die sich auf die Analyse von HTML und CSS auswirken und dazu führen können, dass standardkonforme Webseiten falsch analysiert werden. Das Macken-Layout bestimmt, ob diese Macken ein- oder ausgeschaltet sind. Unabhängig davon ist es wichtig, die wichtigsten Ähnlichkeiten und Unterschiede zwischen dem Quirks-Modus und dem Standardmodus in Bezug auf CSS-Layout und -Analyse (nicht HTML-Analyse) zu verstehen.

Manche Leute bezeichnen den Standardmodus fälschlicherweise als „strikten Analysemodus“, was den Browser dazu verleitet, die HTML-Syntaxregeln durchzusetzen und die Korrektheit der Auszeichnung zu überprüfen. Das ist nicht der Fall. Auch wenn das Layout im Standardmodus aktiviert ist, führen Browser weiterhin Korrekturen an Tag-Soup (http://en.wikipedia.org/wiki/Tag_soup) durch. (Vor der Veröffentlichung von Netscape 6 im Jahr 2000 verfügte Mozilla über Parsing-Modi zur Durchsetzung der HTML-Syntaxregeln. Diese Modi wurden als mit vorhandenen Webinhalten nicht kompatibel abgelehnt.)

Ein weiteres häufiges Missverständnis betrifft die XHTML-Analyse. Es wird allgemein angenommen, dass die Verwendung des XHTML-Dokumenttyps zu einer anderen Analyse führt. Tatsächlich ist dies nicht der Fall. XHTML-Dokumente mit dem Inhaltstyp text/html verwenden denselben Parser wie HTML-Dokumente. Derzeit berücksichtigen Browser, dass XHTML mit einem Dokumenttyp vom Typ „Text/HTML“ lediglich eine „Tag-Suppe mit Croutons“ (mit zusätzlichen Schrägstrichen hier und da) ist.

Nur Dokumente, die den XML-Dokumenttyp verwenden (z. B. application/xhtml+xml oder xmapplication/), lösen den XML-Modus zum Parsen aus, und der Parser zu diesem Zeitpunkt unterscheidet sich völlig vom HTML-Parser.

Skript

Während es im Quirks-Modus hauptsächlich um CSS geht, gibt es auch einige Dinge zum Thema Skripting. Beispielsweise erstellen HTML-ID-Attribute im Firefox-Quirks-Modus Objektreferenzen im globalen Skriptbereich, genau wie im Internet Explorer. Die Auswirkungen von Skripting sind im IE8 stärker ausgeprägt als in anderen Browsern.

Im XML-Modus verhalten sich einige DOM-APIs völlig anders, da das DOM-API-Verhalten für XML als inkompatibel mit dem Verhalten für HTML definiert wurde.

Doctype-Sniffing (auch Doctype-Konvertierung genannt)

Moderne Browser verwenden Doctype-Sniffing, um den Engine-Modus für Text-/HTML-Dokumente zu bestimmen. Dies bedeutet, dass die Wahl des Modus auf der Dokumenttypdeklaration (oder dem Fehlen einer solchen) am Anfang des HTML-Dokuments basiert. (Dies gilt nicht für Dokumente, die den XML-Dokumenttyp verwenden.)

Die Dokumenttypdeklaration (Doctype) ist eine syntaktische Fälschung von SGML, dem alten Markup-Framework, anhand dessen HTML vor HTML5 definiert wurde. In der HTML4.01-Spezifikation beschreibt die Dokumenttypdeklaration die Versionsinformationen von HTML. Trotz des Namens „Dokumenttypdeklaration“ und trotz der Beschreibung der „Versionsinformationen“ in der HTML 4.01-Spezifikation ist mit der Dokumenttypdeklaration nicht beabsichtigt, ein SGML- oder XML-Dokument als einen bestimmten Dokumenttyp zu klassifizieren, selbst wenn es (aufgrund des Namens) so aussieht. (Mehr im Anhang)

Weder die HTML 4.01-Spezifikation noch ISO 8879 (SGML) sagen etwas über die Verwendung von Dokumenttypdeklarationen als Engine-Modusschalter aus. Doctype Sniffing basiert auf der Beobachtung, dass zum Zeitpunkt der Entwicklung von Doctype Sniffing die überwiegende Mehrheit der Quirks-Dokumente weder eine Dokumenttypdeklaration noch einen Verweis auf eine alte DTD hatte. HTML5 akzeptiert diese Tatsache und definiert den Dokumenttyp „Text/HTML“ als einzigen Modusschalter.

Eine typische Dokumenttypdeklaration vor HTML5 enthält (durch Leerzeichen getrennt) die Zeichenfolge „<!DOCTYPE“, den universellen Bezeichner des Stammelements („html“), die Zeichenfolge „PUBLIC“, den öffentlichen Bezeichner der DTD in Anführungszeichen, einen möglichen Systembezeichner (URL) derselben DTD und das Zeichen ">". Die Dokumenttypdeklaration wird vor dem Starttag des Stammelements des Dokuments platziert.

Dokumenttyp auswählen

text/html

Hier ist eine einfache Anleitung zum Auswählen eines Dokumenttyps beim Erstellen eines neuen Text-/HTML-Dokuments:

Standardmodus, modernste Verifizierung

<!DOCTYPE html>

Dies ist das Richtige, wenn Sie neue Funktionen wie <video> , <canvas> und ARIA validieren möchten. Beachten Sie, dass sich die gültige HTML5-Definition noch im Wandel befindet. Testen Sie daher unbedingt die Bildausrichtung in Firefox, Safari, Chrome, Opera 9 oder Opera 10. Es reicht nicht aus, die Bildausrichtung im Internet Explorer zu testen. Testen Sie sie unbedingt auch in IE8.

Standardmodus, ein stabileres Überprüfungsziel

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

Dieser Dokumenttyp löst auch den Standardmodus aus und die 10 Jahre alte gültige HTML 4.01-Definition ist stabil. Testen Sie die Bildausrichtung unbedingt in Firefox, Safari, Chrome, Opera 9 oder Opera 10. Es reicht nicht aus, die Bildausrichtung im Internet Explorer zu testen. Testen Sie sie unbedingt auch in IE8.

Sie möchten den Standardmodus verwenden, aber dennoch veraltetes Markup überprüfen oder aufgeteilte Bilder in Tabellenlayouts verwenden und diese nicht korrigieren.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

Dadurch wird der Near-Standards-Modus (und der alte vollständige Standards-Modus von Mozilla) ausgelöst. Beachten Sie, dass Layouts, die auf geschnittenen Bildern basieren und mit Tabellen implementiert werden, bei einer späteren Portierung auf HTML5 möglicherweise nicht mehr funktionieren (dies gilt auch für den vollständigen Standardmodus).

Den Quirks-Modus bewusst nutzen

Kein Dokumenttyp.

Bitte tun Sie das nicht. Das bewusste Designen für den Quirks-Modus wird Ihnen in Zukunft zum Verhängnis werden, wenn sich Ihre Kollegen oder Nachfolger nicht einmal mehr für Windows IE6 interessieren (Netscape 4.x und IE5 interessierten niemanden mehr). Das Entwerfen für den Quirks-Modus ist eine schlechte Idee. Glauben Sie mir.

Wenn Sie Windows IE6 weiterhin unterstützen möchten, ist es besser, einen speziellen Hack mit bedingten Kommentaren dafür zu erstellen, als andere Browser in den Quirks-Modus zurückzuversetzen.

Ich empfehle keinen XHTML-Dokumenttyp, da die Verwendung von XHTML als schädlich gilt. Unabhängig davon, ob Sie den XHTML-Dokumenttyp verwenden, beachten Sie bitte, dass die XML-Deklaration dazu führt, dass IE6 (aber nicht IE7!) den Quirks-Modus auslöst.

Anwendung/xhtml+xml

Eine einfache Richtlinie für application/xhtml+xml besteht darin, niemals Doctype zu verwenden. Die Webseiten in diesem Modus sind nicht „streng konform“ mit XHTML1.0, aber das ist nicht wichtig. (Bitte beachten Sie den Anhang unten)

IE8-Komplikationen

A List Apart hat einmal eingeführt, dass IE8 zusätzlich zum Doctype Modusübergänge basierend auf Metaelementen als einen der Faktoren für die Modusauswahl verwenden wird. (Siehe Kommentare von Ian Hickson, David Baron, nochmals David Baron, Robert O'Callahan und Maciej Stachowiak.)

IE8 hat 4 Modi: IE5.5-Quirks-Modus, IE7-Standards-Modus, IE8-Semi-Standards-Modus und IE8-Standards-Modus. Der gewählte Modus basiert auf Daten aus mehreren Quellen: Dokumenttyp, Metaelemente, HTTP-Header, regelmäßig heruntergeladene Daten von Microsoft, die LAN-Domäne, vom Benutzer vorgenommene Einstellungen, vom LAN-Administrator vorgenommene Einstellungen, der Modus des übergeordneten Frames (sofern vorhanden) und ob die Schaltfläche „Kompatibilitätsansicht“ in der Adressleiste vom Benutzer ausgelöst wird. (Bei anderen Anwendungen, in die die Engine eingebettet ist, hängt der Modus auch von der eingebetteten Anwendung ab.)

Glücklicherweise verwendet IE8 Doctype-Sniffing größtenteils wie andere Browser, wenn die folgenden Bedingungen erfüllt sind:

• Der Autor hat den X-UA-kompatiblen HTTP-Header nicht gesetzt
• Der Autor hat das X-UA-kompatible Meta-Tag nicht gesetzt
• Microsoft hat den Domänennamen der Site nicht auf eine schwarze Liste gesetzt
• Der LAN-Administrator hat die Site nicht auf die schwarze Liste gesetzt
• Der Benutzer hat die Schaltfläche „Kompatibilitätsansicht“ nicht gedrückt (oder wurde anderweitig zu einer bestimmten Benutzer-Blacklist hinzugefügt).
• Die Site befindet sich nicht in der Domäne des lokalen Netzwerks
• Der Benutzer hat nicht ausgewählt, alle Websites in IE7 anzuzeigen.
• Die Seite ist nicht über einen Frame in eine Seite im kompatiblen Modus eingebettet

IE8 führt Doctype-Sniffing genauso durch wie IE7, mit Ausnahme der beiden oben bezüglich X-UA-Compatible genannten Fälle. Die IE7-Emulation wird als Kompatibilitätsansicht bezeichnet.

Im Fall von X-UA-Compatible verhält sich IE8 völlig anders als andere Browser. Möchten Sie den Anhang dieser Seite oder das Flussdiagramm im PDF- und PNG-Format sehen?

Ohne den X-UA-kompatiblen HTTP-Header oder Meta-Tag ermöglicht IE8 den Benutzern leider, Seiten versehentlich vom IE8-Standardmodus in den IE7-Modus herunterzustufen, bei dem es sich um einen emulierten IE7-Standardmodus handelt, selbst wenn der entsprechende Dokumenttyp verwendet wird. Schlimmer noch: LAN-Administratoren können dasselbe tun. Microsoft kann auch alle von Ihnen verwendeten Domänen auf eine schwarze Liste setzen.

Um diesen Effekten entgegenzuwirken, reicht der Doctype nicht aus; Sie benötigen den X-UA-kompatiblen HTTP-Header und das Meta-Tag.

Nachfolgend finden Sie eine einfache Anleitung zum Auswählen des X-UA-kompatiblen HTTP-Headers oder Meta-Tags für neue Text-/HTML-Dokumente, die bereits über einen Dokumenttyp verfügen, der in anderen Browsern den Standardmodus oder nahezu den Standardmodus auslöst:

Ihre Domäne befindet sich nicht auf der schwarzen Liste von Microsoft und Ihnen ist die Vermeidung browserspezifischer Belästigungen wichtiger als die Gewährleistung, dass Benutzer nicht auf das Verhalten von IE7 zurückgreifen können.

Sie müssen den X-UA-kompatiblen HTTP-Header oder Meta-Tag nicht einschließen.

Ihre Domain steht auf der schwarzen Liste von Microsoft, weil andere Autoren Ihrer Domain Websites beschädigt haben, die möglicherweise dazu geführt haben, dass Benutzer die Kompatibilitätsansicht für die gesamte Domain aktiviert haben. Sie befürchten, dass Google oder Digg Ihre Site rahmen, oder Sie möchten sicherstellen, dass Benutzer die Kompatibilitätsansicht nicht verwenden können.

Fügen Sie zunächst das folgende Meta-Element in Ihre Seite ein (es ist in HTML5 nicht zulässig) <meta http-equiv="X-UA-Compatible" content="IE=Edge"> (vor allen Skriptelementen) oder setzen Sie den folgenden HTTP-Header: X-UA-Compatible: IE=Edge

Ihre Site funktioniert in IE7, bricht aber in IE8 ab

Fügen Sie zunächst das folgende Metaelement in Ihre Seite ein (in HTML5 ist es nicht zulässig): (vor jeglichen Skriptelementen) oder legen Sie den folgenden HTTP-Header fest: X-UA-Compatible: IE=EmulateIE7. Korrigieren Sie dann Ihre Site, sodass sie nicht auf nicht standardmäßiges IE7-Verhalten angewiesen ist, und migrieren Sie zu IE=Edge.

Weiterführende Links

• Eric Meyer schreibt über den Mac IE5-Modus in Using the Correct Doctype
• Mozillas Doctype Sniffing von David Baron
• Lance Silver bespricht Modi und Doctype-Sniffing in Windows IE6 in CSS-Erweiterungen in IE6.
• Opera9 Doctype-Konvertierung
• Faruk Ateş's Lösung für IE8 und X-UA-Kompatibilität

Nachtrag: Ein Appell an XML-Implementierer und Spezifikationsautoren

Bitte bringen Sie kein Doctype-Sniffing in XML ein.

Doctype-Sniffing ist eine Tag-Soup-Lösung für ein Tag-Soup-Problem. Doctype Sniffing ist eine Heuristik, die nach der Veröffentlichung der HTML4- und CSS2-Spezifikationen entwickelt wurde, um veraltete Dokumente von Dokumenten zu unterscheiden, die dem von ihren Autoren erwarteten Verhalten entsprechen.

Gelegentlich wurde vorgeschlagen, Doctype-Sniffing auf XML anzuwenden, um unterschiedliche Verarbeitungen zu planen, das verwendete Vokabular zu ermitteln oder Funktionen zu aktivieren. Das ist eine schlechte Idee. Die Disposition und Vokabularidentifizierung sollten Namespace-basiert sein, während die Funktionsaktivierung auf expliziten Verarbeitungsanweisungen oder Elementen basieren sollte.

Die gesamte Idee der Wohlgeformtheit wurde eingeführt, um eine DTD-lose Analyse von XML zu ermöglichen und Doctype-lose Dokumente zu fördern. Im formellen Fall gilt: Wenn zwei XML-Dokumente die gleiche kanonische Form haben und von einer Anwendung unterschiedlich verarbeitet werden (und der Unterschied nicht auf einen Mangel an Auswahlmöglichkeiten bei der Verarbeitung externer Entitäten zurückzuführen ist), kann die Anwendung beschädigt werden. Wenn in der Praxis zwei XML-Dokumente dazu führen, dass der gleiche Inhalt an einen SAX2-Inhaltsprozessor gemeldet wird (qnames werden ignoriert), eine Anwendung die Dokumente jedoch unterschiedlich verarbeitet, ist die Anwendung wahrscheinlich defekt. Da Sie als Webautor nicht darauf vertrauen können, dass jeder seine Seiten mit einem XML-Prozessor analysiert, der zusätzliche Entitäten auflöst (selbst wenn es bei einigen Browsern so aussieht, als ob sie dies tun, weil sie bestimmte allgemeine Bezeichner einer verkürzten DTD zuordnen, die die Entitäten definiert), ist das Einfügen eines Doctypes in XML für das Web sinnlos und führt normalerweise zu Cargo-Kult-Gewohnheiten. (Sie können mit der DTD-Override-Funktion des W3C-Validators immer noch eine Validierung anhand einer DTD durchführen, obwohl der W3C-Validator angibt, dass das Ergebnis nur vorläufig gültig ist. Oder noch besser: Sie können eine entspannte NG-Validierung verwenden, die das Dokument nicht mit Schemaverweisen verunreinigt.) Die Anforderung eines Doctypes zum Zwecke des Sniffings ist ziemlich albern, auch wenn dies in der HTML-Praxis der richtige Weg ist.

Wenn eine Spezifikation auf niedriger Ebene zwei Dinge als gleich definiert, sollte eine Spezifikation auf hoher Ebene außerdem nicht versuchen, ihnen unterschiedliche Bedeutungen zu geben. Erwägen Sie <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> . Wenn der öffentliche Bezeichner entfernt wird, wird immer noch dieselbe DTD angegeben, sodass der Dokumenttyp <!DOCTYPE html SYSTEM "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> dasselbe bedeutet wie der vorherige Dokumenttyp. Sollten sie anders beschnüffelt werden? Die Theorie lässt sich noch weiter ausbauen. Angenommen, example.com erhält eine DTD namens foobar.dtd: <!DOCTYPE html SYSTEM "http://example.com/foobar.dtd"> . Wie kann man das riechen? Es sollte dasselbe bedeuten. Sogar die gesamte DTD kann in das Dokument eingefügt werden.

Mit anderen Worten, wenn Sie #include "foo.h" haben, sollten Sie keine schwarze Magie auf den Namen foo.h anwenden, weil es möglich sein sollte, den Inhalt von foo.h in das Dokument zu kopieren oder foo.h in bar.h zu kopieren und #include "bar.h" zu sagen.

Der Grund, weshalb ich mir keine Sorgen darüber mache, dass HTML und SGML die gleichen Parameter konstruieren, liegt darin, dass Webbrowser keinen echten SGML-Parser zum Parsen von HTML verwenden. Daher halte ich es für sinnlos, so zu tun, als sei es SGML. Wenn Sie immer noch nicht überzeugt sind, lesen Sie W. Eliot Kimbers Artikel zu diesem Thema comp.text.sgml

Anhang: Umgang mit einigen Doctypes in Text/HTML

In der folgenden Tabelle werden der Quirks-Modus, der Standard-Modus und der Semi-Standard jeweils als Q, S und A bezeichnet. Wenn der Browser nur über zwei Modi verfügt, wird der Standardmodus als „S“ gekennzeichnet, wenn sich die Zeilenhöhe der Tabellenzellen wie im Standardmodus von Mozilla verhält, und als „A“, wenn sich die Zeilenhöhe der Tabellenzellen wie im Semistandardmodus von Mozilla verhält.

Beachten Sie, dass XHTML, das unter Verwendung des XML-Inhaltsmodells bereitgestellt wird, im XML-Modus gerendert wird.

Der Zweck dieser Tabelle besteht nicht darin, zu behaupten, dass alle Dokumenttypen in der Tabelle eine sinnvolle Wahl für neue Seiten darstellen. Der Zweck dieser Tabelle besteht darin, anzuzeigen, auf welchen Daten meine Empfehlungen basieren.

Für Spaltenüberschriften werden folgende Abkürzungen verwendet:

NS6

Mozilla 0.6…0.9.4 und Netscape 6.0…6.2.3

Alter Moz

Mozilla 0.9.5 bis 1.1 Alpha und Mozilla 1.0

Moz & Safari & Opera 10 & HTML5

Mozilla 1.0.1, Mozilla 1.1 Beta und höher, Firefox bis Netscape 7, Safari 0.9 bis Safari 4.0 Beta, Opera 10, Chrome, Konqueror 3.5, HTML5-spezifisches Verhalten

Oper 9.0

Opera 9.0…9.20

IE 8 und Opera 9.5

Standard-IE8 ohne X-UA-Kompatibilität und Kompatibilitätsmodus-Overrides („A“ bedeutet in diesem Fall IE8-Nahstandardmodus), Opera 7.5…8.54 und 9.5…9.6

IE 7 und Opera 7.10

IE7, IE8 im Kompatibilitätsmodus ohne X-UA-Compatible-Override (in diesem Fall steht „A“ für den IE7-Modus) und Opera 7.10…7.23

IE 6 und Opera 7.0

Windows IE 6 und Opera 7.0…7.03

Mac IE 5

Mac IE 5.0…5.2.3

Konq 3.2

Konqueror 3.2.2…3.3 (und möglicherweise 3.1…3.2.1; ich habe es noch nicht bestätigt)

Geschichte

Der Doctype-Sniffing-Code von Moziila wurde im Oktober 2000, September 2001 und Juni 2002 erheblich geändert. Dieses Dokument beschreibt den Status der unter ftp.mozilla.org verfügbaren Builds von Mozilla (und Netscape 6.x) vom 19.10.2000. Dieses Dokument behandelt nicht die Funktionsweise von Doctype-Sniffing in Mozilla M18 (und Netscape 6.0 PR3). Auch der Doctype-Sniffing-Code von Safari wurde seit der ersten öffentlichen Betaversion erheblich geändert. Dieses Dokument behandelt kein Verhalten vor Version V73, auch bekannt als 0.9.

Der Doctype-Sniffing-Code in Konqueror vor 3.5 scheint aus einer sehr alten Version von Safari zu stammen. Konqueror entspricht jetzt Safari, mit Doctype-Sniffing-Code von Mozilla.

Wie aus der Tabelle ersichtlich, verändert sich das Doctype-Sniffing von Opera von eher IE-ähnlich zu eher Mozilla-ähnlich, obwohl Opera 9.5 und 9.6 auf dem Rückweg sind. Gleichzeitig wurde das Layoutverhalten des Quirks-Modus von Opera von der Emulation des Quirks-Modus von IE6 auf den Quirks-Modus von Mozilla umgestellt.

Anhang: IE8-Modusauswahl

Erste Schritte: Gehen Sie zu „X-UA-kompatible Meta?“

X-UA-kompatibles Meta?

IE=7: IE7-Standards verwenden

IE=EmulateIE7: Geben Sie „Macken oder kein Doctype? (Kompatibilitätsmodus)“ ein.

IE=IE8 oder IE=IE7 oder IE=a oder IE=EmulateIE8 oder nein oder Skript erscheint zuerst: Geben Sie „X-UA-kompatibler HTTP-Header?“ ein.

IE=8 oder IE=Edge oder IE=99 oder IE=9.9: „Near-Standards-Modus“ aufrufen?

IE=5: Quirks-Modus verwenden (IE5.5)

X-UA-kompatibler HTTP-Header?

IE=7: IE7-Standardmodus verwenden

IE=EmulateIE7: Gehe zu „Macken oder kein Doctype? (Kompatibilitätsmodus)“

IE=IE8 oder IE=IE7 oder IE=a oder IE=EmulateIE8 oder Keine: Gehen Sie zu „Alle Sites anzeigen … Vorgabe?“

IE=8 oder IE=Edge oder IE=99 oder IE=9.9: „Near-Standards-Modus“ aufrufen?

IE=5: Quirks-Modus verwenden (IE5.5)

Quirks-Modus oder kein Doctype? (Kompatibilitätsmodus)

Ja: Quirks-Modus verwenden (IE5.5)

Nein: IE7-Standardmodus verwenden

Alle Sites anzeigen...voreingestellt?

Ja: Geben Sie „Quirks-Modus oder kein Doctype? (Kompatibilitätsmodus)“ ein.

Nein: Gehen Sie zu „LAN-Sites anzeigen … voreingestellt?“

LAN-Sites anzeigen … voreingestellt?

Ja: Gehen Sie zu „Befindet sich die Site in einer LAN-Domäne?“

Nein: Gehen Sie zu „Steht der Domänenname auf einer von Microsoft geführten Liste?“

Befindet sich die Domäne auf einer von Microsoft geführten Liste?

Ja: Geben Sie „Quirks-Modus oder kein Doctype? (Kompatibilitätsmodus)“ ein.

Nein: Gehen Sie zu „Durch eine kompatible Modusseite mithilfe eines Frames eingebettet?“

Eingebettet von einer kompatiblen Modusseite mithilfe eines Frames?

Ja: Geben Sie „Quirks-Modus oder kein Doctype? (Kompatibilitätsmodus)“ ein.

Nein: Gehe zu „Kompatibilitätsmodus-Taste gedrückt?“

Kompatibilitätsmodus-Taste gedrückt?

Ja: Geben Sie „Quirks-Modus oder kein Doctype? (Kompatibilitätsmodus)“ ein.

Nein: Geben Sie „Quirks-Modus oder kein Doctype? (IE8)“ ein.

Quirks-Modus oder kein Doctype? (IE8)

Ja: Geben Sie „Quirks-Modus verwenden (IE5.5)“ ein.

Nein: In den „Quasi-Standardmodus“ wechseln?

Ein Quasi-Standardmodell?

Ja: IE8-Halbstandardmodus verwenden

Nein: IE8-Standardmodus verwenden

Diese Schritte sind als Flussdiagramme in den Formaten PDF und PNG verfügbar.

Danksagung

Ich danke Simon Pieters, Simon Pieters und Anne van Kesteren für ihre Hilfe beim Korrigieren der Modustabellen für verschiedene Opera-Versionen und für ihre Kommentare. Danke an Simon Pieters für ein weiteres IE8-Flussdiagramm.