ところで、本題から外れますが、 HTTP ヘッダーの X-UA-Compatible フィールドより meta 要素の指定の方が優先されるのは知りませんでした。情報ありがとうございます。おっしゃる通り、マイクロソフトのドキュメントでは META Tags and Locking in Future Compatibility [microsoft.com] に
If you specify a default document compatibility mode using your Web server, you can override that setting by specifying a different document compatibility mode in a specific Web page. The mode specified within the Web page takes precedence over the mode specified by the server.
なぜ互換ビューリストに入っているのか (スコア:3, 興味深い)
http://www.microsoft.com/ [microsoft.com] と、 Google でてきとうに検索して出てきた microsoft.com 内のページをいくつか見てみたのですが、ちゃんと X-UA-Compatible: IE=EmulateIE7 が付いています。どうして互換ビューリスト (Compatibility View list) に micorosft.com を入れる必要があるのでしょう。
個人的には、マイクロソフトだけがいじれる互換ビューリストと同じ機能をウェブサイト管理者にも提供してほしかったです。具体的には、 robots.txt とか favicon.ico みたいに、ウェブサーバーに所定のファイル名でファイルを 1 個置いたら同じサーバーの全部のページが互換ビューになってくれるというような。
Re:なぜ互換ビューリストに入っているのか (スコア:1, 参考になる)
> ファイルを 1 個置いたら
.htaccessを1個置くとか。意味もなくhttp-equivなmetaタグで指定する設計になっているわけではありません。本物のHTTPヘッダに入れてもちゃんと効果があります。charset指定と違ってmetaタグのほうが優先されるみたいですけど。
Re:なぜ互換ビューリストに入っているのか (スコア:2)
お返事ありがとうございます。
HTTP の X-UA-Compatible ヘッダーフィールドで指定できるのは知っています。僕の #1519361 [srad.jp] でも、明示的には書きませんでしたが、 meta 要素ではなく X-UA-Compatible ヘッダーフィールドの話をしています。 .htaccess ファイルを置けば X-UA-Compatible ヘッダーフィールドを追加できるのも知った上で、ウェブサーバー側の設定によって互換ビューを選択する方法を用意してほしかった、と書いたのです (#1519361 に書いた通り、 X-UA-Compatible: IE=EmulateIE7 と互換ビューは動作がわずかに違います。ウェブサーバー側で互換ビューを選択する機能がほしいと思った理由は両者の動作が違うこと以外にもありますが、細かい話なので省略)。
ところで、本題から外れますが、 HTTP ヘッダーの X-UA-Compatible フィールドより meta 要素の指定の方が優先されるのは知りませんでした。情報ありがとうございます。おっしゃる通り、マイクロソフトのドキュメントでは META Tags and Locking in Future Compatibility [microsoft.com] に
と書いてありますね。妥当な設計だと思います。