ふろしき Blog

コンテンツサービスを科学する株式会社ブートストラップ代表のブログ

IEのバージョンごとの機能の違い、選定の目安

f:id:furoshiki0223:20131210024028p:plain
私はIEの中の人ではないので、IE開発者がどういう考えを持っているかはわかりません。しかし、断言して言えることがあります。最近のIEは各バージョンで明らかに意図したテーマを持ち、リリースされています。

各バージョンのテーマを、運用するシステムの目的と照らし合わせれば、定量的にどのバージョンを選択すべきかが導出できるでしょう。

本記事は、これから企業システムで扱うIEのバージョンを上げなくてはいけない場合、また誰かにIEのバージョンごとの違いを説明しなくてはいけない場合、費用面・技術面の制約を説明しなくてはいけない場合に、ヒントを与えてくれるかもしれません。

バージョン別評価サマリ

バージョン別評価サマリでは、業務システムのクライアントとして扱われるIEが、各バージョンごとにどのような特性を持つかを超概算レベルで可視化しています。

項目は、長い目で見た費用効果を表す「コストパフォーマンス」、ニッチな要望に答えやすいかを判断する「機能性」、XP資産からの移植と維持に使う機能の豊富さを表す「移行容易性」の3つの観点で評価しています。

これらの裏付けは、次章以降にて説明します。

★ IE8

コストパフォーマンス
機能性
移行容易性

★ IE9

コストパフォーマンス
機能性
移行容易性

★ IE10

コストパフォーマンス
機能性
移行容易性

★ IE11

コストパフォーマンス
機能性
移行容易性

IE8 = 業務システムでは既にサポートが切れたブラウザ

★ 概要

IE8は「Web標準へ準拠するぞ!」と宣言し、現在のIE開発の流れを作ったブラウザです。しかし、IE7の癖を引きずり独自色を強く残しています。

IE7と8は、共通した挙動・不具合を含んでいることから、コードベースが殆ど同じに見えます。そして、機能面で見れば、DOCTYPEスイッチバグを除いて、IE6とIE7の間にインパクトの大きい変更点はあまり無いため、私はIE8を「少しまともになったIE6」と捉えています。
(※参考 : IE7と8で共通するPNG表示バグとその対策 - ふろしき.js )
(※参考 : IE6のDOCTYPEスイッチ不具合とその対策 - ふろしき.js )

機能面では、CSS2.1への対応強化が挙げられます。しかし、IE6-7と同様、IE8のみに個別で対応が必要になることを、Microsoftが暗に認めている時代のブラウザです。IE8向けコンテンツを他のバージョンのIEやブラウザと相互運用できるようにするために、バージョンベクタ・ユーザエージェント・ドキュメントモードなど、バージョンに付き纏う対策が求められています。IE11ではこれらの機能は既に非推奨/廃止されているため、IE8に特化した複雑なWebシステムは、実質的にIE8のEOLと同じになります。
(※参考 : バージョン ベクタ - Microsoft )
(※参考 : IE8 : ユーザー エージェント文字列 - Microsoft )
(※参考 : ドキュメント互換性の定義 - Microsoft )

XPからの移行の難しさで言えば、IE9-10よりも制約が強くなっています。XP資産の維持で広く利用されている「互換表示ボタン/リスト」が利用できないためです。実質的には「イントラネット互換表示」と「X-UA-Compatible」の合わせ技で対策するという方法しか選択できず、柔軟性を損なう移行となってしまいます。
(※ 参考 : イントラネット内で互換表示を有効にする方法 - ふろしき.js )
(※ 参考 : IE8のX-UA-Compatibleの使い方/動作仕様 - ふろしき.js )

★ 選定の目安

比較的長いライフサイクルとなりがちな業務システムを動かすためのプラットフォームに、Windows 7のEOLである2020年1月14日以降、利用できなくなることが確定しているものを選んでしまうのは得策とは言えません。そもそもですが、開発1年+運用5年の業務システムの世界では、今から作るシステムの対象ブラウザにIE8を選んでしまった場合、運用中にサポートが切れることが確定してしまっています
(※参考 : IE8向けWebシステムのEOLは、2020年1月を超えてはいけない )

このため、現在いかなる理由があっても、本バージョンを選択することは推奨されません。IE8向けWebシステムを作るような状況に陥らないよう、IT管理部門に依頼しIEのアップグレードを行うよう促すか、動作対象ブラウザにFirefoxなど他のモダンブラウザを選択するようにして下さい。どちらも無理であれば、コスト高にはなりますが、マルチブラウザ対策を行い、IE9移行の世代と相互運用できるような状態にして下さい。

これらの対策が行えなかった場合、Windows 8への移行に失敗する可能性が高く、IE8ブラウザやWindows7VMを購入し維持しなくてはいけなくなり、運用コストが最悪の状況に陥ります。

IE9 = 相互運用できるドキュメントビューワー

★ 概要

機能面では、ビジュアル面に力を入れています。CSS3への対応強化、HTML Canvas、SVGが挙げられます。また、オーディオ・ビデオをFlashなどのプラグインを使わずに動作させることができるのも、このバージョンからです。
(※参考 : Internet Explorer 9 の情報インデックス - Microsoft )

IE9からは、バージョン個別対応が必要な場合、Microsoftがこれまで提供してきたバージョンベクターやユーザエージェントの検出でなく、「機能/動作検出」を推奨しています。IE9向けにテストされており、なおかつ機能/動作検出の指針を守り開発されたWebシステムは、IE6-7や8向けにテストされたものよりも、断然にIEのバージョンアップやマルチブラウザ対応に強くなります。
(※参考 : IE9より推奨される機能/動作検出に関するドキュメント - Microsoft )

IE9は、ブログやニュースサイトなどのWebページの閲覧を目的とするのであれば、十分な機能性を確保しています。ただし、高度なオフライン処理・通信処理・入力フォームはサポートされていないため、FlexやSilverLight相当のRIAアプリケーションをWeb技術で代替するには、まだ十分なポテンシャルが確保できていないと判断できます。

IEは2バージョンごとに類似した動作傾向・バグの共有が行われるという傾向にありますが、IE9は10と類似する点を多く含みます。IE9で見つかった不具合は、同じコードベースでIE10で改善されている可能性があります。

XPからの移行では、IE9と10はWindows 7の持つ全バージョンのIEの中で最も多い機能を提供しており、豊富な手段の中から選択することができます。

★ 選定の目安

IE9は相互運用が可能なブラウザであるため、選定対象と含めるのに十分なポテンシャルを得ています。

IE8やIE11には、XPのWeb資産の維持を行う上で強い技術的制約を含んでいますが、IE9とIE10にはこれらの制約が無く、差もありません。特に理由がない場合、IE9よりもIE10を選択する方が無難でしょう。

IE10 = アプリケーションプラットフォーム

★ 概要

IE10は「アプリケーションプラットフォーム」としてのポテンシャルを持つブラウザです。

IE9までは、ブログやニュースサイト程度のWebページを扱う分には、十分のポテンシャルを持ちます。Webシステムの場合は、JSPのようなサーバサイドスクリプティングを扱うようなタイプのものです。

対してIE10は、HTML5機能の強化が図られており、特に業務系の場合、オフライン処理、高度な通信処理、フォームの機能性向上に注目されます。ちょっとしたニッチな要望にも、柔軟に答えやすいブラウザになっています。SPA(Single-page Application)のようなJavaScriptを多く含むWebシステムとして活用されることもIE10は想定済みであり、IE開発チームもこれを意識した性能面の対策を施しているものと考えられます。

XPからの移行では、IE9と10はWindows 7の持つ全バージョンのIEの中で最も多い機能を提供しており、豊富な手段の中から選択することができます。ただし、Quirksモードの動作に仕様変更があるため、移行にはほんの少しだけコツが必要になります。
(※参考 : IE6〜9とIE10とでQuirksモードの動作が違う )

注意点として、Visual Studio 2013を用いたシステム開発では、WebSocketが実装されたIE10以上が必須要件になっていることと、Java開発もJSFやProject AvatorなどWebSocketと結びついた技術が多く含まれています。IEは一つのOSに1バージョンしかインストールできないため、IE9や8を標準ブラウザとして採用すると、場合によってはMicrosoft/Java系開発に支障が生じ、全システムが実質的にレガシーJava、Ruby、PHPなどの開発にロックインされます。

★ 選定の目安

IE10は、XPからの移行で最も適したブラウザです。

移行の技術的制約は一番少なく、既存資産の維持機能は最も高いポテンシャルを持ち、IE10上で開発されたシステムはIE8と比較しても長いライフサイクルで動作させることができます。Quirksモードの仕様変更というリスクも含んでいてもなお、デメリットが少な過ぎるため、逆に心配になるレベルです。

IE11 = スマートデバイス向けWebプラットフォーム

IE11は、スマートデバイスが必要とする様々な機能を追加したブラウザです。

機能面では、IE10までが持っているHTML5対応が強化された機能へ、スマートデバイスの過酷な環境で高いユーザビリティを獲得するための機能を追加しています。例えば、ページの先読みや、画像などのリソース読み込みの優先付けなど、貧弱なネットワーク環境下で高いパフォーマンスを引き出すための機能を提供しています。

ただ、多くの追加機能はWindows 8モードと呼ばれる状態でないと発揮されません。Windows 8モードとは、スマートデバイスに特化したIEの表示モードで、Windows 7には提供されていない機能になります。デスクトップ用途であれば、IE10とそこまでポテンシャルに変化が無いブラウザともとれます。

XPからの移行では、最も相性が悪いバージョンです。XP時に開発したIE6向けシステムは、通常ドキュメントモードを利用することで維持させます。しかし、IE11はこれが非推奨であるため、移行には全てのシステムの画面周りの改修、入念な動作テストが必要になります。ドキュメントモードは内部的に残されており、強引に動作させることも可能ですが、品質は良くなく、CSS Expressionsのようなレガシーシステム定番の廃止機能も動作方法次第では動かないなどの問題を抱えています。非推奨機能であるため、今後改善が行われる可能性も低いという状況です。
(※参考 : ドキュメント モードの非推奨 - Microsoft )

★ 選定の目安

このバージョンは、現時点で最新であるものの、XPからの移行の選定に含めるべきかは微妙なラインです。どちらかと言えば、移行後の開発システムが、Windows 7のEOL時にこのバージョンのIEで動作できる状態にできていることに重要な意味を持ちます。

IE11は、Windows 8系OSでは、実質的に最低バージョンのIEとなります。Windows 8はドキュメントモードが非推奨であるため、Windows 7から次版のOSへ移行を行うタイミングで、全システムが互換表示機能やX-UA-Compatibleに頼らず、11の最新のレンダリングエンジンで動作可能な状態になっていなくてはいけません。

Active Directory周りでまだまだ進化中のスマートデバイス向けWindowsですが、企業システムのIT管理者による統合管理の必要性を鑑みると、その実用性の高さから適用される可能性が高いでしょう。Windows系スマートデバイス(タブレット)を利用した場合、IE11へのアップグレードは必須の要件と言えます。IE11には、貧弱なネットワーク回線、タッチパネルとの親和性向上のため、多くの機能が追加され改善されています。ユーザ体験ではなく、性能という可視化される分野での強化が、強みになっているブラウザです。
(※参考 : 11分で覚える、IE11対応Web制作のカンニングペーパー(前篇) - さぶみっと )

>> HTML5/IE11対応 - Webシステム・ガイドライン集

IE11リリースによる本当の危機、その後のSIのやるべきこと

私が以前執筆した記事「意外と知られていない、IE11リリースによる本当の危機」がかなり好評でしたので、執筆者としてもう少しだけ言葉を残してみようと思います。

なぜQuirks?と考えたことはあるだろうか

Webシステムでは、わざとQuirksを使うというバッドプラクティスがどこでも横行しているでしょう。必然的に、そうならざる得ないケースがあったからです。マルチバージョン対応を最小のコストで行う方法として、Quirksが最も優れてしまったのというのが最大の要因です。

かつてWinXPの時代、6/7/8で同じ機能性が確保された無菌室状態のレンダリングモードはQuirksだけでした。IEのみしかいない世界では、Quirksに逃げられてしまう可能性があることを想定できていなかったのは、IE側のミスだったと言えます。IEは、バージョン間の相互運用性が確保できていないと暗に認めてしまうような機能を実装した時点で、X-UA-Compatibleを実装すべきだったのです。IEは自信を持って相互運用性が確保できたと言える状況になるまで、マルチバージョン対応の最善の方法にQuirksという抜け道を作ってはいけなかったのです。

しかしIEもまた、日本のSIのような、IE内だけでマルチバージョン対応を行うというレアケースを想定することは難しかったでしょう。日本のSIがWebでシステムを作ってしまった時点で、コストと正しさを両立できない仕組みを作ってしまった時点で、「あえてのQuirks」は必然的に止められなかったのでしょう。

正しさとコストを両立できるまでの6年

IE11のリリースで、Win7の時代にQuirksアプリをわざわざ開発する理由は失われてしまいました。問題は、Quirksを使うことが当たり前過ぎて、Quirksが何なのかをわかっていないような人がいるケース。そしてそれを、要件フェーズや品質管理側からコントロールできていないケースなのかもしれません。

今後のWebシステム開発では、IEの段階的なアップグレード計画、開発・移行を行うシステムのドキュメントモードのレベルの設計、テスト対象ブラウザについても、企業の持つシステム全体をトータルに見た上で、SI側がコンサルタントできないといけないはずです。そうしないと、6年後は最悪な状態に陥るでしょう。企業はWindowsのアップグレードを、諦めざる得ない状況になってしまうのです。専用に別の端末を確保し維持するという、コストパフォーマンスとして最悪の状態に陥るでしょう。

この6年をしっかりと設計し、全システムが見事IE10以上への移行に成功したのならば。バージョン検出やドキュメントモードでなく「機能/動作検出」による汎用的なWebシステムを作り上げたのであれば、HTML5の標準的プラットフォームにより、正しい方法で長いライフサイクルに耐えるシステムとなるはずです。

既存システムはコスト最適化させなくてはいけないというこの状況下で、Web開発を行うSIのコンサルタントにとっての、腕の見せどころなのかもしれません。

IE11を裏ワザ的なやり方でDOCTYPEスイッチを有効化する方法

IE11はDOCTYPEスイッチが機能しません。これは恐らく、ドキュメントモードが非推奨へ変わったからでしょう。
(※参考 : ドキュメント モードの非推奨 - Microsoft )

しかしIEはまだ、Quirksモードを内部的に残しています。今までとは異なる手段にはなりますが、有効化することが可能です。ただし、ドキュメントモード非推奨化に伴い、Quirksモードは表向きなくなったという扱いです。「Quirksモード」という表現は、IE11のどこを探しても見つかりません。こうした扱いの変化もあり、制御には少しだけコツが必要です。

内部ドキュメントモードとその表現方法の違い

IE11が内部的に備えている全てのドキュメントモードは、以下の通りです。

  • IE5モード
  • IE7モード
  • IE8モード
  • IE9モード
  • IE10モード+Quirksレイアウト
  • IE10モード
  • Edgeモード(※ IE11の動作)

「IE5モード」は、IE6〜9で提供されていた「Quirksモード」と、IE10で提供されていた「IE5 quirksモード」と同じ扱いのものです。基本的にはIE5の動作をエミュレートします。

対して「IE10モード+Quirksレイアウト」とは、IE10で提供されていた、HTML5との相互運用を図るため機能追加が行われたQuirksモードです。IE10で提供されていたQuirksモードは、IE5との互換性が無いことをMicrosoftが公表しています。
(※参考 : 相互運用可能な (HTML5) Quirks モード - Microsoft )

F12開発者ツールから見えるドキュメントモードは、以下の項目になります。

f:id:furoshiki0223:20131127192830p:plain

5/7/8/9/10/Edgeと、6つにしか見えません。

IE11では、IE10モード+Quirksレイアウトが有効時、表向きには「IE10」という表示がされます。逆にIE10モード+Quirksレイアウトを有効にしたい場合、F12開発者ツールからはそれを指定することができなくなっています。

IE10モード+Quirksレイアウトを有効にするには、X-UA-CompatibleとDOCTYPEスイッチによる合わせ技が必要になります。そしてその指定方法は、Quirksモードとそうでないものが混在するWebシステムを11へ移行した際に、意図せず有効化させてしまう可能性が高い組み合わせであるため、取り扱いには注意が必要です。

X-UA-CompatibleとDOCTYPEスイッチ動作一覧

IE11のX-UA-Compatibleと、DOCTYPEスイッチによるStandard/Quirksモードの切り替えに伴う内部ドキュメントモードは、以下の一覧の通りです。縦軸はX-UA-Compatibleのパラメータ、横軸はDOCTYPEスイッチによる状態切替を表します。

Standard Quirks
5 IE5モード IE5モード
7 IE7モード IE7モード
8 IE8モード IE8モード
9 IE9モード IE9モード
10 IE10モード IE10モード
11 IE11モード IE11モード
EmulateIE7 IE7モード IE5モード
EmulateIE8 IE8モード IE5モード
EmulateIE9 IE9モード IE5モード
EmulateIE10 IE10モード IE10モード+Quirksレイアウト
EmulateIE11 IE11モード IE11モード
Edge IE11モード IE11モード

>> DOCTYPEスイッチの切替条件は、IE10と同じです

最善の対策はあくまで「改修」

X-UA-Compatibleは、HTTPレスポンスヘッダとHTML無いのmeta要素の2箇所で定義されますが、常に後者が優先されます。このため、複数のドキュメントモードを同一システム内で混在させた場合、新しいIEへのバージョンアップにドキュメントモードを活用するケースでは、HTTPレスポンスヘッダを利用することになるでしょう。

IE10モード+Quirksレイアウト特化のシステムは滅多に開発されないことが想定されるため、IE11以降、トラブルを避けるためEmulateIE系のパラメータは利用しないことをオススメします。

そもそもですが、IE11からはドキュメントモードは非推奨です。Microsoftはこれまで一時的な対応策としてこの方法を提供してきましたが、IE12以降は機能として削除される可能性があります。Windows8系では定期的にIEのバージョンアップが強制されるため、本対策を利用してさらにシステムの延命を図ろうとしているのであれば、そのシステムは短命に終わる可能性が高いでしょう。本対策が必要なタイミングはごく稀であると認識して下さい。

正しい移行の方法は、改修を行うことです。

意外と知られていない、IE11リリースによる本当の危機

Internet Explorerはエンタープライズでの利用が想定されるため、Microsoft製品で広く適用されているサポート ライフサイクル ポリシーを確認すると、最低でも10年のサポートが受けられると考えている人も多いでしょう。IE8も9も10も、みんなそうなると信じて疑わないIT管理者の方も多いのではないでしょうか。

しかし、これは「誤り」です。

本記事では、最近やたらと複雑化の進んだIEのサポート期間の真実について解説します。

サポートライフサイクルポリシーとは?

そもそもですが、Microsoftの「サポートライフサイクルポリシー」とは何でしょうか。公開しているドキュメントを参照すると、以下の通りです。

マイクロソフトはビジネス、開発用製品に対して最短でも 10 年間のサポートを提供します。ビジネス、開発用製品に対するメインストリーム サポートは、製品発売後 5 年間または次期製品 (N+1) の発売後 2 年間のどちらか長い方の期間提供します。マイクロソフトは、メインストリーム サポート終了後 5 年間または次々期製品 (N+2) の発売後 2 年間のどちらか長い方の期間延長サポートを提供します。最終的に、ビジネス、開発用のほとんどの製品は最短でも 10 年間のオンライン セルフヘルプ サポートを受けることになります。

(※参考 : http://support.microsoft.com/gp/lifepolicy/ja)

Microsoft製品にはメインストリームサポートと延長サポートの2つの考え方があります。

  • メインストリームサポート : 不具合改善+セキュリティアップデート。
  • 延長サポート : セキュリティアップデートのみ。

ざっくりと説明すると、上記の通りです。製品ごとにちょっとした違いもあるようですが、多くの製品の共通点を集約すれば上記の通りでしょう。電話やメールのサポートについて、メインストリームの期間は受け付けてくれますが、延長期間は本当に最小のサポートしかされないため、セキュリティアップデートのみです。他は受け付けてくれません。

メインストリームサポートは、製品が発売されてから5年で、その後はもう5年の延長サポートへ移ります。MicrosoftはN+1というサポートシステムを持っているため、実際には5年以上に伸びることもありますが、頻繁にバージョンアップを行っている場合は、5年とみなすべきです。

つまり、Microsoftのビジネス製品は、メインストリーム5年+延長サポート5年の合計である、10年のサポートが受けられると考えるのが自然でしょう。

サービスパックポリシーという罠

IEは動作するプラットフォームがOSに強く依存するブラウザです。OSによって、動作しないバージョンがあることは広く知られているでしょう。Windows XPであればIEは6〜8しか動きませんし、Windows 7であればIEの8〜11が動作します。IEは実質的に、OSのサポート期間が全てということになります。

現在多くの企業システムとしても採用されているWindows7上で動作するIEは、Windows7のサポート期間の縛りを受けることになります。Windows7は2013年11月現在、サポート期間は2020年1月14日までなので、約6年2ヶ月のサポートがあります。

Windows8は先月アップデートされWindows8.1になりましたが、このアップデートにはサービスパックポリシーとして扱われます。Windows XPで言うところのSP1→SP2のような扱いです。サービスパックポリシーは製品のアップデートが行われると24ヶ月以内に実施しないとサポートが切れるため、実質的に次の移行先OSはWindows8.1以上ということになります。

実はIE10、残り6年しかサポートが無い

Windows8.1で強制的にアップグレードされたIE11には、今までにない特徴が2つほど含まれています。

  1. OSはサービスパックポリシー程度のアップデートなのに、IEはアップグレード相当のバージョンアップ
  2. IE11からはドキュメントモードが非推奨になった

IE9の時点で既に例外が生じていましたが、最近のIEはアップグレード速度が速いため、OSのアップグレードとセットになっていません。OSが1バージョン上がるまでに、2回以上のバージョンアップを行うのが普通になりました。そして今回、IE11はWindows8.1へのアップデートで、アップグレードが必須になっています。つまり、次の移行先OSは、IE11以上で確定です。

そしてIE11からの大きな特徴、それは「ドキュメントモード」の非推奨です。これまでの企業システムは、IEの持つドキュメントモードの力を借りて、IE6でテストされたシステムをIE8へ移行できていました。多くの企業システムは、イントラネット互換表示という機能を利用し、IE8/9/10で、IE7相当の動作をエミュレートさせることで、IE6向けWebシステムを保護してきました。

しかし今回、IE11からはドキュメントモードが廃止になり、イントラネット互換表示も公式として推奨されない手段になってしまいました。実際にIE11からは、過去のレンダリングエンジンの動作はあまりテストされていないようで、多くの不具合が確認されています。実質的にIE11では、ドキュメントモードに頼ってはいけないという状況でしょう。

企業のレガシーWebシステムの寿命はあと6年

もうお分かりでしょう。

IE11は動作の不安定などを注目する人が多いようですが、本当の危険はそこではありません。最大の危機、それは企業がレガシー資産を残り6年で入替えなくてはいけないことです。大企業だと5年単位でIT資産の運用指針を決定するでしょうし、そもそも企業システムは開発1年運用5年の世界なので、今作っているものも対策を行わなくてはいけません。実はとても時間が無いのです。

これまで企業システムは、サーバのミドルウェア製品こそ最新でお作法を守ったプログラミングを心がけているようですが、フロントエンドは相互運用性が失われ、マネジメントのコントロールを外れた手段が横行していたようです。しかしそれもここまでのようです。

近年、IE6資産の維持のためにWindowsXPのVMを購入する企業、IE6互換のサードパーティベンダ製品を購入しているといった事例もあるようですが、長期的にはコスト効果の低い対策となっています。とはいえ、今の時代になってもOS依存のコーディングを防ぐ明確な手段が存在しないため、完全な解決手段も無いという状況です。

レンダリングエンジンのレイヤーは、Compat InspectorやFidlerといったツールの力を借りて相互運用性のテスト手段が確立されつつあります。IE8以降、Web標準への準拠を高め、IEは高い相互運用性を確保できました。プロジェクトが正しい手法でフロントエンドを開発していた場合、ドキュメントモードの存在はそこまで大きな問題にならないはずです。

しかしどうしても乗り越えられない壁である、OS依存の問題。ドキュメントモードが存在しているにもかかわらず、WindowsXPから7へ上手く移行出来ない理由として、ここが強く関わっていると思います。テキストの出力方法から、WindowsAPI依存の技術と、IEは多くの機能をOSへ依存させています。

OSというレイヤーとどのように向き合うべきか、今後の議論はそこにフォーカスされるのかもしれません。

イントラネット内で互換表示を有効にする方法(IE8/IE9/IE10/IE11)

IEの8〜11では、イントラネットゾーンで互換表示(IE7との互換動作)を有効にする機能を持ちます。

イントラネットとは、企業システムをWebベース(Internet Explorerの利用)で構築した場合に、企業内と企業外のネットワークで別のポリシーを適用するために作られたWindows固有の考え方です。多くの企業システムでは、Webシステムの互換性の保持のために利用されている鉄板とも言える設定情報です。

これを利用すれば、企業システムのみを互換表示で保護することが可能です。WindowsXPからWindows7へ移行した際に、IE6/7向けに作られたWebシステムをアップグレードされたレンダリングエンジンでも動作させるために活用されています。

本記事では、イントラネット互換表示機能について解説します。

  1. 設定方法
    1. 「互換表示設定」でのチェック
    2. 「インターネットオプション」への設定
  2. 確認方法
  3. 利用上の注意点

1. 設定方法

★ 1.1.「互換表示設定」でのチェック

「互換表示設定(B)」を開きます。

  • IE8 : コマンドバーの「ツール(T)」を選択して下さい。
  • IE9/10 : Altキーを押下するとコマンドバーが表示され、「ツール(T)」を選択すると操作が行えるようになります。
  • IE11 : 右上の歯車をクリックすると、「互換表示設定(B)」が選択できます。

f:id:furoshiki0223:20131124063653p:plain

「イントラネット サイトを互換表示で表示する(I)」にチェックが入っていることを確認して下さい。
f:id:furoshiki0223:20131125043356p:plain

★ 1.2. 「インターネットオプション」への設定

まず、「インターネットオプション」を開きます。

  • IE11 : 右上の歯車をクリックすると、「インターネットオプション(O)」が選択できます。

f:id:furoshiki0223:20131125045424p:plain

a. ドメインを直接指定してイントラネットを定義する場合

「詳細設定(A)」をクリックし、「この Web サイトをゾーンに追加する(D)」へURLを登録します。
f:id:furoshiki0223:20131125045836p:plain
f:id:furoshiki0223:20131125045846p:plain

b. プロキシサーバを介さないアクセスをイントラネットと定義する場合

「イントラネットのネットワークを自動的に検出する(D)」からチェックを外し、「プロキシ サーバーを使用しないサイトをすべて含める(P)」へチェックします。
f:id:furoshiki0223:20131125045902p:plain

2. 確認方法

実際に、イントラネットで定義されたドメイン/URLのサイトへアクセスして下さい。

★ IE8/IE9/IE10の場合

「F12」を押下し、「F12開発者ツール」を表示して下さい。ドキュメントモードが「IE7」であれば、正常です。
f:id:furoshiki0223:20131125054620p:plain

★ IE11の場合

「F12」を押下し、「F12開発者ツール」を表示して下さい。左のデスクトップPCのようなアイコンをクリックし、右のウィンドウに以下のような表示があることを確認して下さい。
f:id:furoshiki0223:20131125052807p:plain

3. 利用上の注意点

★ 機能永続性の問題

IE11からはドキュメントモードが非推奨となったため、推奨される手段ではありませんが、機能としては残っています。本機能は、今後のIEではサポートされない可能性があるため、取り扱いには注意が必要です。

段階的に、企業システムをIE10以降が提唱するバージョンに依存しないWeb開発へと移行させる必要があります。

(※参考 : ドキュメント モードの非推奨 - Microsoft )

互換表示機能をWindowsレジストリを利用して無効化する方法(IE8/IE9/IE10/IE11)

IEには「互換表示ボタン」や「互換表示一覧(リスト)」を通じて、サイトのドメインごとに互換表示機能の有効/無効を切り替える機能を持っています。

企業システムでの用途の場合、この機能をIEの利用者側で制御して欲しくないという要望もあるでしょう。この場合、Windows(XP/7)のレジストリ編集により対策することが可能です。ただし、X-UA-Compatibleによるブラウザモード制御や、イントラネット互換表示機能までは本設定による影響を与えません。

本記事では、Windowsレジストリを利用した互換表示機能の無効化方法について説明します。

  1. 設定方法
  2. 確認方法

(※ 以下の手順は、WindowsXPも7も共通です。)

1. 設定方法

[Winキー]+[R]で「ファイル名を指定して実行」ウィンドウを開きます。名前に「regedit」を入力し、「OK」ボタンをクリックして下さい。
f:id:furoshiki0223:20131125032747p:plain

「HKEY_CURRENT_USER\Software\Policies\Microsoft」へ移動します。
f:id:furoshiki0223:20131125050940p:plain

1.1. キー「Internet Explorer」を登録

※「Internet Explorer」が既に作成されている場合は、本手順は不要です。

「Microsoft」を右クリック、「新規(N)」→「キー(K)」を選択。
f:id:furoshiki0223:20131125033526p:plain

「Internet Explorer」と入力し、Enterキーを押下。(※InternetとExplorerの間は半角スペース)
f:id:furoshiki0223:20131125033535p:plain

1.2. キー「BrowserEmulation」を登録

※ 「BrowserEmulation」が既に作成されている場合は、本手順は不要です。

「Internet Explorer」を右クリック、「新規(N)」→「キー(K)」を選択。
f:id:furoshiki0223:20131125033909p:plain

「BrowserEmulation」と入力し、Enterキーを押下。(※BrowserとEmulationの間にはスペース無し)
f:id:furoshiki0223:20131125034023p:plain

1.3. 「DisableSiteListEditing」を登録

「BrowserEmulation」を左クリックで選択し、右のウィンドウの開いているスペースで右クリック。「新規(N)」→「DWORD値」を選択。Windows7の場合は、32bit版を選択して下さい。
f:id:furoshiki0223:20131125034210p:plain

「DisableSiteListEditing」と入力し、Enterキーを押下。
f:id:furoshiki0223:20131125034322p:plain

「DisableSiteListEditing」をダブルクリックし、「値のデータ(V)」へ「1」と半角で入力、「OK」をクリック。
f:id:furoshiki0223:20131125034417p:plain

これで完了です。F5を押下し更新するとより良いでしょう。

2. 確認方法

IEを一度再起動し、「ツール」→「互換表示設定」を開いて下さい。(※IE9/10の場合は、Altキーを押下すると、コマンドバーが出現しツールを選択できるようになります。)

以下のように、「このWebサイトの追加(D)」と「互換表示に追加したWebサイト(W)」の両方の右にあるボタンが非アクティブであれば、設定は正常に反映されています。

f:id:furoshiki0223:20131125034543p:plain

IE11のX-UA-Compatibleの使い方/動作仕様

IE11では、X-UA-Compatibleという制御パラメータを利用し、過去のWebブラウザの機能をエミュレートさせることができます。

本記事では、X-UA-Compatibleの利用方法について解説します。

  1. 動作の仕様
  2. 設定方法
    1. HTMLドキュメント内にX-UA-Compatibleを追加する
    2. ApacheでHTTPレスポンスヘッダにX-UA-Compatibleを追加する
    3. IISでHTTPレスポンスヘッダにX-UA-Compatibleを追加する

1. 動作仕様

  • IE=EmulateIE11 : 常にIE11モードとして動作する。
  • IE=EmulateIE10 : 常にIE10モードとして動作する。(※製品不具合)
  • IE=EmulateIE9 : DOCTYPE宣言に応じて、IE9モードかQuirksモード(IE5)を選択する。
  • IE=EmulateIE8 : DOCTYPE宣言に応じて、IE8モードかQuirksモード(IE5)を選択する。
  • IE=EmulateIE7 : DOCTYPE宣言に応じて、IE7モードかQuirksモード(IE5)を選択する。
  • IE=11 : 必ずIE11モードを選択する。
  • IE=10 : 必ずIE10モードを選択する。
  • IE=9 : 必ずIE9モードを選択する。
  • IE=8 : 必ずIE8モードを選択する。
  • IE=7 : 必ずIE7モードを選択する。
  • IE=5 : 必ずIE5モードとして動作する。

>> IE10のDOCTYPEスイッチによるStandard/Quirksモードの切り替え一覧表

2. 設定方法

X-UA-Compatibleの設定は、HTMLドキュメント上で設定するか、HTTP レスポンスヘッダで設定するかのどちらかを選択できます。

★ HTMLドキュメント内にX-UA-Compatibleを追加する

HTMLドキュメント内で記述する場合は、head要素内の比較的最初で以下を定義します。

<meta http-equiv="X-UA-Compatible" content="IE=11">

★ ApacheでHTTPレスポンスヘッダにX-UA-Compatibleを追加する

RHEL/CentOS/FedoraでApache HTTP Serverを利用している場合は、「/etc/httpd/httpd.conf」にて、一番最後に以下の内容を追記して下さい。

LoadModule headers_module modules/mod_headers.so
<IfModule headers_module>
   Header set X-UA-Compatible: IE=11
</IfModule>

Apacheに「mod_headers.so」がバンドルされていない場合はエラーになります。予め、インストールして下さい。

★ IISでHTTPレスポンスヘッダにX-UA-Compatibleを追加する

MicrosoftのWindows系OSで「インターネット インフォメーション サービス(IIS)」を利用している場合は、以下の手順になります。

「コンピュータの管理」→「インターネット インフォメーション サービス(IIS) マネージャー」
f:id:furoshiki0223:20131112210814p:plain

「HTTP応答ヘッダー」
f:id:furoshiki0223:20131112210923p:plain
表示内で右クリック、「追記」を左クリック
f:id:furoshiki0223:20131112211023p:plain
「名前(N):」へ「X-UA-Compatible」、「値(V):」へ「IE=11」
f:id:furoshiki0223:20131125014426p:plain

IE11のEmulateIE10(X-UA-Compatible)でDOCTYPEスイッチに不具合がある(→仕様でした)

(※ 本ドキュメントは古い情報です。正確な仕様は、こちらを参照して下さい。)

IE10までは、「X-UA-Compatible」に対して、「IE=EmulateIE」で指定された対象バージョンのドキュメントモードでは、DOCTYPEスイッチの条件に従いQuirksモードへの切り替えを行っていました。

「IE=EmulateIE10」と指定した場合、Microsoftの公開している仕様に準ずるなら、以下のURLのDOCTYPEスイッチの条件に従う必要があるはずです。

IE10のDOCTYPEスイッチによるStandard/Quirksモードの切り替え一覧表

↓ Microsoftの提供するEmulateIEの仕様
X-UA-Compatibility Meta Tag and HTTP Response Header - Microsoft Developer Network

しかしIE11では、「IE=EmulateIE10」の場合に限り、DOCTYPE宣言を確認せず常にIE10として動作するという不具合があります。これを改善するには、Quirksモードとして動作が必要なWebコンテンツに対して、「IE=EmulateIE9」以下を指定するか「IE=5」と直接指定することで対処する必要があります。

※2013/11/24 : この不具合は、筆者がMicrosoft Connectへ報告しています。
IE11 - BUG / DOCTYPE switch does not work, when I use "IE=EmulateIE10". - Microsoft Connect
※2013/11/27 : えむけい氏の指摘により、本動作は仕様であることが確認されました。

IE11の互換表示リスト(互換表示一覧)の使い方/動作仕様

IE11には、正常な動作が行えない古いWebコンテンツを利用できるようにするために、「互換表示リスト(互換表示一覧)」という機能が提供されています。

本記事では、「互換表示リスト(互換表示一覧)」の動作仕様について説明します。

  1. 互換表示設定から追加
  2. リストに追加すると何が起こるのか?
  3. 互換表示リストの設定内容を無効化させる方法

1. 互換表示設定から追加

Altキーを押下すると、コマンドバーが表示されます。その後、以下の手順に沿って入力して下さい。
f:id:furoshiki0223:20131124063653p:plain
ウィンドウ「互換表示設定」が表示されるので、以下を設定します。
f:id:furoshiki0223:20131124063706p:plain

※ IE8〜10には「互換表示ボタン」という機能があり、これを利用すれば互換表示リストへの登録が簡単に行えましたが、11からは削除されています。

2. リストに追加すると何が起こるのか?

常に、IE7 Standardモード(IE7の機能のエミュレート)として動作します。

3. 互換表示リストの設定内容を無効化させる方法

★ ドメイン単位での無効化(開発者向け)

X-UA-Compatibleへ以下の値を設定すると、互換表示リストへの追加は無視されます。

  • IE=EmulateIE11 : 最新のレンダリングエンジンで動作。
  • IE=EmulateIE10 : IE10モードで動作。(※製品の不具合動作)
  • IE=EmulateIE9 : DOCTYPE宣言に応じて、IE9モードかQuirksモード(IE5)を選択する。
  • IE=EmulateIE8 : DOCTYPE宣言に応じて、IE8モードかQuirksモード(IE5)を選択する。
  • IE=EmulateIE7 : DOCTYPE宣言に応じて、IE7モードかQuirksモード(IE5)を選択する。
  • IE=11 : 最新のレンダリングエンジンで動作
  • IE=10 : IE10の機能をエミュレートするレンダリングエンジンで動作
  • IE=9 : IE9の機能をエミュレートするレンダリングエンジンで動作
  • IE=8 : IE8の機能をエミュレートするレンダリングエンジンで動作
  • IE=5 : IE5の機能をエミュレートするレンダリングエンジン(Quirksモード)で動作

IE11には一部不具合が含まれていますが、Quirksモードへの遷移条件はIE10と同じです。
>> IE10のDOCTYPEスイッチによるStandard/Quirksモードの切り替え

X-UA-Compatibleの設定は、HTMLドキュメント上で設定するか、HTTP レスポンスヘッダで設定するかのどちらかを選択できます。設定の方法は、以下を参照して下さい。

>> IE11のX-UA-Compatibleの使い方/動作仕様

★ 全てのリストを無効化(IT管理者向け)

Windowsレジストリを利用して、無効化する方法もあります。

>> 互換表示機能をWindowsレジストリを利用して無効化する方法

IE10の互換表示リスト(互換表示一覧)の使い方/動作仕様

IE10には、正常な動作が行えない古いWebコンテンツを利用できるようにするために、「互換表示リスト(互換表示一覧)」という機能が提供されています。

本記事では、「互換表示リスト(互換表示一覧)」の動作仕様について説明します。

  1. 設定方法1 - 互換表示ボタンからの追加
  2. 設定方法2 - 互換表示設定から追加
  3. リストに追加すると何が起こるのか?
  4. リストへ追加されても、互換表示させない方法

1. 設定方法1 - 互換表示ボタンからの追加

アドレスバーの右にある、割れたアイコンのボタンをクリックして下さい。

f:id:furoshiki0223:20131124035233p:plain

>> (詳細はこちら)IE10の互換表示ボタンの使い方/動作仕様

※互換表示ボタンがアドレスバーの横に表示されない場合、次の手順が必要です。

2. 設定方法2 - 互換表示設定から追加

Altキーを押下すると、コマンドバーが表示されます。その後、以下の手順に沿って入力して下さい。
f:id:furoshiki0223:20131124063653p:plain
ウィンドウ「互換表示設定」が表示されるので、以下を設定します。
f:id:furoshiki0223:20131124063706p:plain

3. リストに追加すると何が起こるのか?

動作モードに応じて、以下のような振る舞いをします。

  • Standardモードの場合 : IE7 Standardモード(IE7の機能のエミュレート)として動作します。
  • Quirksモードの場合 : IE5 quirksモード(IE5の機能のエミュレート)として動作します。(※デフォルトのQuirksモードは、IE5と完全な互換性を持ちません。)

StandardモードとQuirksモードについては、以下のドキュメントを参照して下さい。
>> IE10のDOCTYPEスイッチによるStandard/Quirksモードの切り替え

4. リストへ追加されても、互換表示させない方法

★ ドメイン単位での無効化(開発者向け)

X-UA-Compatibleへ以下の値を設定すると、互換表示リストへの追加は無視されます。

  • IE=EmulateIE10 : DOCTYPE宣言に応じて、IE10モードかQuirksモード(IE5)を選択する。(※実質的無効化)
  • IE=EmulateIE9 : DOCTYPE宣言に応じて、IE9モードかQuirksモード(IE5)を選択する。
  • IE=EmulateIE8 : DOCTYPE宣言に応じて、IE8モードかQuirksモード(IE5)を選択する。
  • IE=EmulateIE7 : DOCTYPE宣言に応じて、IE7モードかQuirksモード(IE5)を選択する。
  • IE=10 : 最新のレンダリングエンジンで動作
  • IE=9 : IE9の機能をエミュレートするレンダリングエンジンで動作
  • IE=8 : IE8の機能をエミュレートするレンダリングエンジンで動作
  • IE=5 : IE5の機能をエミュレートするレンダリングエンジン(Quirksモード)で動作

>> IE10のDOCTYPEスイッチによるStandard/Quirksモードの切り替え

X-UA-Compatibleの設定は、HTMLドキュメント上で設定するか、HTTP レスポンスヘッダで設定するかのどちらかを選択できます。設定は、以下を参照して下さい。

>> IE10のX-UA-Compatibleの使い方/動作仕様

★ 全てのリストを無効化(IT管理者向け)

Windowsレジストリを利用して、無効化する方法もあります。

>> 互換表示機能をWindowsレジストリを利用して無効化する方法

IE6〜9とIE10とでQuirksモードの動作が違う、どうすれば解決できるか?

古いWebコンテンツを動かすため、IE6からQuirksモードという機能が追加されました。QuirksモードはIE5の動作をエミュレートすることができる機能です。しかし、IE10からQuirksモードでもHTML5の機能が動作するよう仕様に修正が加えられたため、動作に違いが生じることがあります。
(※参考 : 相互運用可能な (HTML5) Quirks モード - Microsoft)

IE10ではこの問題に対応するため、無印の「Quirksモード」と「IE5 Quirksモード」と2種類のQuirksモードを提供しています。もし今まで利用できていた古いWebコンテンツが、IE10以降から正常に動作しなくなった場合、ドキュメントモードを「IE5 Quirksモード」へ切り替えるため、以下の手順を試して下さい。

  1. 互換表示ボタンの利用(ユーザ向け)
  2. 互換表示リストへの追加(ユーザ向け)
  3. X-UA-Compatibleを利用する(開発者向け)

1. 互換表示ボタンの利用(ユーザ向け)

元々Quirksモードで動作していたサイトでは、アドレスバーのすぐ右に「互換表示ボタン」が付いています。このボタンをクリックすると、QuirksモードはIE5 Quirksモードへ状態遷移します。

f:id:furoshiki0223:20131122001408p:plain

2. 互換表示リストへの追加(ユーザ向け)

以下の手順に従い、設定を試してみて下さい。

IEのウィンドウ右上にある「歯車アイコン」をクリックし、「互換表示設定(B)」をクリック。
f:id:furoshiki0223:20131111201907p:plain

ドメイン名を入力し、「追加」をクリック。
f:id:furoshiki0223:20131111202037p:plain

閉じるをクリックすると、IEは再びロードを開始し、古いレンダリングエンジンによる動作を開始します。IE11では、「互換表示設定」にて指定されたドメイン名(URL)のWebサイトは、「IE7」の動作を再現させます。

3. X-UA-Compatibleを利用する(開発者向け)

IE10では、X-UA-Compatibleの値を「IE=5」で指定すると、「IE5 quirksモード」が適用されます。

設定方法については、以下のページを確認して下さい。

>> IE10のX-UA-Compatibleの使い方/動作仕様

IE11には互換表示ボタンが無い、どうすれば解決できるか?

IE8から10では、「互換表示ボタン」という機能がありました。古いWebコンテンツは、IEの利用者が互換表示をオンにすることでIE7/IE5の動作をシミュレートさせ、Webページを表示できるようにしていました。

f:id:furoshiki0223:20131122001408p:plain

しかし、IE11では互換表示で利用するドキュメントモード機能が非推奨というステータスに変わったため、互換表示ボタンも表示されなくなりました。
(※参考 : ドキュメント モードの非推奨 - Microsoft)

この仕様変更によりWebページが正常に表示出来ない場合、Microsoftの公式の見解としては、コンテンツの制作/開発者が改善を行わなくてはいけないことになっています。IE12以降はこの機能が廃止される可能性もありますが、それまでの間IE11でなんとか動作させたいというケースがあるでしょう。

その場合、以下の方法を参考に解決策を探ってみて下さい。

ユーザ側での対応策

以下の手順に従い、設定を試してみて下さい。

IEのウィンドウ右上にある「歯車アイコン」をクリックし、「互換表示設定(B)」をクリック。
f:id:furoshiki0223:20131111201907p:plain

ドメイン名を入力し、「追加」をクリック。
f:id:furoshiki0223:20131111202037p:plain

閉じるをクリックすると、IEは再びロードを開始し、古いレンダリングエンジンによる動作を開始します。IE11では、「互換表示設定」にて指定されたドメイン名(URL)のWebサイトは、「IE7」の動作を再現させます。

古いWebシステムの維持は「互換表示」から「改修」へ

近年、HTML5というキーワードが世の中を騒がせています。それと同時に、Webブラウザやその上で動作するインタラクティブなコンテンツは、プラグインからWeb標準へその手段を徐々に移行しつつあります。

しかし一方で、利用者側のIEのバージョンがなかなか上がらないため、その恩恵は全く受けれていないと考えている人も多いのではないでしょうか。HTML5はHTML CanvasやWebSocketのような派手な機能に目が行きがちですが、開発者にとっての真のメリットは、Webブラウザをオープン性の高いプラットフォームへ変化させたこと、そしてそれがWeb開発の現場が抱えていた問題を改善へ向けた点にあります。

改善の結果、IE11からはライフサイクルの長いWebシステムの維持の考え方を大きく見直しました。本記事では、IE11で打ち出したドキュメントモードの非推奨化の考え方と、既存のWebシステム維持方法の変更点について解説します。

1. IEの設計方針の変化

★ 1.1. 「XHTML1.0」→「HTML5」

HTML4.01、XHTML1.0の時代は、Webはポータビリティの高いドキュメント集であり、Webブラウザもただのドキュメント表示ツールでしかありませんでした。Flashなどのプラグインや、GoogleMapsやjQueryの登場により、インタラクティブなアプリケーションを実現することも出来ましたが、Web標準はそのような表現ができることを想定はしていませんでした。

この状況に不満を感じたWebブラウザベンダは、WHATWGというW3Cとは別の標準化団体を立ち上げました。WHATWGでは、実世界のWebブラウザ利用者のニーズに沿った仕様の策定を目指すべく活動し、結果としてWeb技術はアプリケーションプラットフォームとしてのポテンシャルを獲得するようになりました。
(※参考 : What is the WHATWG? )

★ 1.2. 「独自実装」→「Web標準への準拠」

f:id:furoshiki0223:20131120021536p:plain

かつてIEは、大量のActiveX機能、CLRの動作、独自のタグ定義など、他の競合ブラウザにシェアを奪われないよう、独自機能によるロックインを行っていました。IEのバージョンアップを行えるようにするには、過去の独自実装機能を動作させ続ける必要があります。このためIEは、過去のレンダリングエンジンを新しいIE上でも実装し続ける必要に迫られました。IE8からは、この状況を改善するため、独自実装からWeb標準への準拠へ方針をシフトしました。
(※参考 : Microsoft Expands Support for Web Standards - Microsoft )

IEはこれまで独自実装により安定した機能を得ていました。しかしIE8からは、仕様策定中のHTML5の機能を部分的にサポートするようになり、またCSS2.1についてもベンダプレフィックスを与えることで試験的に実装するようになりました。
(※参考 : Microsoft CSS Vendor Extensions - Microsoft )
(※参考 : HTML5 - Microsoft )

HTML5が高いポテンシャルを有するようになると、実世界のニーズを埋めるために利用されていた独自実装やプラグインの価値は一気に低くなりました。そして現在、IEはHTML5機能の実装を積極的に行い、プラグインの利用を排除する方針で開発を進めています。IE10のMetro版は、リリース直前までFlashを含めプラグインを廃止するという宣言まで行っていました。(実際は制限付きになりましたが。)

現在、Microsoftの公式の見解として、IEがプラグインを減らしWeb標準の実装にこだわるモチベーションは、マルチデバイス環境下での高いユーザ体験の実現を理由としています。Windows 8のような、デスクトップとスマートデバイスの違いを意識させないデバイス上で、Web技術の持つマルチデバイス実装の力を借りることにより、高いユーザ体験を提供しようとしています。
(※参照 :Metro style browsing and plug-in free HTML5 - building Windows8)

2. IEが求める既存システムの維持方法の変化

★ 2.1. ドキュメントモードの煩雑化

前章でも述べた通り、IEは6以降、過去の独自実装をいつまでも抱え続けなくてはいけないことに苦労していました。

実際にIE11では、IE5(旧Quirksモード)、IE7(互換表示モード)、IE8、IE9、IE10、IE11(Edgeモード)と、合計6つのレンダリングエンジンを内部で抱えています。QuirksモードについてはIE5の独自機能に加えてHTML5機能が多少動作するような工夫がIE10以降行われるようになりました。過去のレンダリングエンジンにまでメンテナンスが必要な状況へ追い込まれてしまいました。
(※参考 : 相互運用可能な Quirks モード - Microsoft)

しかし、Web標準への準拠を進めたIEは、機能の安定化に加えて、機能/動作検出というWebデザインのベストクラクティスが広まり、バージョンを意識する必要が薄れてきました。特に、IE8からIE9にかけてはWeb標準に注力した仕様変更を行いましたが、IE9から10は、XHRの改善が目つくものの、多くは独自機能の削除とWeb標準機能の追加に注力されているように思えます。
(※参考 : IE9 の互換性の変更点 - Micosoft )
(※参考 : IE10 の互換性の変更点 - Microsoft)

IEの使用レンダリングエンジンの種類を表すドキュメントモードは、「以前のバージョンの動作をエミュレートできる場合がある」という表現で紹介されてきましたが、同時にそれが一時的なソリューションであるという説明も行ってきました。

多くの企業が、このドキュメントモードの恩恵を受けて、既存のIE6でテストされたシステムを残したまま、Windows7+IE8以上への移行を行うことができたはずです。しかしIE11からは、この対策は通用しなくなります。

★ 2.2. 古いWebシステムの維持は「互換表示」→「改修」

IE11は、これまで過去のコンテンツを維持するために利用されていた互換表示(ドキュメントモード)を、「一時的なソリューション」から「非推奨」というステータスへ変えています。また、ドキュメントモードは今後、サポートされなくなる可能性があるという説明もされています。このステータスの変化は、IE10とIE11の間で、HTMLドキュメントの解釈にも大きな変化を与えているようです。
(※参考 : IE11 の互換性の変更点 - Microsoft)
(※参考 : ドキュメント モードの非推奨 - Microsoft)

これまで既存のWebシステムは、次の更改までの間はドキュメントモードを利用して一時的な対策を行うのが一般的でした。しかしIE11以降、ドキュメントモードは利用せずに、Webコンテンツの制作/開発者側で改善を行う必要があります。古いWeb標準で記述されていたHTMLドキュメントは「Quirksモード(IE5+αのレンダリングエンジン)」で動作していましたが、IE11からはドキュメントモードが非推奨であるため、Edgeモード(IE11のレンダリングエンジン)で動作するように仕様変更されています。
(※参考 : IE11ではDOCTYPE宣言がチェックされない - ふろしき.js)

また、互換表示機能に含まれる全てのレンダリングエンジンから、部分的に古い機能が削除されています。例えば、CSS ExpressionsはIE7以下の互換表示機能だと動作していましたが、IE11ではQuirksモード(IE5)でもIE7互換モードでも動作しない仕様へと変更されています。互換表示とは呼ばれていますが、互換性は失われているものとみなすべきです。
(※参考 : expression of CSS is not enabled in compatibility mode with "Internet Zone" - Microsoft Connectの回答より)

既存システムを維持しIEのバージョンアップを行うには、IT管理者によるドキュメントモード(互換表示)の操作により解決できることが多かったですが、今後この手段は利用できなくなるものと見なすべきです。IEは過去にも、一つ前のバージョンで「サポートされなくなる可能性がある」旨を警告し、バージョンアップ時にサポート終了へ遷移させるというアクションを繰り返し行ってきました。このような過去の傾向から、ドキュメントモードはIE12もしくはその先のどこかのバージョンで、サポートされなくなると予想できます。

企業システムのIT管理者は、これまで先延ばしにしてきた既存資産の改修を、IEのバージョン11以上へのアップデートへカウントダウンが始まっている今、確実に進めていく必要があります。仮にIE11が標準ブラウザでない場合も、長期的なコスト最適化のため、今後開発するシステムがIE独自機能に依存しない設計となるよう、統制を行わなくてはいけません。

開発者はバージョンアップ時の改修のリスクを減らすため、相互運用性に対して注意を払う必要があります。特に、IE10以下で新規開発を行う場合、必ずDOCTYPEを正しく宣言し、最新のレンダリングエンジンで動作することを確認した上でテストして下さい。誤ったDOCTYPEの宣言は、IE10以下であればどのバージョンであっても互換表示の恩恵を受けるため、問題は小さく見えます。しかしIE11以降で、問題は確実に大きくなります。

相互運用性対策は「ブラウザ/デバイス検出」から「機能/動作検出」へ

これまでWebシステム/サイトは、Webブラウザの種類でビューを切り替える「ブラウザ検出」という考え方が一般的でした。また、デスクトップ型かスマートデバイス型かをサーバで判断し、ビューを返す「デバイス検出」は、今もなお主流かと思います。

しかし最近、ブラウザの持つ機能や動作を検出して動作を切り替える「機能検出」「動作検出」という方法へシフトすべきという意見が広がっています。実際に現場でも、この設計指針へのシフトを検討している方もいるでしょう。

本記事では、「ブラウザ/デバイス検出型」と「機能/動作検出型」について、その重要性について解説します。

1. Webブラウザの持つ2レイヤーの概念

★ 1.1. レンダリングエンジンとOS

「機能/動作検出」の前に、まずWebブラウザの持つ2レイヤーの考え方について理解してみましょう。

Webブラウザには、HTMLドキュメントやCSS/JavaScriptファイルを読み込み、Webページを表示するレンダリングエンジンという機構が備わっています。

レンダリングエンジンはOSから見ると、他のアプリケーションとは変わらないただのプログラムです。しかしレンダリングエンジン側から見たOSは、WindowsにMAC、Linuxという異なるシステムであり、レンダリングエンジンはこれらのOSの持つ機能の中から極力同じことが出来るものを利用し、Webページの表示を行わなくてはいけません。

したがって、WebブラウザがHTMLドキュメントを読み込みWebページを表示する際、その動作は以下の2レイヤーに依存することになります。

f:id:furoshiki0223:20131118170607p:plain

レンダリングエンジンのソースコードの大半は、どのようなOSであっても同じものが利用されるため動作に違いは生じません。しかし、OSに依存するような機能を利用していた場合、OSごとに異なる動作にならざるえません。

2. OS・レイヤーの抱える問題

★ 2.1. alertから学ぶ、各WebブラウザのOSとの付き合い方

Chrome(WebKit)やFirefox(Gecko)は極力レンダリングエンジン側に処理を持たせ、OSは汎用的なAPIのみを利用しようという傾向があります。しかしIE(Trident)は、どちらかと言えばOSのAPIをフルに活用しようという傾向にあります。いかにもOSのAPIをラップしてそうな機能は、Webブラウザごとにやや異なる動作になります。

例えば、JavaScriptの「alert」というシンプルなAPIを確認するだけでも、各Webブラウザの持つ思想の違いが読み取れるでしょう。

f:id:furoshiki0223:20131116020551p:plain

alertは、Firefoxには閉じるボタンがありませんが、ChromeとIEにはあるという機能面での違いが生じています。デザインについて、FirefoxとChromeはOSによる差異は小さく独自のものを利用していますが、IEはWindowsXPか7かといったOSの種類によって、ウィンドウの形状に違いが生じます。

alertの場合、形状が異る程度で、目的としている機能は概ね達成されています。問題になることは無いでしょう。

★ 2.2. 名前解決から学ぶ、OSブランド間の差異

URLの考え方は、各OSごとに違いが生じています。

ハイパーリンクやお気に入りのクリックにより生じるドメイン名の名前解決ですが、MacOSのようなUNIX系のWebブラウザはSocketと呼ばれるAPIを利用します。対してWindows上のWebブラウザは全て、WinSock2というAPIを利用することになります。

SocketのAPIへ渡されたドメイン名は、DNSと呼ばれる名前解決の仕組みを利用してIPアドレスに解決されます。対してWinSock2は、DNSに加えてNBT(NetBIOS/WINS)という名前解決の仕組みも利用されることになります。Windowsの場合はActive Directory絡みの拡張も絡みますが、ドメイン名周りについて、Webブラウザの種類への依存は小さく、OSの種類への依存は大きいという状況です。

ドメイン名の扱いをOSごとに厳密にすると、MacOSは「DNSドメイン名」、WindowsOSは「フルコンピュータ名」と呼ばれる概念として扱われ、名前解決が行われます。同じChromeやFirefoxであっても、Windows版かMac版かでアクセスできるURLに差異が生じてしまいます。これは、WINSに依存した業務システムでは、問題になることがあります。

f:id:furoshiki0223:20131118174841p:plain

OSの持つ名前解決の仕組みが限られているが故に発生する、機能面での差異です。

Webブラウザの仕様はW3Cで標準化されていますが、その内容は「できること」が中心で、想定外の操作に対する動作の定義は、行われていないものが多いです。Web標準はあくまで、共通項を定義しているのに過ぎないのです。

★ 2.3. テキスト出力から学ぶ、OSのバージョン間差異

IEはWindowsのみとOSが限定されているから安全かと言えば、そういうものでもありません。Windowsは2000/XP(NT5系)からVista/7/8(NT6系)、そして8.1でも微妙に差があり、OSのバージョン間でも動作の違いが生じています。

Windowsのテキスト出力について、NT5系のWindowsの多くのフォントが可変幅だったのに対して、NT6系からメイリオと呼ばれる固定横幅が推奨されるようになりました。これに伴い、テキスト出力は固定幅に最適化されたような動作に変わりました。

レガシーIE向けに作られたWebシステム/サイトに多いのが、ピクセル単位での動作に依存したデザインです。以前よく見た事例としては、ポップアップウィンドウの幅とテキストの横幅が揃うことを前提としたレイアウトが問題になるケースです。

f:id:furoshiki0223:20131118185105p:plain

このシステムが開発されたのは単一ブラウザが当たり前なIE6時代なので、当時は全く問題にならなかったのでしょう。時代が変わりIE8へ移行しても、WindowsXPなのでまだ問題がありませんでした。しかし、Windows7+IE8へ移行というタイミングになって、突然問題が起こります。同じIE8なのに、レイアウトが崩れてしまうのです。

この事例は、ポップアップウィンドウというOS依存のAPIと、テキスト出力というOS依存の動作がダブルパンチになって効いてきています。

Webブラウザ依存のポップアップウィンドウを使うなんてのがそもそも良くないという意見もありますが、その点を差し置いても、レイアウトのデザインについては、どこまでがレンダリングエンジンでできて、どこからがOSなのかという点は理解する必要があります。そしてOSにより変化する機能は、何かしらの対策を講じなくてはいけないでしょう。

CSS3-UIには「text-overflow」という仕様がありますが、まさにこれはOS依存のテキスト幅に対しても、目的の機能をWebブラウザの機能だけで実現しようという取り組みです。Webブラウザの種類だけでなく、OSの種類でも機能の差異を吸収しようという取り組みがWeb標準では行われています。

3. レンダリングエンジン・レイヤーの抱える問題

★ 3.1. IEの互換表示機能の限界

Internet Explorerには、後方互換性を保つための「互換表示」という機能が備わっています。例えば、IE8であれば、IE5(Quirksモード)とIE7のレンダリングエンジンを内部で持っており、古いIEの独自機能を利用したコンテンツをそのまま維持しつつ、IEのバージョンアップを行えるという狙いがあります。
(※参考 : 互換表示一覧の概要 - Microsoft)

f:id:furoshiki0223:20131118193454p:plain

かつてIEには、CSS上でJavaScriptを動作させることができる、CSS Expresionsというアンチパターンがありました。古いコンテンツの多くは、この機能に依存していました。Webブラウザが新しいWeb標準に追いつけていない場合にも、CSS側で不足した機能を埋めることができたからです。CSS ExpressionsはIE8で既に、サポートが削除されています。
(※参考 : CSS Expressions のサポート終了について - Microsoft)

互換表示機能を使えば、IE8〜10のWebブラウザでもCSS Expressionsを利用することができます。古いコンテンツがネックになって、IEのバージョンアップができなくなるという問題を回避するために行われた対処です。既存資産の維持という目的であれば、互換表示機能は価値の高い機能でしょう。

しかし、2章の内容を読んだ人であれば、この動作には限界があるということがわかるはずです。「互換表示」が機能するのは、あくまでレンダリングエンジンの層に限定されるのです。OSをエミュレートするための機能を、Webブラウザは持ってはいません。

f:id:furoshiki0223:20131118194122p:plain

★ 3.2. 独自実装機能の限界

既に述べた通り、古いIEはかなり多くの独自機能を持ち、多くのコンテンツがこれに依存していました。Webブラウザ上で、.NET用のCLRが動作したり、豊富なActiveXのAPIや、Windows機能のラッパーじゃないかと思えるような機能がゴロゴロと付いていました。

これにより、Web制作/開発者側の苦労は大きくなりました。IEは古いバージョンも多くシェアを占める上、独自動作は各バージョン間でも違いが生じているため、バージョンベクタと呼ばれる機能を利用して、各バージョンごとの動作差異を吸収しなくてはいけません。
(※参考 : バージョン ベクタ - Microsoft )

また、独自実装に走ったIEと、標準準拠に走った別のWebブラウザとで、ブラウザ検出によるビューの切り替えを行わなくてはいけません。制作/開発者は、IE特化のビューをわざわざ用意する必要があったのです。ASP.NETには、これを想定した機能まで提供されていました。ブラウザごとに、マークアップを分けるのは公式に認められた手段と化していたのです。
(※参考 : ブラウザ定義ファイルのスキーマ -MSDN )

しかしIEはバージョン8から、独自実装からWeb標準への準拠という方針へシフトし、状況は徐々に改善されました。
(※参考 : Microsoft Expands Support for Web Standards - Microsoft)

これまで安定した実装を得るために独自機能へ走っていたのが、ベンダプレフィックスにより試験機能を明確化することで、Web標準への準拠するようになりました。
(※参考 : Microsoft CSS Vendor Extensions - Microsoft)

こうした取り組みが実り、IEはバージョン固有機能のしがらみから開放され、IE9以降あたりから独自実装の少ない汎用的なコンテンツを作ることができるようになりました。

4. HTML5時代のWeb開発/制作の指針

★ 4.1. 「ブラウザ検出」→「機能/動作検出」

IE9では、Microsoftが公式に公開している互換性クックブックというドキュメントの中で「機能検出」「動作検出」という指針でWebコンテンツを制作/開発するよう促しています。
(※参考:機能検出と動作検出の使用 - Microsoft)

IE10からはMicrosoftも自信を持っており、特定のIEのバージョンでのみHTMLタグを有効にさせるという条件付きコメント機能のサポートを削除しました。
(※参考:条件付きコメントがサポートされなくなった - Microsoft)

またIE11からは、ユーザエージェントからMSIEの文字をなくしたことで、サーバ・JavaScript上から、ブラウザの種類の検出が困難になりました。
(※参考:IE11 の互換性の変更点 - Microsoft)

これらの背景を踏まえ、Web開発/制作者はコンテンツに対して、以下の指針を持つ必要があります。

〜IE8 「ブラウザ検出」を利用したコンテンツの開発/制作
IE9〜/Firefox/Chrome 「機能/動作検出」を利用したコンテンツの開発/制作

個人的な感覚ですが、IEのレンダリングエンジンは、5-6、7-8、9-10と、2バージョンが類似した動作を行う傾向にあるように思えます。機能面で見ればIE10からになりますが、Microsoft側の見解としてはIE9以降であり、IEのレンダリングエンジンの特性から見ても現実的な判断であると考えられます。

Microsoftは今後、IEを機能/動作検証の指針で利用されることを想定して開発を進めるでしょう。IE10/11で行った大胆な仕様変更を鑑みると、IEはどこかのタイミングで互換表示機能を廃止することも考えられます。Webブラウザを検出を許すような設計はインパクトが大きいため、上記に挙げた2つの指針は厳守すべきです。もしこれが守られなかった場合、企業システムであれば、IEのバージョンアップに多くのコストを要する可能性があります。

★ 4.2. 「デバイス検出」→「機能/動作検出」

iPhoneのブーム以降、世の中にスマートデバイスやタブレットという新しいデバイスが利用されるようになり、Webブラウザを取り囲む環境は大きく変化しました。Webブラウザの機能は汎用化されましたが、一方でOS側の持つデバイスや機能が多様化しました。このような背景の中、MicrosoftはWindows8以降のOSからは、デスクトップ型とスマートデバイス型の違いを意識させないOS作りへ方針を変えています。
(※参考 : Windows help & learning - Microsoft Support)

f:id:furoshiki0223:20131119003251p:plain

デバイスも、キーボードをつなげればデスクトップ型になり、外せばスマートデバイス型へ変化するというコンピュータを広げようとしています。このようなデバイスが広がれば、必然としてサーバサイドでデバイスの種類を区別するようなWebコンテンツのデザインは歓迎されないでしょう。
(※参考 : Surface 2 - Microsoft )

f:id:furoshiki0223:20131119003404p:plain

近年「レスポンシブWebデザイン」という手法が広がっていますが、Microsoftもこれを推進しており、必要なOSSのJSライブラリを一式、Microsoft側でサポートしています。Webサイト/システムは、サーバ側でデバイスに応じて返すビューを変えるのでなく、クライアント側でマルチデバイスに対応したビューを用意する必要があります。
(※参考 : オープンソースのJavaScriptライブラリでベンダサポートを受ける方法 - ふろしき.js)

レスポンシブWebデザイン導入のメリットが見いだせない制作/開発者の方もいるようですが、デバイスがデスクトップとスマートデバイスの違いが無くなろうとしている今の状況を鑑みれば、導入は必然なものとして考えることができるでしょう。エンタープライズ系の場合、企業にタブレットの導入が広がっているのであれば、レスポンシブWebデザインのようなマルチデバイス対策は進めていく必要があります。

IE11ではDOCTYPE宣言がチェックされない、どうすれば解決できるか?

IE11から、ドキュメントモードは非推奨というステータスに変わっています。
(※参考 : ドキュメント モードの非推奨 - Microsoft)

IEはこれまで、DOCTYPEを確認してQuirksモード(IE5+αなレンダリングエンジン)とEdgeモード(最新のレンダリングエンジン)を切り替えていましたが、11からはこの仕様は削除され、DOCTYPEの記述がドキュメントモードに影響を与えなくなりました。

古いWeb標準に従って記述されていた以下のようなドキュメントは、これまではQuirksモードで動作していましたが、IE11では常にEdgeモード(IE11のレンダリングエンジン)で動作します。

※ DOCTYPE宣言無し

<html lang="ja">
  <head>
    <meta charset="utf-8" />
    <title>test page.</title>
  </head>
  <body>
  </body>
</html>

※ FramesetのURI指定無し

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN">

※ TransitionalのURI指定無し

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">


f:id:furoshiki0223:20131118233751p:plain

この仕様変更によりWebページが正常に表示出来ない場合、Microsoftの公式の見解としては、コンテンツの制作/開発者が改善を行わなくてはいけないことになっています。

しかし、これを待つことが出来ない状況があるはずです。その場合、以下の方法を参考に解決策を探ってみて下さい。

1. ユーザ側でできる対策

IEには、Webサイトの利用者側で、特定のドメインに対する「互換性モード」の切り替えを行う機能を持っています。

Microsoftでは、IEをエンタープライズ用途(企業内向け)で利用されることを想定しており、ライフサイクルの長いシステムのプラットフォームとして利用されることを前提とした、様々な機能が提供されています。

互換性モードは、IEのバージョンアップを行っても、古いWebサイト・アプリを継続して利用できるよう、古いレンダリングエンジンの動作をエミュレートすることができる機能です。

以下の手順に従い、設定を試してみて下さい。

IEのウィンドウ右上にある「歯車アイコン」をクリックし、「互換表示設定(B)」をクリック。
f:id:furoshiki0223:20131111201907p:plain

ドメイン名を入力し、「追加」をクリック。
f:id:furoshiki0223:20131111202037p:plain

閉じるをクリックすると、IEは再びロードを開始し、古いレンダリングエンジンによる動作を開始します。IE11では、「互換表示設定」にて指定されたドメイン名(URL)のWebサイトは、「IE5」の動作を再現させます。

2. 開発者側でできる対策

★ ApacheでHTTPレスポンスヘッダにX-UA-Compatibleを追加する

RHEL/CentOS/FedoraでApache HTTP Serverを利用している場合は、「/etc/httpd/httpd.conf」にて、一番最後に以下の内容を追記して下さい。

LoadModule headers_module modules/mod_headers.so
<IfModule headers_module>
   Header set X-UA-Compatible: IE=5
</IfModule>

Apacheに「mod_headers.so」がバンドルされていない場合はエラーになります。予め、インストールして下さい。

★ IISでHTTPレスポンスヘッダにX-UA-Compatibleを追加する

MicrosoftのWindows系OSで「インターネット インフォメーション サービス(IIS)」を利用している場合は、以下の手順になります。

「コンピュータの管理」→「インターネット インフォメーション サービス(IIS) マネージャー」
f:id:furoshiki0223:20131112210814p:plain

「HTTP応答ヘッダー」
f:id:furoshiki0223:20131112210923p:plain
表示内で右クリック、「追記」を左クリック
f:id:furoshiki0223:20131112211023p:plain
「名前(N):」へ「X-UA-Compatible」、「値(V):」へ「IE=5」
f:id:furoshiki0223:20131124005122p:plain

このブログの筆者について

川田 寛

コンテンツサービスの開発や運営代行を専門とする集団「株式会社ブートストラップ」の社長です。ネットではふろしきと呼ばれています。

2009年にNTTグループへ新卒入社し、ITエンジニアとしてクラウド技術・Web技術の研究開発と技術コンサルティングに従事。2015年よりピクシブに入社し、エンジニアリングマネージャー・事業責任者・執行役員CCOなど、様々な立場からコンテンツサービスの事業づくりに関わりました。2021年にメディアドゥへVPoEとしてジョインし出版関係の事業に関わったのち、2023年に独立しています。

関わってきたインターネット事業としては、ECサービスのBOOTH、UGCプラットフォームのpixiv(主に海外展開)、制作ツールのpixiv Sketch、VR・VTuber関連ではVRoid、Wikiサービスのピクシブ百科事典など、10を超える多様なCtoCコンテンツサービス。また、NTTドコモのすご得コンテンツ、メディアドゥのWeb3サービスであるFanTopなど、いくつかのBtoCコンテンツサービスにも関わってきました。

幸運なことに、私はコンテンツに関係する幅広いインターネットサービスのテクノロジー&ビジネスの知識を得ることができました。これを日本のコンテンツ発展に役立てたいと思い、株式会社ブートストラップを創業しました。

このブログでは現在、出版社やIPホルダー、ライセンサーといったコンテンツに関わる人々に向けて、インターネット事業に関するTipsや業界内のトレンドなどの情報を発信しています。私と話をしてみたいという方は、以下のフォームより気軽にご連絡ください。

お問い合わせフォーム