よく知られているブラウザのDOCTYPEモード選択メカニズム

ドキュメントの範囲

この記事では、Firefox やその他の Gecko ベースのブラウザ、Safari、Chrome やその他の Webkit ベースのブラウザ、Opera、Konqueror、Mac 版 Internet Explorer、Windows 版 Internet Explorer、および組み込み IE ブラウザのモード切り替えについて説明します。ブラウザ エンジンの名前を記載するのは避け、代わりにそのエンジンを使用する最も有名なブラウザの名前を記載します。

この記事では、各モードの正確な動作を説明するのではなく、モード選択のメカニズムに焦点を当てています。

モデル

さまざまなモードは次のとおりです。

コンテンツタイプ text/html のモード

text/html コンテンツのモード選択は、doctype スニッフィングに基づいています (この記事の後半で説明します)。 IE8 では、モードは他の要因にも依存します。ただし、IE8 のデフォルトでは、Microsoft 提供のブラックリストに含まれていない非イントラネット サイトのモードはドキュメントの種類によって異なります。

この記事ではモードについて一律に説明していますが、モードの正確な動作はブラウザごとに異なるということは強調しすぎることはありません。

癖モード

互換モードでは、ブラウザは 1990 年代後半に一般的だった方法に従って作成されたページが「壊れる」のを避けるために、最新の Web 書式設定規則に違反します。ブラウザによって、動作に異なる癖が実装されます。 Internet Explorer 6、7、8 では、Quirks モードは IE 5.5 で事実上固定されます。他のブラウザでは、Quirks モードは標準モードからわずかに逸脱します。

新しいページを作成する場合は、関連する仕様 (特に CSS 2.1) に準拠し、標準モードを使用する必要があります。

標準モード

標準モードでは、ブラウザは、指定されたブラウザで可能な限り、標準に準拠したドキュメントの仕様に正しい処理を実行しようとします。

ブラウザによって段階が異なるため、標準モードは単一の目標ではありません。

HTML5ではこのモードを「ノークワルクモード」と呼びます。

ほぼ標準モード

Safari、Chrome、Opera (7.5 以降)、IE8 には、「準標準モード」と呼ばれるモードもあり、これは CSS2 仕様に厳密に従うのではなく、従来の慣例に従ってテーブル セルの垂直サイズを実装します。 Mac IE5、Windows IE6 および 7、Opera 7.5 より前、および Konqueror では、少なくともそれぞれの標準モードでは、垂直方向のテーブル セルのサイズ設定に関する CSS2 仕様に厳密に従っていないため、準標準モードは必要ありません。実際、彼らの標準モードは、Mozilla の標準モードよりも、Mozilla の準標準モードに近いです。

HTML5 では、このモードを「制限付き Quirks モード」と呼びます。

IE7 モード

IE8 には、基本的に IE7 の標準モードのコピーをフリーズするモードがあります。他のブラウザにはこのようなモードはなく、HTML5 でも指定されていません。

コンテンツ タイプ application/xhtml+xml (XML モード) のモード

Firefox、Safari、Chrome、Opera では、application/xhtml+xml HTTP コンテンツ タイプ (メタ要素でも 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 レイアウトに影響します。たとえば、テーブルがスタイルを継承しないのは奇妙なことです。一部のブラウザの Quirks モードでは、ボックス モデルは IE5.5 ボックス モデルになります。このドキュメントでは、レイアウトの癖をすべて列挙しているわけではありません。

準標準モード（そのようなモードを持つブラウザ）では、画像のみを含むテーブルセルの高さが標準モードの場合と異なります。

XML スキーマでは、セレクターの大文字と小文字の区別の動作が異なります。さらに、HTML body 要素の特定のルールは、最新の CSS 2.1 の変更を実装していない古いブラウザには適用されません。

分析

HTML と CSS の解析に影響し、標準に準拠した Web ページが誤って解析される原因となる奇妙な点もいくつかあります。 Quirks レイアウトによって、これらの Quirks がオンかオフかが決まります。いずれにせよ、CSS レイアウトと解析 (HTML 解析ではない) の観点から、Quirks モードと標準モードの主な類似点と相違点を理解することが重要です。

標準モードを誤って「厳密な解析モード」と呼ぶ人もいますが、これはブラウザを誤解させ、HTML 構文ルールを強制し、マークアップの正確性を評価することになります。そうではありません。標準モード レイアウトが有効な場合でも、ブラウザーはタグ スープ (http://en.wikipedia.org/wiki/Tag_soup) の修正作業を実行します。 (2000 年に Netscape 6 がリリースされる前は、Mozilla には HTML 構文規則を強制する解析モードがありました。これらのモードは、既存の Web コンテンツと互換性がないため非推奨になりました。)

もう一つのよくある誤解は、XHTML 解析に関するものです。一般的に、XHTML doctype を使用すると解析結果が異なると考えられています。実際はそうではありません。コンテンツ タイプが text/html の XHTML ドキュメントは、HTML ドキュメントと同じパーサーを使用します。現在、ブラウザは、doctype が text/html の XHTML が単なる「クルトン入りタグスープ」(あちこちに余分なスラッシュがある) であることを気にしています。

XML ドキュメント タイプ (例: application/xhtml+xml または xmapplication/) を使用するドキュメントのみが解析用の XML モードをトリガーし、この時点でのパーサーは HTML パーサーとはまったく異なります。

スクリプト

Quirks モードは主に CSS に関するものですが、スクリプトに関するものもいくつかあります。たとえば、Firefox の Quirks モードでは、HTML の ID 属性は IE の場合と同様に、グローバル スクリプト スコープでオブジェクト参照を確立します。 IE8 でのスクリプトの影響は、他のブラウザよりも顕著です。

XML モードでは、XML の DOM API の動作が HTML の動作と互換性がないように定義されているため、一部の DOM API の動作がまったく異なります。

ドキュメントタイプスニッフィング（ドキュメントタイプ変換とも呼ばれる）

最近のブラウザは、doctype スニッフィングを使用して text/html ドキュメントのエンジン モードを決定します。つまり、モードの選択は、HTML ドキュメントの先頭にあるドキュメント タイプ宣言 (またはその欠如) に基づいて行われます。 (これは、XML ドキュメント タイプを使用するドキュメントには適用されません。)

文書型宣言 (doctype) は、HTML5 以前の HTML の定義に使用された古いマークアップ フレームワークである SGML の構文上の偽造です。 HTML4.01仕様では、ドキュメント型宣言でHTMLのバージョン情報を記述します。 「文書型宣言」という名前や、HTML 4.01 仕様で「バージョン情報」と説明されている内容にもかかわらず、文書型宣言は、SGML または XML 文書が (名前からして) 特定の種類の文書のように見えても、SGML または XML 文書を特定の種類の文書として分類することを意図したものではありません。 （詳細は付録を参照）

HTML 4.01 仕様も ISO 8879 (SGML) も、ドキュメント タイプ宣言をエンジン モード スイッチとして使用することについては何も述べていません。 Doctype スニッフィングは、Doctype スニッフィングが設計された当時、Quirks ドキュメントのほとんどにドキュメント タイプ宣言も古い DTD への参照もなかったという観察に基づいています。 HTML5 はこの事実を受け入れ、text/html doctype を唯一のモードスイッチとして定義します。

典型的な HTML5 以前のドキュメント タイプ宣言には、(空白で区切られた)「<!DOCTYPE」文字列、ルート要素のユニバーサル識別子 (「html」)、「PUBLIC」文字列、引用符で囲まれた DTD のパブリック識別子、同じ DTD の可能なシステム識別子 (URL)、および文字「>」が含まれます。ドキュメント タイプ宣言は、ドキュメントのルート要素開始タグの前に配置されます。

ドキュメントタイプを選択

テキスト/HTML

新しい text/html ドキュメントを作成するときに doctype を選択する方法についての簡単なガイドを次に示します。

標準モード、最先端の検証

<!DOCTYPE html>

これは、 <video> 、 <canvas> 、 ARIA などの新しい機能を検証する場合に適切な方法です。 HTML5 の有効な定義はまだ流動的であるため、Firefox、Safari、Chrome、Opera 9、または Opera 10 で画像の配置を必ずテストしてください。 Internet Explorer で画像の配置をテストするだけでは不十分です。必ず IE8 でもテストしてください。

より安定した検証対象である標準モード

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

この doctype は標準モードもトリガーし、10 年前の HTML 4.01 の有効な定義は安定しています。必ず Firefox、Safari、Chrome、Opera 9、または Opera 10 で画像の配置をテストしてください。 Internet Explorer で画像の配置をテストするだけでは不十分です。必ず IE8 でもテストしてください。

標準モードを使用したいが、非推奨のマークアップを検証したり、テーブルレイアウトでスライスされた画像を使用したりして修正したくない。

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

これにより、標準に近いモード (および古い Mozilla の完全標準モード) がトリガーされます。テーブルで実装されたスライスされた画像に基づくレイアウトは、後で HTML5 に移植された場合に壊れる可能性があることに注意してください (これは完全な標準モードにも適用されます)。

意図的にQuirksモードを使用する

ドキュメントタイプがありません。

そんなことしないでください。意図的に Quirks モード用に設計すると、将来、同僚や後任者が Windows IE6 を気にしなくなったときに悩まされることになります (Netscape 4.x や IE5 を気にする人は誰もいなくなりました)。奇妙な動作モード向けに設計するのは悪い考えです。私を信じて。

Windows IE6 を引き続きサポートしたい場合は、他のブラウザを Quirks モードにフォールバックさせるよりも、条件付きコメントを使用して特別なハックを行う方が適切です。

XHTML を text/html として使用すると有害であると考えられるため、XHTML doctype は推奨しません。いずれにしても、XHTML doctype を使用することを選択した場合は、XML 宣言によって IE6 (IE7 ではありません!) で Quirks モードがトリガーされることに注意してください。

アプリケーション/xhtml+xml

application/xhtml+xml の簡単なガイドラインは、doctype を決して使用しないことです。このモードの Web ページは XHTML1.0 に厳密に準拠しているわけではありませんが、これは重要ではありません。 （下記付録をご覧ください）

IE8 の合併症

A List Apart はかつて、Doctype に加えて、IE8 ではメタ要素に基づくモード遷移をモード選択の要素の 1 つとして使用すると紹介しました。 (Ian Hickson、David Baron、David Baron (再び)、Robert O'Callahan、Maciej Stachowiak のコメントを参照してください。)

IE8 には、IE5.5 互換モード、IE7 標準モード、IE8 準標準モード、IE8 標準モードの 4 つのモードがあります。選択されるモードは、doctype、メタ要素、HTTP ヘッダー、Microsoft から定期的にダウンロードされるデータ、LAN ドメイン、ユーザーによる設定、LAN 管理者による設定、親フレームのモード (存在する場合)、およびアドレス バーの互換表示ボタンがユーザーによってトリガーされたかどうかなど、複数のソースからのデータに基づいています。 (エンジンを埋め込む他のアプリケーションの場合、モードは埋め込みアプリケーションによっても異なります。)

幸いなことに、次の条件が満たされている場合、IE8 は他のブラウザと同様に doctype スニッフィングを主に使用します。

• 著者はX-UA-compatible HTTPヘッダーを設定していない
• 著者はX-UA-compatibleメタタグを設定していない
• マイクロソフトはサイトのドメイン名をブラックリストに登録していない
• LAN管理者がサイトをブラックリストに登録していない
• ユーザーが互換表示ボタンを押していない（または特定のユーザーのブラックリストに追加されている）
• サイトはローカルエリアネットワークドメイン内にありません
• ユーザーはIE7ですべてのサイトを表示することを選択しませんでした
• ページはフレーム経由で互換モードページに埋め込まれていません

IE8 は、X-UA-compatible に関する上記の 2 つのケースを除き、IE7 と同様に doctype スニッフィングを実行します。 IE7 エミュレーションは互換表示と呼ばれます。

X-UA-compatible の場合、IE8 は他のブラウザとはまったく異なる動作をします。このページの付録またはフローチャートを PDF および PNG 形式で表示したいですか?

残念ながら、X-UA-compatible HTTP ヘッダーまたはメタ タグがないと、適切な doctype を使用している場合でも、IE8 ではユーザーが誤ってページを IE8 標準モードからエミュレートされた IE7 標準モードである IE7 モードにダウングレードしてしまう可能性があります。さらに悪いことに、LAN 管理者も同じことを行うことができます。 Microsoft は、使用するすべてのドメインをブラックリストに登録することもできます。

これらの影響に対抗するには、doctype だけでは不十分で、X-UA-compatible HTTP ヘッダーとメタ タグが必要です。

以下は、他のブラウザで標準モードまたは準標準モードをトリガーする doctype を既に持つ新しい text/html ドキュメントに対して、X-UA 互換の HTTP ヘッダーまたはメタ タグを選択するための簡単なガイドです。

あなたのドメインは Microsoft のブラックリストに載っておらず、ユーザーが IE7 の動作に戻れないようにすることよりも、ブラウザ固有の煩わしさを回避することに重点を置いています。

X-UA-compatible HTTP ヘッダーまたはメタ タグを含める必要はありません。

あなたのドメインが Microsoft のブラックリストに登録されているのは、あなたのドメインの他の作成者が壊れたサイトを所有しており、ユーザーがドメイン全体で互換表示を有効にする原因となっている可能性があるためです。Google や Digg があなたのサイトをフレーミングすることを心配しているか、ユーザーが互換表示を使用できないようにしたいと考えています。

まず、ページに次のメタ要素を含めます (HTML5 では無効です) <meta http-equiv="X-UA-compatible" content="IE=Edge"> (スクリプト要素の前)、または次の HTTP ヘッダーを設定します: X-UA-compatible: IE=Edge

サイトは IE7 では動作しますが、IE8 では動作しません

まず、ページに次のメタ要素を含めます (HTML5 では無効です)。 (スクリプト要素の前)、または次の HTTP ヘッダーを設定します: X-UA-compatible: IE=EmulateIE7。その後、サイトを修正して非標準の IE7 動作に依存しないようにし、IE=Edge に移行します。

関連リンク

• Eric Meyer は、正しい Doctype の使用で Mac IE5 モードについて書いています。
• Mozilla の Doctype スニッフィング (David Baron 著)
• Lance Silver は、「IE6 の CSS 強化」で Windows IE6 のモードと doctype スニッフィングについて説明しています。
• Opera9 ドキュメントタイプ変換
• Faruk Ateş の IE8 と X-UA 互換のソリューション

補遺: XML 実装者と仕様作成者へのお願い

XML に doctype スニッフィングを導入しないでください。

Doctype スニッフィングは、タグスープの問題に対するタグスープのソリューションです。 Doctype スニッフィングは、HTML4 および CSS2 仕様が公開された後に設計されたヒューリスティックであり、古いドキュメントと作成者が期待する動作に準拠したドキュメントを区別します。

時々、さまざまな処理をスケジュールしたり、使用中の語彙を識別したり、機能をアクティブ化したりするために、XML で doctype スニッフィングを使用することを提案する人もいます。これは悪い考えだ。ディスパッチと語彙の識別は名前空間ベースで行う必要がありますが、機能のアクティブ化は明示的な処理命令または要素に基づく必要があります。

整形式性という概念は、XML の DTD なしの解析を可能にし、doctype なしのドキュメントを促進するために導入されました。正式なケースでは、2 つの XML ドキュメントが同じ正規形式を持ち、アプリケーションがそれらを異なる方法で処理する場合 (その違いが外部エンティティの処理における選択の欠如によるものではない場合)、アプリケーションが壊れる可能性があります。実際には、2 つの XML ドキュメントで同じコンテンツが SAX2 コンテンツ プロセッサに報告され (qname は無視されます)、アプリケーションがそれらのドキュメントを異なる方法で処理する場合、そのアプリケーションはおそらく壊れています。 Web 作成者として、余分なエンティティを解決する XML プロセッサを使用してページを解析することをすべての人に信頼することはできないことを考えると (一部のブラウザは、特定の共通識別子をエンティティを定義する短縮された DTD にマップするため、そのように動作するように見えますが)、Web 用に XML に doctype を挿入することは無意味であり、通常はカーゴ カルト的な習慣につながります。 (W3C バリデータの DTD オーバーライド機能を使用して DTD に対して検証することはできますが、W3C バリデータでは、結果は暫定的に有効であると表示されます。または、さらに良い方法として、スキーマ参照でドキュメントを汚染しない、緩和された NG 検証を使用することもできます。) スニッフィングの目的で doctype を要求するのは、たとえそれが HTML の実践で行われる方法だとしても、かなりばかげています。

さらに、低レベルの仕様で 2 つのものが等しいと定義されている場合、高レベルの仕様ではそれらに異なる意味を与えようとすべきではありません。 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> を検討してください。公開識別子が削除されても同じ DTD が指定されているため、doctype <!DOCTYPE html SYSTEM "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> は以前の doctype と同じ意味になります。嗅ぎ方は違うほうがいいのでしょうか?この理論はさらに発展させることができる。 example.com に foobar.dtd という DTD が指定されているとします: <!DOCTYPE html SYSTEM "http://example.com/foobar.dtd"> 。これをどうやって嗅ぐのですか?それは同じことを意味するはずです。 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 を読んでみてください。

付録: text/html でいくつかの doctype を処理する方法

次の表では、Quirks モード、標準モード、および準標準はそれぞれ Q、S、および A として示されています。ブラウザにモードが 2 つしかない場合、テーブル セルの行の高さが Mozilla の標準モードと同じように動作する場合は標準モードは「S」とマークされ、テーブル セルの行の高さが Mozilla の準標準モードと同じように動作する場合は「A」とマークされます。

XML コンテンツ モデルを使用して提供される XHTML は XML モードでレンダリングされることに注意してください。

この表の目的は、表内のすべての doctype が新しいページに適した選択肢であると主張することではありません。この表の目的は、私がどのようなデータに基づいて推奨事項を作成しているかを示すことです。

列見出しには次の略語が使用されます。

NS6

Mozilla 0.6…0.9.4 および Netscape 6.0…6.2.3

オールドモズ

Mozilla 0.9.5 から 1.1 アルファおよび Mozilla 1.0

Moz & Safari & Opera 10 & HTML5

Mozilla 1.0.1、Mozilla 1.1 ベータ版以降、Firefox から Netscape 7、Safari 0.9 から Safari 4.0 ベータ版、Opera 10、Chrome、Konqueror 3.5、HTML5 固有の動作

オペラ 9.0

オペラ 9.0…9.20

IE8 および Opera 9.5

X-UA-compatible および互換モードのオーバーライドのないデフォルトの IE8 (この場合の「A」は IE8 の標準に近いモードを意味します)、Opera 7.5…8.54 および 9.5…9.6

IE 7 および Opera 7.10

IE7、X-UA-compatible オーバーライドなしの互換モードの IE8 (この場合、「A」は IE7 モードを意味します)、および Opera 7.10…7.23

IE 6 および Opera 7.0

Windows IE 6 および Opera 7.0…7.03

マックIE5

Mac IE 5.0…5.2.3

コンク3.2

Konqueror 3.2.2…3.3 (おそらく 3.1…3.2.1 ですが、まだ確認していません)

歴史

Moziila の doctype スニッフィング コードは、2000 年 10 月、2001 年 9 月、および 2002 年 6 月に大幅に変更されました。このドキュメントでは、2000 年 10 月 19 日現在、ftp.mozilla.org で入手可能な Mozilla (および Netscape 6.x) ビルドの状態について説明します。このドキュメントでは、Mozilla M18 (および Netscape 6.0 PR3) での doctype スニッフィングの仕組みについては説明しません。 Safari の doctype スニッフィング コードも、最初のパブリック ベータ版以降大幅に変更されています。このドキュメントでは、バージョン V73 (0.9 とも呼ばれる) より前の動作については説明しません。

Konqueror 3.5 より前のバージョンの doctype スニッフィング コードは、Safari の非常に古いバージョンから来ているようです。 Konqueror は、Mozilla の doctype スニッフィング コードを使用して Safari と一致するようになりました。

表からわかるように、Opera の doctype スニッフィングは IE に似たものから Mozilla に似たものへと変化していますが、Opera 9.5 と 9.6 では元に戻りつつあります。同時に、Opera の Quirks モードのレイアウト動作は、IE6 の Quirks モードのエミュレーションから Mozilla の Quirks モードに切り替わりました。

付録: IE8 モードの選択

開始するには、「X-UA-compatible meta?」に進みます。

X-UA 互換メタ?

IE=7: IE7標準を使用する

IE=EmulateIE7: 「Quirks または doctype なし? (互換モード)」と入力します

IE=IE8 または IE=IE7 または IE=a または IE=EmulateIE8 またはスクリプトが最初に表示されます: 「X-UA-compatible HTTP header?」と入力します。

IE=8 または IE=Edge または IE=99 または IE=9.9: 「近似標準モード」を入力しますか?

IE=5: Quirks モードを使用する (IE5.5)

X-UA 互換 HTTP ヘッダー?

IE=7: IE7標準モードを使用する

IE=EmulateIE7: 「Quirks または doctype なし? (互換モード)」に進みます

IE=IE8 または IE=IE7 または IE=a または IE=EmulateIE8 または None: 「すべてのサイトを表示...プリセット?」に進みます。

IE=8 または IE=Edge または IE=99 または IE=9.9: 「近似標準モード」を入力しますか?

IE=5: Quirks モードを使用する (IE5.5)

Quirks モードか、Doctype なしか? (互換モード)

はい: Quirks モードを使用する (IE5.5)

いいえ: IE7 標準モードを使用する

すべてのサイトを表示します...プリセットですか?

はい: 「Quirks モードか、Doctype なしか? (互換モード)」と入力します

いいえ: 「LAN サイトを表示...プリセット?」に進みます。

LAN サイトを表示します...プリセットですか?

はい: 「サイトは LAN ドメイン内にありますか?」に進みます。

いいえ: 「ドメイン名は Microsoft によって管理されているリストに載っていますか?」に進みます。

ドメインは Microsoft が管理するリストに載っていますか?

はい: 「Quirks モードか、Doctype なしか? (互換モード)」と入力します

いいえ: 「フレームを使用して互換モードページに埋め込まれていますか?」に進みます。

フレームを使用して互換モードページに埋め込まれていますか?

はい: 「Quirks モードか、Doctype なしか? (互換モード)」と入力します

いいえ: 「互換モード ボタンが押されましたか?」に進みます。

互換モードボタンは押されましたか?

はい: 「Quirks モードか、Doctype なしか? (互換モード)」と入力します

いいえ: 「Quirks モードか、Doctype なしか? (IE8)」と入力します。

Quirks モードか、それとも doctype なしか? (IE8)

はい: 「Quirks モードを使用する (IE5.5)」と入力します

いいえ: 「準標準モード」に入りますか?

準標準モデル？

はい: IE8 準標準モードを使用する

いいえ: IE8 標準モードを使用する

これらの手順は、PDF および PNG 形式のフローチャートとして利用できます。

謝辞

さまざまな Opera バージョンのモード テーブルの修正に協力し、コメントを寄せてくれた Simon Pieters、Simon Pieters、Anne van Kesteren に感謝します。別の IE8 フローチャートを提供してくれた Simon Pieters に感謝します。