Die in diesem Artikel enthaltene Modusumschaltung gilt 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 eingebettete IE-Browser. Vermeiden Sie die Nennung des Namens der Browser-Engine und nennen Sie stattdessen den Namen des bekanntesten Browsers, der diese Engine verwendet.
Dieser Artikel konzentriert sich auf den Modusauswahlmechanismus und nicht auf die Dokumentation des genauen Verhaltens jedes Modus.
Hier sind die verschiedenen Modi:
Die Modusauswahl für Text-/HTML-Inhalte hängt vom Doctype-Sniffing ab (wird später in diesem Artikel besprochen). Im IE8 hängt der Modus auch von anderen Faktoren ab. Allerdings hängt der Modus für Nicht-Intranet-Sites, die nicht auf der Blacklist von Microsoft stehen, im IE8 standardmäßig vom Dokumenttyp ab.
Es kann nicht genug betont werden, dass das genaue Verhalten von Mustern in jedem Browser unterschiedlich ist, auch wenn es in diesem Artikel einheitlich besprochen wird.
In Firefox, Safari, Chrome und Opera löst der XML-HTTP-Inhaltstyp application/xhtml (kein Metaelement und kein Doctype!) den XML-Modus aus. Im XML-Modus versucht der Browser, das XML-Dokument in dem im Browser angegebenen Umfang spezifikationsgerecht zu verarbeiten.
IE6, 7 und 8 unterstützen weder application/xhtml xml noch Mac IE5.
Im Browser des Nokia S60, der auf WebKit basiert, kann der HTTP-Inhaltstyp application/xhtml xml den XML-Modus nicht auslösen, da der Schwerpunkt in mobilen Walled Gardens auf der Kompatibilität mit nicht standardmäßigen Inhalten liegt. (Ältere „mobile Browser“ können keine echten XML-Parser verwenden , da nicht-kanonische Inhalte als XML markiert sind.)
Da ich Konqueror nicht ausreichend getestet habe, kann ich nicht genau sagen, was in diesem Browser passieren wird.
Einige Engines verfügen über Modi, die nichts mit Webinhalten zu tun haben. Der Vollständigkeit halber werden sie hier nur erwähnt. Opera verfügt über einen WML2.0-Modus. WebKit auf Leopard verfügt über einen speziellen Modus für ältere Dashboard-Widgets.
Hier sind die wichtigsten Auswirkungen dieser Muster:
Der Text/HTML-Modus wirkt sich hauptsächlich auf das CSS-Layout aus. Es ist zum Beispiel eine Eigenart, dass Tabellen keine Stile erben. In einigen Browser-Mackenmodi wird das Box-Modell zum IE5.5-Box-Modell. In diesem Dokument werden nicht alle Layout-Macken aufgeführt.
Im Semi-Standard-Modus (in Browsern mit diesem Modus) unterscheidet sich nur die Höhe der Tabellenzelle, die das Bild enthält, von der im Standard-Modus.
Im XML-Modus weisen Selektoren ein unterschiedliches Verhalten auf, bei dem die Groß-/Kleinschreibung beachtet wird. Darüber hinaus gelten die spezifischen Regeln für das HTML-Body-Element nicht für ältere Browser, die die neuesten CSS 2.1-Änderungen nicht implementieren.
Es gibt auch Macken, die sich auf die Analyse von HTML und CSS auswirken und dazu führen können, dass standardkonforme Webseiten falsch analysiert werden. Das Quirk-Layout bestimmt, ob diese Macken aktiviert sind oder nicht. Unabhängig davon ist es wichtig, die wichtigsten Gemeinsamkeiten und Unterschiede zwischen dem Quirks-Modus und dem Standards-Modus beim CSS-Layout und beim Parsen (nicht beim HTML-Parsen) zu verstehen.
Manche Leute bezeichnen den Standardmodus fälschlicherweise als „strengen Analysemodus“, was zu Missverständnissen über die Fähigkeit des Browsers, HTML-Syntaxregeln durchzusetzen, und die Fähigkeit des Browsers, Markup auf Korrektheit zu prüfen, führt. Dies ist nicht der Fall. Selbst wenn das Standardmodus-Layout in Kraft ist, führen Browser immer noch Korrekturarbeiten an der Tag-Suppe (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 von HTML-Syntaxregeln. Diese Modi waren mit vorhandenen Webinhalten nicht kompatibel und wurden aufgegeben.)
Ein weiteres häufiges Missverständnis betrifft das XHTML-Parsing. Es wird allgemein angenommen, dass die Verwendung des XHTML-Dokumenttyps zu einer unterschiedlichen Analyse führt. Tatsächlich ist dies nicht der Fall. XHTML-Dokumente mit dem Inhaltstyp text/html verwenden denselben Parser wie HTML-Dokumente. Derzeit kümmern sich Browser nur darum, dass XHTML mit dem Dokumenttyp text/html nur „Tag-Suppe mit Croutons“ ist (überall zusätzliche Schrägstriche).
Nur wenn Dokumente, die den XML-Dokumenttyp verwenden (z. B. application/xhtml xml oder xmapplication/), den XML-Modus zum Parsen auslösen, unterscheidet sich der Parser zu diesem Zeitpunkt vollständig vom HTML-Parser.
Während es im Quirks-Modus hauptsächlich um CSS geht, geht es auch ein wenig um Skripting. Beispielsweise erstellt das HTML-ID-Attribut im Quirks-Modus von Firefox eine globale Objektreferenz im Skriptbereich, genau wie im IE. Die Auswirkungen von Skripten im IE8 verdienen mehr Aufmerksamkeit als in anderen Browsern.
Im XML-Modus ist das Verhalten einiger DOM-APIs völlig anders, da das Verhalten der DOM-API von XML nicht mit dem Verhalten von HTML kompatibel ist, wenn es definiert ist.
Moderne Browser verwenden Doctype-Sniffing, um den Engine-Modus von Text-/HTML-Dokumenten 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 grammatikalische Fälschung von SGML, einem Markup-Framework alten Stils, und HTML, bevor HTML5 darauf basiert. In der HTML4.01-Spezifikation beschreibt die Dokumenttypdeklaration die Versionsinformationen von HTML. Trotz des Namens „Document Type Declaration“ und der HTML 4.01-Spezifikation, die „Versionsinformationen“ beschreibt, klassifiziert eine Document Type Declaration ein SGML- oder XML-Dokument nicht als einen bestimmten Dokumenttyp, auch wenn es (aufgrund des Namens) so aussieht. . (Mehr im Anhang)
Weder die HTML4.01-Spezifikation noch ISO 8879 (SGML) sagen etwas über die Verwendung von Dokumenttypdeklarationen als Engine-Modus-Konvertierungen aus. Doctype Sniffing basiert auf der Beobachtung, dass zum Zeitpunkt der Entwicklung von Doctype Sniffing die überwiegende Mehrheit der eigenartigen Dokumente weder eine Dokumenttypdeklaration noch einen Verweis auf eine ältere DTD hatte. HTML5 akzeptiert diese Tatsache und definiert den Doctype in text/html als einzige Moduskonvertierung.
Eine typische Dokumenttypdeklaration vor HTML5 enthält (durch Leerzeichen getrennt) die Zeichenfolge „“. Die Dokumenttypdeklaration wird vor dem öffnenden Tag des Stammelements des Dokuments platziert.
Hier ist eine einfache Anleitung zur Auswahl eines Dokumenttyps beim Erstellen eines neuen Text-/HTML-Dokuments:
Ich empfehle keinen XHTML-Dokumenttyp, da XHTML, das als Text/HTML verwendet wird, als schädlich gilt . Wenn Sie sich jedoch für die Verwendung des XHTML-Dokumenttyps entscheiden, beachten Sie, dass XML-Deklarationen den Quirks-Modus in IE6 (aber nicht in IE7!) auslösen.
Eine einfache Richtlinie für application/xhtml XML ist, niemals Doctype zu verwenden. Webseiten auf diese Weise sind nicht „streng konsistent“ mit XHMTL 1.0, aber das spielt keine Rolle. (Siehe bitte den Anhang hinten)
A List Apart hat einmal eingeführt , dass IE8 zusätzlich zum Doctype die Moduskonvertierung basierend auf Metaelementen als einen der Faktoren bei der Modusauswahl verwenden wird. (Siehe Ian Hickson, David Baron, David Baron again, Robert O'Callahan und Maciej Stachowiak Kommentare . )
IE8 verfügt über 4 Modi: IE5.5-Quirks-Modus, IE7-Standardmodus, IE8-Quasi-Standardmodus und IE8-Standardmodus. Die Wahl des Modus hängt von Daten aus mehreren Quellen ab: Dokumenttyp, Metaelemente, HTTP-Header, periodische Download-Daten von Microsoft, LAN-Domäne, vom Benutzer vorgenommene Einstellungen, vom LAN-Administrator vorgenommene Einstellungen und der Modus des übergeordneten Frames (falls vorhanden). beliebig) Kompatibel mit der Adressleisten-Ansichtsschaltfläche wird vom Benutzer ausgelöst. (Bei anderen in die Engine eingebetteten Apps hängt der Modus auch von der eingebetteten App ab.)
Glücklicherweise verwendet IE8 im Allgemeinen Doctype-Sniffing wie andere Browser, wenn:
Mit Ausnahme der beiden oben genannten Fälle bezüglich X-UA-Kompatibilität führt IE8 das Doctype-Sniffing wie IE7 durch. Die IE7-Emulation wird als Kompatibilitätsansicht bezeichnet.
Im Fall von X-UA-Compatible verhält sich IE8 völlig anders als andere Browser. Ich würde gerne den Anhang oder das Flussdiagramm in den Formaten PDF und PNG auf dieser Seite sehen.
Leider ermöglicht IE8 Benutzern ohne den X-UA-kompatiblen HTTP-Header oder Meta-Tag, selbst mit dem entsprechenden Dokumenttyp, versehentlich ein Downgrade der Seite vom IE8-Standardmodus auf den IE7-Modus, bei dem es sich um eine Emulation des IE7-Standardmodus handelt. Schlimmer noch, LAN-Administratoren können dies auch tun. Microsoft kann auch alle von Ihnen verwendeten Domänennamen auf die schwarze Liste setzen.
Um mit diesen Effekten umzugehen, reicht der Doctype nicht aus, Sie benötigen einen X-UA-kompatiblen HTTP-Header und ein Meta-Tag.
Im Folgenden finden Sie eine einfache Anleitung zur Auswahl 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 Quasi-Standardmodus auslöst:
Doctype Sniffing ist ein Tag-Chowder-ähnlicher Ansatz zur Lösung eines Tag-Chowder-Problems. Doctype-Sniffing ist eine Heuristik, die nach der Veröffentlichung der HTML4- und CSS2-Spezifikationen entwickelt wurde und veraltete Dokumente von Dokumenten unterscheidet, die dem Verhalten entsprechen, das ihre Autoren möglicherweise erwartet hätten.
Gelegentlich wird empfohlen, Doctype Sniffing für XML zu verwenden, um verschiedene Verarbeitungen zu planen, das verwendete Vokabular zu identifizieren oder Funktionen zu aktivieren. Das ist eine schlechte Idee. Planung und Vokabularidentifizierung sollten auf Namespaces basieren, während die Funktionsaktivierung auf expliziten Verarbeitungsanweisungen oder -elementen basieren sollte.
Die gesamte Idee der Wohlgeformtheit besteht darin, das DTD-freie Parsen von XML einzuführen und eine doctype-freie Dokumentation zu fördern. Im formalen Fall, dass zwei XML-Dokumente dieselbe kanonische Form haben und die Anwendung sie unterschiedlich verarbeitet (und der Unterschied nicht auf mangelnde Auswahlmöglichkeiten zur Verarbeitung externer Entitäten zurückzuführen ist), kann die Anwendung fehlerhaft sein. Wenn in der Praxis zwei XML-Dokumente dazu führen, dass derselbe Inhalt an einen SAX2-
-Content-Handler gemeldet wird (Qnames werden ignoriert) und die Anwendung die Dokumente unterschiedlich verarbeitet, kann die Anwendung kaputt gehen. In Anbetracht der Tatsache, dass Sie als Webautoren nicht darauf vertrauen können, dass jeder einen XML-Prozessor verwendet, der zusätzliche Entitäten auflöst, um seine Seiten zu analysieren (auch wenn einige Browser dies scheinbar tun, weil sie bestimmte öffentliche Bezeichner einer verkürzten entitätsdefinierenden DTD zuordnen), Einfügen Doctypes in XML für das Web umzuwandeln ist sinnlos und führt oft zu Cargo-Kultgewohnheiten. (Sie verwenden immer noch die DTD-Override-Funktion von W3C Validator, um eine DTD zu validieren, obwohl W3C Validator angibt, dass das Ergebnis nur vorübergehend gültig ist. Oder noch besser, Sie können NG mit Validieren lockern, es verunreinigt nicht das vom Schema referenzierte Dokument. Es ist ziemlich dumm, einen Doctype zu verlangen, um zu schnüffeln, auch wenn das in der HTML-Praxis der Workaround ist. Wenn eine Spezifikation auf niedrigerer Ebene zwei Dinge als gleich definiert, sollte eine Spezifikation auf höherer Ebene nicht versuchen, ihnen unterschiedliche Bedeutungen zu geben. Bitte beachten Sie . Wenn Sie die öffentliche Kennung entfernen, wird weiterhin dieselbe DTD angegeben, sodass doctype bedeutet dasselbe wie der vorherige Dokumenttyp. Sollten sie anders gerochen werden? Kann weitere Theorien aufstellen. Angenommen, eine DTD namens foobar.dtd wird nach example.com kopiert: . Wie kann man das erschnüffeln? Es sollte dasselbe bedeuten. Sogar die gesamte DTD kann an das Dokument angehängt werden. Mit anderen Worten: Wenn #include „foo.h“ vorhanden ist, sollten Sie keine schwarze Magie an den Namen foo.h binden, da dies das Kopieren des Inhalts von foo.h in das Dokument oder das Kopieren von foo ermöglichen sollte. h in bar.h ein und bedeutet #include „bar.h“. Der Grund, warum ich mir keine Sorgen darüber mache, dass HTML und SGML dieselben Parameter erstellen, ist, dass Webbrowser keine echten SGML-Parser zum Parsen von HTML verwenden. Daher halte ich es nicht für sinnvoll, vorzugeben, SGML zu sein. Wie auch immer, wenn Sie noch nicht überzeugt sind, finden Sie hier W. Eliot Kimbers Artikel zu diesem Thema comp.text.sgml In der folgenden Tabelle werden der Quirk-Modus, der Standardmodus und der Quasi-Standard durch Q, S bzw. A dargestellt. Wenn der Browser nur über zwei Modi verfügt und die Zeilenhöhe der Tabellenzelle mit dem Standardmodus von Mozilla übereinstimmt, wird der Standardmodus mit „S“ gekennzeichnet. Wenn die Zeilenhöhe der Tabellenzelle mit dem Quasi-Standardmodus von Mozilla übereinstimmt, wird der Standardmodus mit „S“ gekennzeichnet. dann wird es als „A“ gekennzeichnet. Bitte beachten Sie, dass XHTML, das mit dem XML-Inhaltsmodell bereitgestellt wird, im XML-Modus gerendert wird. Der Zweck dieser Tabelle besteht nicht darin, zu sagen, dass alle Dokumenttypen in der Tabelle eine sinnvolle Wahl für neue Seiten sind. Der Zweck dieser Tabelle besteht darin, zu zeigen, auf welchen Daten meine Empfehlungen basieren. Für Spaltenüberschriften werden folgende Abkürzungssymbole verwendet: Anhang: Umgang mit einigen Dokumenttypen in Text/HTML
Moziilas Doctype-Sniffing-Code wurde im Oktober 2000, September 2001 und Juni 2002 erheblich geändert. Der Status des in diesem Dokument beschriebenen Mozilla-Builds (und Netscape 6.x) kann unter ftp.mozilla.org ab dem 19.10.2000 eingesehen werden. In diesem Dokument wird nicht behandelt, wie das Doctype-Sniffing in Mozilla M18 (und Netscape 6.0 PR3) funktioniert. Auch der Doctype-Sniffing-Code von Safari wurde seit der ersten öffentlichen Betaversion erheblich verändert. Dieses Dokument behandelt kein Verhalten vor Version V73, auch 0.9 genannt.
Der Doctype-Sniffing-Code vor Konqueror 3.5 scheint aus einer sehr frühen Version von Safari zu stammen. Konqueror entspricht jetzt Safari und sein Doctype-Sniffing-Code stammt von Mozilla.
Wie aus der Tabelle hervorgeht, ändert sich das Doctype-Sniffing von Opera regelmäßig von einer Ähnlichkeit mit dem IE zu einer Ähnlichkeit mit Mozilla, obwohl Opera 9.5 und 9.6 auf dem Rückweg sind. Gleichzeitig wurde das Layoutverhalten des Opera-Quirks-Modus von der Emulation des Quirks-Modus von IE6 auf den Quirks-Modus von Mozilla umgestellt.
Vielen Dank an Simon Pieters, Simon Pieters und Anne van Kesteren für ihre Hilfe bei der Korrektur der Musterblätter für verschiedene Opera-Versionen und für ihre Kommentare. Vielen Dank an Simon Pieters für die Erstellung eines weiteren IE8-Flussdiagramms.
Der Computer hat Internetzugang, aber der Browser kann die Webseite nicht öffnen
Was bedeutet Browser
Browser-Kompatibilität
So lösen Sie das Problem verstümmelter Zeichen beim Öffnen einer Webseite
Überprüfen Sie den Online-Status Ihrer Freunde auf TikTok
So beheben Sie das Fehlen von winntbbu.dll
Wofür wird Javascript hauptsächlich verwendet?
Welche Kodierung wird in einem Computer zur Verarbeitung von Daten und Anweisungen verwendet?
![[Web-Frontend] Node.js-Schnellstart](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
