この記事に記載されているモード切り替えは、Firefox およびその他の Gecko ベースのブラウザ、Safari、Chrome およびその他の Webkit ベースのブラウザ、Opera、Konqueror、Internet Explorer for Mac、Internet Explorer for Windows、および組み込み IE ブラウザに適用されます。 ブラウザ エンジンの名前については言及せず、代わりにそのエンジンを使用している最もよく知られているブラウザの名前について言及してください。
この記事は、各モードの正確な動作を文書化するのではなく、モード選択メカニズムに焦点を当てています。
ここではさまざまなモードを示します:
text/html コンテンツのモード選択は、doctype スニッフィングによって異なります (この記事で後ほど説明します)。 IE8 では、モードは他の要因にも依存します。ただし、IE8 のデフォルトでは、Microsoft のブラックリストに載っていない非イントラネット サイトのモードはドキュメントの種類によって異なります。
この記事では一律に説明していますが、モードの正確な動作はブラウザごとに異なることは、いくら強調してもしすぎることはありません。
Firefox、Safari、Chrome、Opera では、application/xhtml XML HTTP コンテンツ タイプ (meta 要素や doctype ではありません!) が XML モードをトリガーします。 XML モードでは、ブラウザは、ブラウザで指定された範囲で XML ドキュメント仕様に正しい処理を実行しようとします。
IE6、7、および 8 は application/xhtml XML をサポートしていません。また、Mac IE5 もサポートしていません。
WebKit ベースの Nokia S60 ブラウザでは、モバイル ウォールド ガーデンでは非標準コンテンツとの互換性が重視されているため、application/xhtml xml HTTP コンテンツ タイプは XML モードをトリガーできません。 (古い「モバイル ブラウザ」では、非正規コンテンツが XML としてタグ付けされているため、実際の XML パーサー を使用できません。)
Konqueror を十分にテストしていないため、このブラウザで何が起こるかを正確に言うことはできません。
一部のエンジンには、Web コンテンツとは関係のないモードがあります。完全を期すため、ここではそれらについてのみ言及します。 Opera には WML2.0 モードがあります。 Leopard の WebKit には、レガシー ダッシュボード ウィジェット用の特定のモードがあります。
これらのパターンの主な影響は次のとおりです:
text/html モードは主に CSS レイアウトに影響します。たとえば、テーブルがスタイルを継承しないのは奇妙な点です。一部のブラウザーの互換モードでは、ボックス モデルが IE5.5 ボックス モデルになります。このドキュメントには、レイアウトの癖がすべてリストされているわけではありません。
準標準モード (このモードを備えたブラウザ) では、画像を含む表セルの高さのみが標準モードと異なります。
XML モードでは、セレクターは大文字と小文字を区別する異なる動作をします。さらに、HTML body 要素の特定のルールは、最新の CSS 2.1 の変更を実装していない古いブラウザには適用されません。
HTML と CSS の解析に影響を与える問題もあり、標準に準拠した Web ページが正しく解析されない可能性があります。 Quirk レイアウトによって、これらの Quirk が有効かどうかが決まります。いずれにせよ、CSS レイアウトと解析 (HTML 解析ではありません) における Quirks モードと Standards モードの主な類似点と相違点を理解することが重要です。
標準モードを「厳密解析モード」と誤って呼ぶ人がいます。これは、ブラウザが HTML 構文ルールを適用する機能と、ブラウザがマークアップの正しさを評価する機能を誤解しています。これは事実ではありません。標準モードのレイアウトが有効な場合でも、ブラウザはタグ スープ (http://en.wikipedia.org/wiki/Tag_soup) の修正作業を行います。 (2000 年の Netscape 6 のリリース前、Mozilla には HTML 構文ルールを強制するための解析モードがありました。これらのモードは既存の Web コンテンツと互換性がないため、廃止されました。)
もう 1 つのよくある誤解は、XHTML 解析に関するものです。一般に、XHTML doctype を使用すると、異なる解析が行われると考えられています。実際には、これは当てはまりません。コンテンツ タイプが text/html の XHTML ドキュメントは、HTML ドキュメントと同じパーサーを使用します。現在、すべてのブラウザが気にしているのは、ドキュメント タイプが text/html の XHTML が単なる「クルトン入りのタグ スープ」(どこにでも余分なスラッシュがある) であるということです。
XML ドキュメント タイプ (例: application/xhtml xml または xmapplication/) を使用するドキュメントが解析のために XML モードをトリガーする場合にのみ、このときのパーサーは HTML パーサーとは完全に異なります。
Quirks モードは主に CSS に関するものですが、スクリプトに関するものもあります。たとえば、Firefox の Quirk モードでは、HTML id 属性によって、IE と同様に、グローバルなスクリプトスコープのオブジェクト参照が確立されます。 IE8 におけるスクリプトの影響は、他のブラウザよりも注目に値します。
XML モードでは、一部の DOM API の動作は完全に異なります。これは、XML の DOM API の動作が、HTML の定義時の動作と互換性がないためです。
最新のブラウザは、doctype スニッフィングを使用して text/html ドキュメントのエンジン モードを決定します。これは、モードの選択が HTML ドキュメントの先頭にあるドキュメント タイプ宣言 (またはその欠如) に基づいて行われることを意味します。 (これは、XML 文書タイプを使用する文書には適用されません。)
文書型宣言 (doctype) は SGML の文法を偽造したものです。 SGML は古いスタイルのマークアップ フレームワークであり、HTML5 より前の HTML はそれに基づいて定義されました。 HTML4.01仕様では、文書型宣言にHTMLのバージョン情報を記述します。 「文書型宣言」という名前と「バージョン情報」を説明する HTML 4.01 仕様にもかかわらず、文書型宣言は、たとえその名前が似ているとしても、SGML または XML 文書を特定の文書型として分類しません。 。 (詳細は付録で説明)
HTML4.01 仕様も ISO 8879 (SGML) も、エンジン モード変換としてのドキュメント タイプ宣言の使用については何も述べていません。 Doctype スニッフィングは、Doctype スニッフィングが設計された時点では、奇妙な文書の大部分には文書型宣言も古い DTD への参照もなかったという観察に基づいています。 HTML5 はこの事実を受け入れ、text/html の doctype を唯一のモード変換として定義します。
HTML5 以前の典型的な文書型宣言には、"」。文書型宣言は、文書のルート要素の開始タグの前に配置されます。
ここでは、新しい text/html ドキュメントを作成するときに doctype を選択する方法についての簡単なガイドを示します:
text/html として使用される XHTML は有害であると考えられるため、XHTML doctype はお勧めしません 。いずれにせよ、XHTML doctype の使用を選択した場合は、XML 宣言によって IE6 では quirks モードがトリガーされることに注意してください (IE7 ではありません!)。
application/xhtml XML の簡単なガイドラインは、doctype を決して使用しないことです。このような Web ページは XHMTL 1.0 と「厳密に一致」していませんが、それは問題ではありません。 (巻末の付録をご覧ください)
A List Apart では、Doctype に加えて、IE8 がモード選択の要素の 1 つとしてメタ要素に基づくモード変換を使用するという を紹介しました。 (イアン・ヒクソン、デビッド・バロン、デビッド・バロン・アゲイン、ロバート・オキャラハン、およびマチェイ・スタチョウィアクのコメントを参照)
IE8 には、IE5.5 quirks モード、IE7 標準モード、IE8 準標準モード、IE8 標準モードの 4 つのモードがあります。モードの選択は、doctype、メタ要素、HTTP ヘッダー、Microsoft からの定期ダウンロード データ、LAN ドメイン、ユーザーが行った設定、LAN 管理者が行った設定、および親フレームのモード (任意）アドレス バーの表示ボタンと互換性があり、ユーザーによってトリガーされます。 (エンジンに埋め込まれている他のアプリの場合、モードは埋め込みアプリによっても異なります。)
幸いなことに、IE8 は通常、次の場合に他のブラウザと同様に doctype スニッフィングを使用します。
X-UA 互換に関する上記の 2 つのケースを除き、IE8 は IE7 と同様に doctype スニッフィングを実行します。 IE7エミュレーションは互換表示と呼ばれます。
X-UA 互換の場合、IE8 は他のブラウザとはまったく異なる動作をします。このページの 付録 またはフローチャートを PDF および PNG 形式でご覧になりたいです。
残念ながら、X-UA 互換の HTTP ヘッダーまたはメタ タグがないと、適切な doctype を使用していても、IE8 ではユーザーがページを IE8 の標準モードから、エミュレーション IE7 標準モードである IE7 モードに誤ってダウングレードしてしまう可能性があります。さらに悪いことに、LAN 管理者もこれを行う可能性があります。 Microsoft は、使用するすべてのドメイン名をブラックリストに登録することもできます。
これらの影響に対処するには、doctype だけでは不十分です。X-UA 互換の HTTP ヘッダーとメタ タグが必要です。
以下は、他のブラウザで標準モードまたは準標準モードをトリガーする doctype がすでにある新しいテキスト/HTML ドキュメントに対して、X-UA 互換の HTTP ヘッダーまたはメタ タグを選択する方法に関する簡単なガイドです。
Doctype スニッフィングは、タグ チャウダーの問題を解決するためのタグ チャウダーに似たアプローチです。 Doctype スニッフィングは、HTML4 および CSS2 仕様のリリース後に設計されたヒューリスティックで、古いドキュメントと作成者が予期した動作に準拠するドキュメントを区別します。
場合によっては、XML で doctype スニッフィングを使用して、さまざまな処理をスケジュールしたり、使用中の語彙を特定したり、機能を有効にしたりすることが推奨されます。これは悪い考えです。スケジューリングと語彙の識別は名前空間に基づく必要がありますが、機能のアクティブ化は明示的な処理命令または要素に基づく必要があります。
整形式性の全体的な考え方は、DTD を使用しない XML 解析を導入し、doctype を使用しないドキュメントを推進することです。 2 つの XML ドキュメントが同じ正規形式を持ち、アプリケーションがそれらを異なる方法で処理する (この違いは、外部エンティティを処理する選択肢がないためではない) 形式的なケースでは、アプリケーションが壊れる可能性があります。実際には、2 つの XML ドキュメントによって同じコンテンツが SAX2
コンテンツ ハンドラー に報告され (qnames は無視され)、アプリケーションがドキュメントを異なる方法で処理する場合、アプリケーションが壊れる可能性があります。 Web 作成者として、ページを解析するために余分なエンティティを解決する XML プロセッサを誰もが使用するとは信じられないことを考慮すると (一部のブラウザは、特定の公開識別子を切り詰められたエンティティ定義 DTD にマップするため、そうしているように見えますが)、 doctype を Web 用の XML に変換することは無意味であり、しばしば貨物崇拝的な習慣につながります。 (W3C Validator の DTD オーバーライド機能 を使用して DTD を検証しますが、W3C Validator は結果が一時的にのみ有効であると通知します。さらに良いことに、 Validate を使用して NG を緩和できます。スキーマによって参照されるドキュメントを汚すことはありません。 たとえそれが HTML の実践における回避策だったとしても、スニッフィングするために doctype を要求するのは非常に愚かです。 また、下位レベルの仕様で 2 つのものが等しいと定義されている場合、上位レベルの仕様ではそれらに異なる意味を与えようとしてはいけません。 を検討してください。 ;。パブリック識別子を削除しても、同じ DTD が指定されたままであるため、doctype は、前の doctype と同じを意味します。別の方法で嗅ぎ分けるべきでしょうか？さらに理論化することができます。 foobar.dtd という DTD が example.com: にコピーされるとします。これを嗅ぐにはどうすればいいですか？同じことを意味するはずです。 DTD 全体をドキュメントに添付することもできます。 言い換えると、#include "foo.h" がある場合、foo.h という名前に黒魔術をバインドしてはなりません。これは、foo.h の内容をドキュメントにコピーしたり、foo をコピーしたりすることを許可する必要があるためです。 h を bar.h に組み込み、 #include "bar.h" を意味します。 HTML と SGML が同じパラメーターを構築することについて私が心配しない理由は、Web ブラウザーが HTML の解析に実際の SGML パーサーを使用しないためであり、SGML のふりをすることは役に立たないと思うからです。とにかく、まだ納得していない場合は、この問題に関する W. Eliot Kimber の記事 comp.text.sgml を参照してください。
以下の表では、Qquirkモード、標準モード、準標準をそれぞれQ、S、Aで表しています。ブラウザにモードが 2 つしかない場合、表のセルの行の高さが Mozilla の標準モードと一致する場合、標準モードには「S」のマークが付けられます。 表のセルの行の高さが Mozilla の準標準モードと一致する場合、その場合は「A」とマークされます。
Moziila の doctype スニッフィング コードは、2000 年 10 月、2001 年 9 月、および 2002 年 6 月に大幅に変更されました。このドキュメントで説明されている Mozilla (および Netscape 6.x) ビルドのステータスは、2000 年 10 月 19 日時点で ftp.mozilla.org で参照できます。このドキュメントでは、Mozilla M18 (および Netscape 6.0 PR3) での doctype スニッフィングの動作については説明しません。 Safari の doctype スニッフィング コードも、最初のパブリック ベータ版以来大幅に変更されました。このドキュメントでは、0.9 とも呼ばれるバージョン V73 より前の動作については説明しません。
Konqueror 3.5 より前の doctype スニッフィング コードは、Safari の非常に初期のバージョンに由来しているようです。 Konqueror は Safari と一致するようになり、その doctype スニッフィング コードは Mozilla から提供されています。
表からわかるように、Opera 9.5 と 9.6 は戻りつつありますが、Opera の doctype スニッフィングは IE に似たものから Mozilla に似たものへと定期的に変化しています。同時に、Opera の Quirks モードのレイアウト動作が、IE6 の Quirks モードのエミュレートから Mozilla の Quirks モードに切り替えられました。
形式のフローチャートとして表示されます。 ありがとう オペラのさまざまなバージョンのパターン シートの修正を手伝ってくれた Simon Pieters、Simon Pieters、Anne van Kesteren、およびコメントに感謝します。別の IE8 フローチャートを作成してくれた Simon Pieters に感謝します。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
