ふろしき Blog

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

さらばPointer Events!まだまだ落ち着かない、入力デバイスのWeb標準事情

人々にとってのコンピュータとはデスクトップのみを指す言葉ではなくなり、モバイルやペンといった様々なデバイスが人々の暮らしに関わるようになりました。こうした事情を鑑みて、Microsoftは「Pointer Events」というWeb標準の策定に力を入れていました。彼らは、どんな入力デバイスが備わっていても、共通の手段でそれを扱えることが、Web開発者の望みだと考えていたのです。

IE10ではベンダプレフィクス付き、IE11からはベンダプレフィクス無しで実装されました。そのことを受け、私も一年以上も前に「よし、そろそろだぜ」とブログでPointer Eventsを取り上げました。

ただ、今になってからそれを取り消します。Pointer Eventsは現時点では、あまりオススメできません。どうしても使いたいなら、クロスプラットフォーム面に細心の注意を払ってご利用下さい。

何が起きたのか?

Microsoftは、Appleの特許問題に負けず、Webに共通のスクリーン入力の手段を模索し続けました。その成果として、Pointer Eventsはついに2013年の5月に「勧告候補」というステータスとなりました。

f:id:furoshiki0223:20150206183945j:plain

ところが、Googleからは「Pointer EventsはWebの未来じゃない」という判断がされたようです。2015年2月のChromeでも実装されておらず、Firefoxも動作しません。勧告候補とは呼べないほどに、サポート状況は壊滅的です。もはや、IE独自機能と言っても過言ではない状況と言えます。

f:id:furoshiki0223:20150206185335j:plain

どうしてこうなったのか?

「当初の予定よりも、世の中が変わってしまった」というのが最大の要因です。人々はメインのコンピューターとして、デスクトップよりもモバイルを選択するようになりました。こうした状況を鑑みて、Googleは2014年頭から、BlinkはモバイルWebに力を入れると宣言しましたが、入力についてもその要求は大きく変化したようです。

以下のスライドは、GoogleのRick Byers氏が、2014年の6月に公開したプレゼンテーション「Touch events vs. Pointer events in Blink」中の一枚です。

f:id:furoshiki0223:20150206192958j:plain

彼らは、モバイルファーストであること、早くデフォルトの機能として落ち着くこと、そして、モバイルのネイティブアプリケーションのようにリッチであることを高いプライオリティとして持っており、こうした中でPointer EventはBlinkに合わなくなっていると述べています。また、Pointer Events相当のものが必要というのであれば、Polyfillに頼ればいいと考えているようです。

その後、2014年7月のW3CのMLにて、彼は次のように語っています。(※「Blink does not plan to implement pointer events」より一部を抜粋し意訳)

「これからも、Pointer Eventsのワーキンググループには関わり続ける予定だ。私たちが解決しようとしている問題は本質的に同じで、APIがどんな仕様であるかだ。少なくとも私たちは、すでに共通するタッチアクション用のAPIを持っている。様々な意見が入ることなく決断が行われることは望ましくない。Webプラットフォームが長期的に健全であるために、私たちは様々な技術的な意見を取り込み、ベストな方法を探るべきだろう。複数のブラウザベンダ間で協力しプラットフォームを進化させていくこと、Webの標準化を進めていくこと、これらに対して、Blinkチームはこれからも深く関わり続けていく。マイクロソフトが成し遂げたことは、本当に素晴らしいことだ。これからも、あなた方は我々とともに、現状のAPI設計の欠点を埋めていき、新しいイベントモデルを探っていけるはずだ。 」

"I plan to continue to participate in the working group, as the problems we're trying to solve are essentially the same regardless of the specific form of the API and we have at least the touch-action API in common. I hope it goes without saying that this decision reflects only a difference in technical opinion about what's best for the long-term health of the web platform. The blink team continues to be deeply committed to evolving the platform only through the collaboration of multiple browser vendors and the web standards process. We have deep respect for the work Microsoft has done here, and I'm optimistic that we will find a way together to leverage the advancements in input API design without the drawbacks of introducing a new event model."

【ここから下、2015/2/14に追記】
@kanreisa氏との議論もあり、「さらば!」と投げ出すだけだと辛いので、Pointer Eventsと「さらば!」しなくて良い方法を記述しました。@kanreisaさん、ありがとうございます!

Pointer Eventsに残された復活の道は?

jQuery FoundationのKris Borchers氏(@kborchers)に確認したのですが、2015年2月現在、状況は変わっていないようです。Blinkチームは、Pointer Eventsが世の中から適合されることを待っているという状況です。ようは、シェアの問題ということになるのでしょう。

f:id:furoshiki0223:20150215152710j:plain

したがって、人々がPointer Eventsを活用し、Pointer Eventsを必要とすれば、Blinkチームも実装に踏み切ることができるでしょう。そこで、Pointer Eventsがこれから復活するために必要な2つの道をご紹介します。

1. jQuery FoundationのPEPの普及

BlinkチームがPointer Eventsの実装計画を取りやめた後、Google(Polymerチーム)はjQuery Foundationへ、Pointer Events Polyfill(PEP)を寄贈しました。今もなお、Pointer EventsのPolyfillは維持し提供されており、フォールバックによりPointer Eventsの機能を活用することが可能です。

もし、このPolyfillライブラリの活用が広がれば、Blinkチームもそのニーズに答えようと実装に踏み切ってくれるでしょう。

2. ペンデバイスの普及

現在、ペンデバイスの入力を行うための専用のイベントが存在せず、Pointer Eventsを利用するしか道は残されていません。したがって、ペンデバイスが普及すれば、必然的にPointer Eventsが必要となり、Blinkも早急に実装することが求められるでしょう。

「2014年4月」はIEの歴史を動かした。そこから何が読み取れるのか?

マイクロソフトが提供しているブラウザ「Internet Explorer」の脆弱性問題がTVで大きく取り上げられ、Webの利用者へ混乱をもたらした事件から、約3ヶ月が経過しました。また、IEの重要な機能追加の発表があったマイクロソフト主催カンファレンス「Build 2014」からも3ヶ月です。長きに渡って人々から愛されたIE6のEOLからも3ヶ月。今思えば、2014年の4月は、IEの歴史を大きく左右する重大な事件の連続でした。

割と冷静さを取り戻してきたこのタイミングで、もう一度一連の事件の振り返るとともに、マイクロソフトがとった対応から、IEが一体どういうポリシーでこれからのWebを維持していくのか、その考えを読み取ってみましょう。

脆弱性問題を冷静にみつめてみると?

脆弱性の問題は、マイクロソフトに限らず多くの製品ベンダがよく起こしている問題です。ソフトウェアのバグや脆弱性が存在しないということは証明できないといわれ、これを「悪魔の証明」と呼び、防ぎようのないこととして扱われます。技術的な違いこそありますが、IEは今回の起こした脆弱性問題(#222929)の前にも、似たようなリスクを持つ脆弱性問題を何度か抱えたことがあり、近いものだと2012年(#480095)に起こしています。割とありきたりな事象です。絶対に起こさないを目指すと製品を世の中に出せなくなるので、リスクコントロールで調整していくものと言えるでしょう。

ところが、Windows XPのサポート終了直後だったこと、政治・経済が比較的静かなゴールデンウィーク中に起きたこと、あるいは、IE自体の知名度が高かったことが要因なのか、そのありきたりな事象が、TVで取り上げられる「事件」へと発展しました。彼らは、注目を集めることがビジネスであり、正しい情報を伝えることは必ずしも彼らにとっての利益とはなりえません。モラルの話はさておき、これはもうビジネスなので仕方がないでしょう。セキュリティ問題と同様、いつ起きてもおかしくないリスク、いわば事故のようなものです。

そして残念なことに、情報の本質が元のソースとはやや異なるものに歪められたその報道は、技術に詳しくない人の注目を集めるには十分だったようです。

元の情報:提示する対策ができないなら、Internet Explorerを使うべきではない
↓
TVでの報道:Internet Explorerを使ってはいけない

「使ってはいけない」これは確かに、強烈なインパクトですね。

マイクロソフトは、世の中的に騒がれた要因を少しでも取り除こうと、Windows Vistaや7、8.1だけでなく、既にサポートが終了してまったく面倒をみる必要のないWindows XPへも、無償でセキュリティパッチを提供しました。普通の製品ではあまり考えられない、異例の対応と言えます。例えるなら、貸しビルのオーナーが、耐用年数が過ぎたビルに家賃も払わずに住んでいる人のため、わざわざペンキを塗り替えてあげるようなものです。

あれから3ヶ月、IEはどうなったのか?

StatCounter Global Statsの統計情報を確認すると、4月の脆弱性問題は、国内でのIEのシェアが一時的にChromeに抜かれるという歴史的な事件に発展したようです。しかし今は、ペンキの効果があったのか、なんとか立て直してトップの座を奪い返しています。

f:id:furoshiki0223:20150204163749j:plain

一方で、グローバルな視点では、Chromeの影響力が高く、IE、Firefox、共に苦戦しているようです。短期的な問題は去ったかのように見えますが、長期的にはまだまだ難ありという状況にみえます。

f:id:furoshiki0223:20150204163750j:plain

世界的にはモバイル/タブレットがシェアを高めているため、高い影響力を持つAndroid版ChromeやiOS版Safariと、どう勝負していくかも求められています。コンシュマライゼーション(消費者向けの製品が企業で活用されるエンタープライズの一種の心理)が進む中、エンタープライズIT側への影響も無視できない重要な動向です。

f:id:furoshiki0223:20150204163752j:plain

一方で、Build 2014ではこんな動きが

2014年4月サンフランシスコにて、マイクロソフトはグローバル・カンファレンス「Build 2014」を開催しました。この中で、Josh Holmes氏が行なった講演「Internet Explorer as a Web Application Platform」で、興味深い発表がされました。

ここからは、彼の講演のダイジェストをお届けします。

"IE6カウントダウンというサイトの、2014年の2月の段階でのスナップショットを見てもらいたい。

世界的には、4.4%のユーザが未だにIE6を使っているという状況だ。しかし、アメリカでは0.2%であり、そこまで多くない。ほとんどが政府と企業だ。ノルウェイはなんと0.0%と小さく、もはや何の影響力も持たない。しかし、中国は今でも22.2%もあるため、中国を市場ターゲットとする場合は、IE6対応が求められるだろう。

f:id:furoshiki0223:20150204163753j:plain

一般的に、コンシューマー向けでは、1つのサイトに何百もの開発者が関わる。しかしエンタープライズの場合は、一般的に、千を超えるようなアプリに対して、少しのプールされた開発者が関わるなんてことがある。この会場にも、辛いと感じている人はいるよね?より良いパフォーマンス、より良いセキュリティ、より良い可用性を与えたいが、古いIT資産が足を引っ張る。

f:id:furoshiki0223:20150204163754j:plain

そこでエンタープライズモード(EMIE)だ。この機能を使うと、今あるIT投資資産を、タイムカプセルのように包み込み維持できる。そして新しいIT投資資産については、IEの持つ最新の機能を使うことができる。エンタープライズモードは、企業標準ブラウザのアップグレードの機会を与えるんだ。"

f:id:furoshiki0223:20150204163756j:plain

この2つのことから、何が読み取れるのか?

エンタープライズ・モードの登場で、なんだほら、古いIE向けシステム、まだまだ延命できるじゃないか!なんてほっとしたのが世間的な評価でしょう。ただ、私としてはそこに注目して欲しくありません。よくよく考えてください、IE6の次はIE8?いえいえ違います、IE7もまだ延長サポート期間であり、決して無視はできません。素直に考えるなら、IE7の保護を考えるべきなのに、彼らは明確に「IE8を暫定的に守る」と言っています。

つまりどういうことか?表向きはN+1サポートとか言っていた彼らですが、Josh Holmes氏の講演では明確に「みんながIE8を使っているみたいだから、IE8向けシステム守ろう」と主張しています。脆弱性騒動もそうだったはずです。「世の中が気にしているから、例外的にWindows XPも守ります」という姿勢でした。実はマイクロソフトという会社は、昔から世の中の評判というのを非常に気にする体質の企業で、そこに過剰なほどにエネルギーを注ぎます。世間の評価を気にするのは、企業として普通のアクションなわけですが、このあたり興味深い動きに思えます。

彼らはサポート期間云々よりも、まずIEのユーザがどういう状況に陥っているのか、そこを大切にするのです。エンタープライズのマーケットにIE8が高いシェアを獲得している間は、彼らはきっとIE8特化のレガシーな資産を丁重にあつかってくれることでしょう。しかしご存知の通り、グローバルな視点では既にIEの影響力は日に日に弱くなっていて、そのことがどう作用するか油断できないという状況であることも認識すべきでしょう。

逆の見方をすれば、良い所もあります。WebRTCとかWebComponentsとか、マイクロソフトのエコシステム的に手を出しにくいWeb技術はいっぱいあるのですが、案外世の中が「欲しい欲しい」と強く主張すれば、なんとかなるのかもしれません。Windows 7世代(主に2020年まで)は、IEに限らず色んな技術が揉まれて不安定なので、世の中の動向を慎重に見たり、自分たちのビジネスにとってどんな価値が求められるのかを強く主張することは、割とインパクトがあるのかもしれませんね。

余談ですが、「マイクロソフトよ、企業向けだとこれを実装してくれると凄く助かるんだが・・・」と伝える場所は、あるにはあるので試してみてはどうでしょう。Web標準とかでなく、単純に「あれ欲しい!すごく重要!」みたいな直感的なノリでも、「俺たちチャレンジャー企業に戻ってしまった!まじ◯oogleさんに負けてられんほど、Webを変えていくよ!!」的な感じで語る今のマイクロソフトなら、割と真摯に聞きそうな気がしています。(日本語で書いたら、誰かが気を使って英語に訳してくれるはず。MS日本チームさんが!)

Compat Inspector - ソースコードからIE独自機能を機械的に検出しWeb標準へ置き換えさせる方法

古いWebコンテンツではIE独自の機能を利用しないことには、リッチな機能を盛り込むことが実質的に不可能という状況でした。しかし、IE9以上からはWeb標準への準拠が高く、Microsoft側でも、IE独自機能に依存しないWeb標準へ準拠したコンテンツ作りを推奨しています。

IE独自機能はバージョン8以降削除される傾向にあり、見落とされると、Webコンテンツのライフサイクルへ悪影響を与えてしまいます。百害あって一利なし、徹底した排除が求められています。本記事では、この作業を人間の感覚でなく、機械的に行う方法について解説します。

★ 誰だって、IE独自機能は機械的に検出したいはず

チェック作業を人の手で行うと、必ず見落としが発生してしまいます。何がIE独自実装で何がWeb標準化を見極めることができないエンジニアに制作/開発を行わせる場合、ソースコードを逐一チェックするのでなく、コンピュータにより機械的にチェックできるようにしたいはずです。

B2BのようなIEのバージョンで縛り開発を行うケースでは、テスト環境が絞られるため、IE独自機能による作り込みの検出をより困難にさせます。ソースコードレビューによるチェックも効果の高い対策ですが、大規模開発ではこれをプロジェクトマネジメント側で可視化し評価できるよう、機械的にチェックできる仕組み作りが求められます。

★ 機械的な検出には「Compat Inspector」が使える

こうしたニーズに応えるため、Microsoftは「Compat Inspector」というツールを提供しています。Compat Inspectorを利用すれば、IE独自機能を検出し、一覧として列挙させることができます。そして大抵の場合は、どのWeb標準に置き換えるべきかアドバイスを行ってくれます。

JavaのFindBugsのように、開発のワークフローに組み込んで活用するのに向いているでしょう。

▼ Compat Inspector
http://ie.microsoft.com/testdrive/html5/compatinspector/

1. Fiddlerのインストールから実行まで

Compat InspectorはJSライブラリであり、検証先のHTMLドキュメント内にScriptタグで埋め込むことにより利用することができます。ただ、開発版から商用版へ切り替えを行う際に、ソースコードに手を加える事を嫌うケースが多いはずです。ビルドプロセスへ組み込むにも、それなりの作り込みを要する上、無駄にバグを作りこむリスクを負うことになります。

こうした背景もあり、Compat Inspectorは単独でなく、「Fiddler」というプロキシツールと併用するのが一般的です。Fiddler側に設定さえ作り込めていれば、1クリックでCompat Inspectorを利用できるため手軽です。また、最近のMicrosoftには珍しく設定をテキストベースで行うという特徴を持ち、環境の配布が容易で大規模での活用にも適しています。

1章ではまず、Fiddlerのインストールを行ってみましょう。
f:id:furoshiki0223:20140102121606p:plain

▼ Fiddlerのダウンロード
http://fiddler2.com/get-fiddler

  • Windows版 : .NET2版と.NET4版が提供されています。Windows 7には.NETの3.5.1がインストールされているため、前者の.NET2版を選択するとトラブルリスクも低いでしょう。
  • Mac/Linux版 : MacやLinuxのようなUNIXベースの環境では、Xamarin社が開発するMonoという.NET互換フレームワークをインストールする必要があります。

f:id:furoshiki0223:20140102112223p:plain

▼ インストールの流れ(Windows版)
f:id:furoshiki0223:20140102111359p:plain

▼ Fiddlerの起動方法(Windows版)
f:id:furoshiki0223:20140102111719p:plain

2. Compat InspectorをFiddler側へ組み込む

前章でFiddlerを実行するまでの流れは、理解できたかと思います。FiddlerはWebサーバとWebブラウザの間を繋ぐ、ただのプロキシツールです。Compat Inspectorをボタン一つで起動できるようにするには、個別に設定が必要です。本章では、この設定方法について説明します。

f:id:furoshiki0223:20140102121909p:plain

先述した通り、Compat InspectorはただのJavaScriptライブラリです。HTMLドキュメント上から呼び出せるよう、Scriptタグで参照させることで利用可能になります。Fiddlerのプロキシとしての特性、機能を活用して、検証対象のWebページにScriptタグを埋め込ませてWebブラウザに読み込ませます。

簡単に「Scriptタグを埋め込む」とは言っていますが、この処理は地味に複雑だったりします。というのは、埋め込みの条件は「全てのScriptタグの読み込みが終わった後」とか、コンテンツタイプはこれじゃないといけないとか、色々な判定処理をFiddler側にスクリプトとして記述し、読みこませなくてはいけないからです。

しかし臆する必要はありません。必要なコードスニペットは、こちらで用意しています。以下の手順に従い、設定ファイルへコードスニペットを埋め込みましょう。

メニューバー「Rules」→「Customize Rules…」
f:id:furoshiki0223:20140102120722p:plain

メモ帳で開かれた「CustomizeRules.js」内に、こちらのカズタマイズ済みの設定ファイルを丸々コピー&ペーストして下さい。ファイルを保存したら、設定は完了です。(※ Fiddler 2.4.5.8でテスト済みです。)

★ インターネット接続できない環境下での利用方法

SIの案件の場合、インターネット接続が禁止された環境下で検証作業を行わなくてはいけないこともあるでしょう。この場合、先ほど丸ごとコピー&ペーストした「Customize Rules…」の内容で、一番下にある以下の行に修正が必要です。

    // Perform the injection at the detected location
    oSession.utilSetResponseBody(
        sBody.Insert(pos, "<script src='http://ie.microsoft.com/testdrive/HTML5/CompatInspector/inspector.js'></script>")
    );
}
}

上記の「sBody.Insert」で指定されているsrcのURLの内容をダウンロードし、イントラネット内のアクセス可能なサーバへ配置し、URLをそちらへ向けて下さい。Compat Inspectorの本体ファイルである「inspector.js」は、インターネット上のリソースへアクセスしない仕様であるため、ローカルで検証処理を完結させることが可能です。

3. Compat Inspectorの実行

2章の設定が正常に完了している場合、メニューバー「Rules」に「Use Compat Inspector」が追加されています。チェックを入れると、Compat Inspectorが有効化します。

有効化している状態で、早速Webサイトへアクセスしてみましょう。IE、Chrome、Firefox、どれでも良いので、ブラウザを起動してテスト対象ページへアクセスして下さい。

一点、注意が必要です。「http://furoshiki.hatenadiary.jp/」のように省略形でなく「http://furoshiki.hatenadiary.jp/test」のようにアクセス先のページを明示するようにして下さい。どうも前者のようなURL表記だと、動作しないようです。画像のように、赤・黄・青の枠と数字が表示されれば成功です。

枠内をクリックしてみましょう。以下のような一覧が表示されます。

f:id:furoshiki0223:20140102232033p:plain

どのような対処が必要かについては、参照されたリンクの内容を確認することになります。リンクで参照されているドキュメントはデフォルトでは英語ですが、「/en-us/」を「/ja-jp/」に修正すると日本語化されます。

http://msdn.microsoft.com/en-us/library/ie/ff986088(v=vs.85).aspx
↓
http://msdn.microsoft.com/ja-jp/library/ie/ff986088(v=vs.85).aspx

f:id:furoshiki0223:20140106110326p:plain

4. 問題に対する対応手順

各色には、以下の意味を持たされています。

Info 許容状態。ユーザによって許容した状態。JSライブラリの検出も行う。
Warning 警告状態。将来的に動かない可能性があり、修正が求められる。
Error エラー状態。既に動かない、致命的な問題を持つ状態。

青色は許容状態なので、カウントは不要です。jQueryなどのJSライブラリの検出も行います。品質をチェックする際に、参考程度に確認して下さい。黄色赤色は対処が必要な項目です。対処としては、以下2種類のワークフローをCompat Inspectorが想定しています。

  1. 対策を行わない。無視する。許容する。
  2. 対策を行う。ソースコードに修正を加える。

★ 1. 対策を行わない。

対策を行わない場合、Infoステータスへ遷移させ、青色に変えます。右の画像にもある通り、Verify用のチェックボックスが付いているため、ここにチェックを入れます。この状態でWebページのリロードを行うと、黄色や赤色は、青色に状態を変えます。

もちろんですが、対策を行わないのはリスクを伴うため、有識者と相談し、この対処が正しいか確認を行う必要があります。

★ 2. 対策を行う。

対策を行う場合は、デバッグ作業を経て動作を確認しながらソースコードの変更を行う必要があるでしょう。

Compat Inspectorにはこれを補助する機能があります。Debugのチェックボックスにチェックを入れて下さい。

F12開発者ツールで確認すると、問題箇所に「debugger」という文字列が埋め込まれています。これはブレークポイントを表す文字列で、開発者ツールを起動している場合は、JavaScriptの処理がここで一旦停止します。

5. 本当にIE独自実装は全て排除すべきなのか?

インターネット向けのサービスの場合、IE8以下のWebブラウザに対応が求められる場合があります。IE8以下は、Microsoft自身も独自実装無くして実装できないことを、暗に認めてしまっている世代のWebブラウザです。実際にCompat Inspectorは、IE8以下では動作できない仕様となっています。

IE独自機能をどうしても必要とする場合、jQueryやBootstrapなどを利用すれば動作の差を多少は吸収することができるはずですが、完全でもありません。悩ましい問題です。Compat Inspectorは、あくまでWeb標準を使うことが正義という前提であり、今というよりこれからの技術とも捉えることができます。

無料でIEのマルチバージョンテスト「Modern.IE」開発での利用時の注意点

Microsoftは、6以降の全てのIEの動作をテストできる手段として、「Modern.IE」というサービスを提供しています。

タイトルでは無料と言っていますが、実際には一部のサービスのみが無料となっています。

本来なら有償のサービスを売り込みたいところなのでしょうが、残念なことに無料のサービスの方が、SI業界の人間であれば待ってましたと言わんばかりの機能性を兼ね備えてしまっています。そのサービスとは「Modern.IE VM」です。

Modern.IE VMとは?

Modern.IE VMとは、90日間無償で利用できる、IEテスト用のVMイメージです。ライセンスが切れても、正規の手順を踏めば再びライセンスされるため、この点で単なる試用版とは異なる特性を持っているように思えます。Windows版の場合、以下の仮想化製品のVMを提供しています。

  • Hyper-V(Windows Server 2008 R2 SP1以上)
  • Hyper-V(Windows Server 2012 以上/Windows 8 Pro)
  • Virtual PC (Win7用)
  • Virtual Box
  • VMWare Player

Webコンテンツは、「OS」+「ブラウザの種類/バージョン」+「ブラウザの制御パラメータ」の3つの組み合わせにより、動作が異なるという特徴を持っていますが、Modern.IE VMではOSとIEのバージョンの組み合わせによる再現性を、ある程度までは網羅できるような状態で提供しています。具体的には、以下のセットです。(2013年12月31日現在)

IE6 IE7 IE8 IE9 IE10 IE11
Windows XP Professional SP3 - - -
Windows Vista Enterprise SP2 - - -
Windows 7 Enterprise - -
Windows 8 Enterprise - - - - -
Windows 8.1 - - - - -

※ ◯=有り、✕=無し、-=動作不可

ダウンロードは、以下のURLへアクセスし、ページ中央の「Mac、Linux、Windows 用の仮想マシンをダウンロードします。」というタイトルのすぐ下で、セレクトボックスの内容を選択しながら進めていきます。
Modern.IE VM - http://loc.modern.ie/ja-jp/virtualization-tools#downloads

f:id:furoshiki0223:20131212224809p:plain
※ 左は仮想化ソフト自体を動かすOS。右は仮想化ソフトの種類です。

ダウンロードファイルのサイズが大きい場合は、分割されています。「.exe」で終わるファイルを実行し、ファイルを一つに繋げる必要があります。なお、Windows XP系VMは日本語が表示できないので、Windows XPのインストールイメージファイルを用意し、ランゲージパックを取得しインストール必要があります。

一つのOS上で、2バージョン以上のIEがテストできる

わざわざ複数のWindowsのマシンを起動しなくても、異なるOS、異なるバージョンのIEがテスト出来るというのは、環境の多様化が進んだ現在において必須のツールでしょう。特に、IE8を動作対象ブラウザにしてしまった場合、IE8とIE9以上の2バージョンでテストしないといけないため、使わないという道すら残されていないように思えます。(→理由がわからない方は、こちらの記事をご覧下さい)

ただ、業務系システムのプロジェクトだと、やはり問題は色々出てきます。まず、セキュリティソフトの入っていないOSを、例え仮想マシン上とはいえ、動作させることを許してくれるかどうか。また、ユニットテストのようなIDEがもろに動いているようなフェーズでは、メモリが不足し動作が困難になるかもしれません。

なんだかんだ言っても、JUnitを扱うようなノリでさらっとRFPやらシステム提案書に書けるほど簡単で無いのがこのサービスの難しい所です。色々なリスクを抱えつつも、そのコストパフォーマンスの高さからどうにかしてでも使いたくなる、いかにもありがちなジレンマに陥っています。

利用時の注意点

ここからは、Modern.IE VMの商用利用時の注意点についてまとめます。 なお、参考にしているライセンスは、2013年7月22日現在のものです。
(※参考 : license 2013-07-22 - Modern.IE )

リバースエンジニアリングするなとかリコンパイルするなとか、Microsoft製品全般に言える、基本的な部分については全て割愛しています。

★ テスト以外には使ってはいけません!

  1. テスト用途として利用することが許されます。
  2. 業務用のOSとして使ってはいけません。
  3. 日常利用するためのOSとして使ってはいけません。

※ 2番について利用許諾内の解釈が難しかったためMicrosoftに確認したところ、あくまで「テスト」という目的であれば、商用の開発プロセス内で組込み利用することが可能とのことです。つまり、普通のSIの開発のテストフェーズで利用する分には何も問題無いということです。

★ ライセンスは90日間です!

  1. VMのダウンロードを行うと、利用許諾に同意したものとみなします。
  2. ダウンロードしたVMイメージ、もしくは初期起動後の状態のスナップショットが、90日間だけライセンスが有効となります。
  3. ライセンスが切れても、再度ライセンスすることができます。(1回目が切れたから、2回目という使い方はOK。要は、同じVMを91日以上使うなという意味。ライセンスが切れると、そのVM内に含まれているデータを取り出すだけでもアウトとも読み取れますので、テストという特性上注意が必要ですね。)
  4. アクティベーションを促されますが、アクティベーションしてはいけません。(プロダクトキーとか入れないで使ってくれという意味です。)

※ 上記、2と3についてはMicrosoftへ確認し発覚した点の共有です。

★ 物理マシンに1台までです!

  1. VMは一度に一人しか利用できません。一人に対して、一つのOS一つのハードウェアでしか使ってはいけません。
  2. 物理マシン上でしか利用してはいけません。
  3. ストレージがケーブル接続されているコンピュータのハードウェアに限ります。
  4. ハードウェアパーティションで区切られたもの、ブレードPCも1台とみなします。
  5. リモートアクセスは許可されています。(※XP/Vista/7/8系個別で定義されており、全てのライセンスで許容されている模様。)

※ このあたりは、シンクライアント環境下の開発のまとめです。一つのハードウェア上に複数VM動かして良いのかという点については、文章からはあまり読み取りにくい感じです。アウトなニュアンスに見えます。

UNIX系環境で楽してダウンロードする方法

wgetで、分割されたファイルを一括ダウンロードする方法もあります。各VMのダウンロードまとめに、ダウンロード先が記述されている「.txt」で終わるテキストファイルがあるので、これを直接指定すれば楽できます。

f:id:furoshiki0223:20131218025719p:plain

wget –i https://az412801.vo.msecnd.net/.../IE8.Win7.For.LinuxVirtualBox.txt

>> Webシステム・ガイドライン集

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システム・ガイドライン集

HTML5世代のJavaScriptからマウスイベントの扱い方、Pointer Events

この記事は古くなっています。こちらを参照して下さい。

これまでマウスイベントの扱いは、以下のような記述方法でした。

var elem = document.getElementById("hoge");
if ( elem.addEventListener ) {
        // IE9以上/Firefox/Chrome
        elem.addEventListener("mousedown", fn);
    } else {
        // IE8以下向け下位互換対策
        elem.attachEvent("onmousedown", fn);
    }
}

上記はマウスが存在するという前提で成立していたもので、今後はマルチデバイス対応が求められる時代になります。

今のところはデスクトップ型向けとスマートデバイス型とでは、ユーザエージェントを使ってビューを切り替えるという方法が主流のようです。しかし今後は、Windows 8的マウスもタッチデバイスもいるような環境が当たり前になるかと思います。どんなページであっても、Webページは複数種類のデバイスから扱われることを前提とすべきでしょう。

Web標準では、これを柔軟に解決するための方法を提供しています。

1. Pointer Eventsの考え方

f:id:furoshiki0223:20131209163332p:plain

Web標準では、マウス/タッチパネル/ペンなどのデバイスは、「ポインター」という抽象的なデバイスとして扱うことで、デバイスの差異を吸収します。もちろん従来のマウスのイベントを利用してもタッチパネルは扱えますが、標準に準拠した統一された動作を実現するには、「ポインター」を利用する必要があるでしょう。

既存のマウスイベントについても、「ポインター」である程度カバーできているため、今後のことを考えるとこの手段に置き換えることが望ましいです。

2013年、現時点での現実的な記述方法としては、こうなります。

var elem = document.getElementById("hoge");
if(navigator.pointerEnabled) {
        // IE11以上+モダンブラウザ用(※現在推奨)
        elem.addEventListener("pointerdown", fn);
} else if (navigator.msPointerEnabled) {
        // IE10+Win8の下位互換対策(※2016年1月中旬まで必要)
        elem.addEventListener("MSPointerDown", fn);
} else if ( elem.addEventListener ) {
        // IE9もしくはIE10+Win7向け下位互換対策(※2020年1月まで必要)
        elem.addEventListener("mousedown", fn);
} else {
        // IE8以下向け下位互換対策(※2020年1月まで必要)
        elem.attachEvent("onmousedown", fn);
}

すごく長いですね・・・。IEに独自実装されていたattacheEvent(※11から削除)にも配慮しつつ、新しいイベントの記述方法まで意識しなくてはいけない。もはや、ハックに近い行為です・・・。

ただ、Windows 7が世の中から消えた頃には、こうなっています。

var elem = document.getElementById("hoge");
elem.addEventListener("pointerdown", fn);

ドキュメントは、W3Cサイトにて「Pointer Events」として公開されています。日本語だと、MicrosoftのIE11周りのドキュメントが一番上手くまとまっているように思えます。
(※参考 : ポインターイベント - Microsoft )

2. 出遅れた入力周りの標準

IEは、2バージョンワンセットの傾向があり、IE5と6、7と8、9と10とで、同じ動作傾向、バグの共有が行われていることから、おおよそ同じコードベースが使われているものと考えられます。
(※参考 : IE5-6、7-8共通のPNG表示不具合 - ふろしき.js )

そして、ディスプレイ周り、所謂レスポンシブWebデザイン対応についてはIE9世代で整備されましたが、入力周りについては、Appleのマルチタッチ特許のなど諸々の問題が絡み、本格的な対応はIE11世代からとなったようです。

f:id:furoshiki0223:20131209170322p:plain

IE11はWindows 8系の最低バージョンになりますので、実用性という面ではWindows 7系が衰退したころでしょう。

【企業システムの2020年問題】IE8以下向けのWebシステムのEOLは、2020年より後になってはいけない

バージョン8までのIEは、Microsoftが暗に独自性が高いことを認めているブラウザです。

同じHTML/CSS/JSであっても、バージョンごとに異なる仕様として動作することがあります。このため、上位のバージョンのIEで動作させるには「ドキュメントモード」いう機能を利用しなくてはいけません。

IEは、過去のレンダリングエンジンを再現させる機能を持っており、IE8からはドキュメントモードという名称で提供されています。Windows 9x/XP世代のWebシステムは多くの場合、IEのドキュメントモードを利用することで維持できているという状況です。
(※参考 : ドキュメント互換性の定義 - Microsoft )

しかし、IE11からはこのドキュメントモードが非推奨となり、今後サポートされなくなる可能性があります。現在のWindows8系OSのIEの最低バージョンである10は、2015年中旬でサポートが切れるため、今後のクライアントOS移行では実質的にドキュメントモードが利用できなくなってしまいます。
(※参考 : ドキュメント モードの非推奨 - Microsoft )

つまり理論上、IE8以下向けに作られたWebシステムは、Windows 7のEOLである2020年1月14日までに、相互運用可能なブラウザであるIE9以上向けに移行しなくてはいけません。

企業内の標準ブラウザとしてIE8を利用している場合、新規開発されるWebシステムも8向けになってしまいますので、早急にIE9以上へアップグレードする必要があります。Windows 7のEOLは2020年1月ですが、OS自体のアップグレードが早めに行われることを考えると、全くと言って良いほど時間がありません。

また、IE9以上を標準ブラウザとしていても、ドキュメントモードを利用しているレガシーWebシステムを移行を行わなくてはいけません。IEは独自実装は廃止し、古いWeb標準はある程度サポートするという方針のようなので、シンプルな仕組みで作られていた場合は、多少のレイアウト崩れ程度で動くかもしれません。ただ、Windows 8移行時直前に出来るほどリスクが低くないため、早めから意識する必要があるでしょう。

これらの対策が十分でない場合、クライアントOSのアップグレード時にシステムが動かなくなり、泣く泣くサポート切れの状態でWindows 7を保守し続けなくてはいけないという状況に陥ることが予想されます。

IE8向けWebシステムを作る際の対策

Windows 7のIEの最低バージョンは8であるため、今後もIE8向けWebシステムを新規で開発しざる得ない場合があるでしょう。IEは1OS上にマルチバージョンのインストールが許容されません。したがって、以下のような対策が必要になります。

★ 1. IEをアップグレードする。

IEをアップグレードするという、技術的に見ればベストな手段です。

ただし、IT運用の予算枠にIEのアップグレード分を追加して貰わなくてはいけないという問題があります。ユーザ企業側にこのような技術的課題への理解があり、トータルコスト最適化のために対策に乗り出そうとしている場合はスムーズに話が進むかもしれませが、単独にてシステム開発を受注した場合、この方法は採用しにくいでしょう。技術面でのベストな手段が、大人の事情からベストにはなり得ないという耳が痛い話です。

★ 2. Windows 8以上への移行日までをシステムのサポート期間とする。

Windows 7のEOLである2020年1月14日に移行期間を含め、2019年1月あたりまでをサポート期間としてしまう作戦です。

開発に1年かけたとして、5年維持できないという短命なシステムを開発します。システム化対象のサービス(業務)がPPM的に「問題児/花型」なステータスであれば、短いライフサイクルで改善が進むため問題は小さいかもしれません。しかし、「金のなる木/負け犬」の場合は現実的な選択とは言えません。最終的に移行時期に画面周りを全部改修して一斉移行するリスクを考えても、得策とは言えないでしょう。開発ベンダ側にとってはお得感がありますが、ユーザ企業にとってはトータルコストが大きい迷惑な方法と言えます。

★ 3. IE8とIE9以上(FireFox/Chrome)で動くように作る。

IE8とIE9以上(Firefox/Chrome)で動くように対策し、テストするという作戦です。

IE8向けには条件付きコメントやユーザエージェントによる検出を行い対策し、IE9以上には機能/動作検出型の開発をすることで、Windows 7のEOLに縛られないライフサイクルを確保します。当然ですが、普通に開発するよりもお金がかかります。Javaのようなキレイなやり方とは言い難く、マネジメントでの可視化も難易度評価も難しい、泥臭い方法になります。ユーザ企業側がこの問題を理解している場合、開発ベンダ側は要件フェーズで明確にスコープ定義をしておかないと、なし崩し的に対策を行う必要が生じ、火を吹く可能性があります。当然ですが、このような問題に対してはベンダ側からユーザ企業へ、IE8特化システムのリスクを事前に説明し理解を得る必要があるでしょう。

★ 4. Firefox/Chromeのみ対応にする。

IE向けに作ることを諦めるという作戦です。

しかし、エンタープライズ用途で利用されることを前提としているIEだからこそ受けられる恩恵、例えば長い期間のサポートを受けられなかったり、IT管理者によるActive Directoryなどの機能を使った統合管理が一切使えなくなります。Windows依存との完全な決別です。Windows 7時代はこのような方法は全く無いというわけでも無さそうですが、セキュリティ管理がいい加減になりやすいため、IT管理者側でも追加でセキュリティ強化ツールを選定するなど、IE以上に注意深く監視をする必要があります。

Firefoxに限定するなら、以下のページで開発のポテンシャルを確認できます。
>> Firefox向けWebシステム開発でできること・できないこと - ふろしき.js

なお、Firefoxの場合は、法人向けに標準化対応を行うサービスも提供しています。Webシステムのフロントエンド部分について、ライフサイクルを長期に渡り動作させれるというのは魅力的かもしれません。
>> 法人向けサポートのご案内 - Mozilla

Windows XPのアップグレード時に、IE5向けWebシステムが無いことを前提に移行してはいけない

IEのドキュメントモード機能が存在しなかったIE5〜7で、どのバージョンでも同じ仕様を持つプラットフォームを得るには、IE5の動作を再現させる「Quirksモード」を有効にするしか手段がありませんでした。

当時のIEは相互運用性が低く、バージョンごとの動作が異なるため、マルチバージョン下で動作するコンテンツ制作はコストが高くなりがちでした。そこで、少し複雑性の高い作り込みをクライアント側へ仕込む場合、レガシーIE向けコンテンツを動作させるために作られたはずの「Quirksモード」を、あえて有効にして新規開発を行った方が、IEのマルチバージョン下で動作させるWebシステムのリスク・コストを最小化させるという最悪のジレンマに陥りました。

このジレンマは、IE8への段階的移行を行っている際にも有効になります。IE6や7で動作させていた時は最新のレンダリングエンジン(標準モード)で動作させていたにも関わらず、IE8では動作がおかしくなるため、全てのHTMLドキュメントからDOCTYPE宣言を外し、Quirksモードが有効化させるという良くない手段に出てしまいます。

本来であれば、「イントラネット互換表示」を活用すべきですが、ActiveDirectoryへの変更が提案できないなどの要因が絡み、システム単体で対策できるDOCTYPEを外すという手段に出てしまいます。非常に良くないジレンマです。

このバッドプラクティスは、理論上、社内の標準OSがWindows7になるまで有効化します。既存の環境にはIE5がいないから大丈夫だと安心していると、問題になることがあります。OSの移行担当者は、Windows XPのバージョンアップ対応では以下の点に注意する必要があります。

1. IE8〜11への移行時の注意点(その1)

IE8から11では、X-UA-Compatibleという機能が提供されています。このパラメータを利用した場合、IEはDOCTYPEスイッチよりも、X-UA-Compatibleの設定を優先してしまいます。IE6向けのWebシステムをIE8〜10へ移行する場合、X-UA-CompatibleにはIE7を指定するのが定石です。しかし、何も考えずに以下を設定するのは危険です。

X-UA-Compatible : IE=7

最も安全なのは、以下の設定です。

X-UA-Compatible : IE=EmulateIE7

この設定は、デフォルトはIE7互換で動作させ、DOCTYPEスイッチの内容次第ではQuirksモードで動作させるという動きになります。

そもそもですが、Windows7系の場合、IE6向けコンテンツを動作させるには、「イントラネット互換表示」を利用するか、IEのバージョンが9〜10の場合は「互換表示リスト」を利用すべきです。これらの機能を利用した場合、DOCTYPEスイッチの判定が優先されるため、リスクが最適化されます。通常時はIE7モードとして動かし、DOCTYPEスイッチでQuirksモードが有効な場合は、Quirksモードが優先されるという、望ましい動作をします。

なお、IE8だけは、互換表示リストが有効な場合は常に「Quirksモード」になります。このため、移行は「イントラネット互換表示」を使うか、「X-UA-Compatible」を各システムに設定して回るという非常に泥臭い対策を行わなくてはいけないことがあります。

2. IE8〜11への移行時の注意点(その2)

IE6はXHTML1.0のDOCTYPEの解釈に問題があり、意図せずQuirksモードで動いていることがあります。これに気付かず開発が行われていた場合、IE7以上への移行では、イントラネット互換表示も、互換表示リストも使うことができない、実質的にX-UA-Compatibleでしか対策が行えないという状況に陥ります。

詳しくは、以下のページを参照して下さい。

>> XHTML1.0の場合、IE6からIE8〜10への移行時に表示が乱れることがある

3. IE10への移行時の注意点

IE10では、Quirksモードが2種類あります。単純にDOCTYPE宣言を使ってQuirksモードを動作させた場合、IE5とは互換性の無いQuirksモードが動作してしまいます。これを改善するには、X-UA-Compatibleとの合わせ技が必要です。

詳しくは、以下のページを参照して下さい。

>> IE6〜9とIE10とでQuirksモードの動作が違う

4. IE11への移行時の注意点

IE11からは、DOCTYPEスイッチが無視されます。従来の方法では、Quirksモードは有効になりません。
(※参考 : IE11ではDOCTYPE宣言がチェックされない - ふろしき.js )

IEは11でドキュメントモードが非推奨化されたため、今後は機能が廃止されることも予想されます。Quirksモードで動作しているWebシステムは、「動作/機能検出」の指針に基づいた作り込みで、相互運用性の高いIE9以上で動作するように改修する必要があります。
(※参考 : 機能検出と動作検出の使用 - Microsoft )

XHTML1.0の場合、IE6からIE8〜10への移行時に表示が乱れることがある

XHTML1.0のDOCTYPE宣言にはいくつか種類があり、IE7以上では常に最新のレンダリングエンジンである「標準モード」として動作します。しかし、IE6は一部の宣言方法で一番古いレンダリングエンジンである「Quirksモード」として動作してしまいます。
(※参考 : The <?xml> prolog, strict mode, and XHTML in IE - IEBlog )

IEには古いレンダリングエンジンを再現させるドキュメントモードという機能が備わっており、「互換表示ボタン」「互換表示リスト」「ローカルネット互換表示」「X-UA-Compatible」などを通じてドキュメントモードを制御し、新しいバージョンへ移行させることが多いでしょう。しかし、これらの機能はDOCTYPEスイッチの切り替えアルゴリズムまでは再現してくれず、問題となるケースがあります。

具体的には、以下の通りです。

6 8〜10 DOCTYPE宣言
S S <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
Q S <?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
S S <!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
Q S <?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
S S <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">
Q S <?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">

IE6でテストされたWebシステムを開発していた際に、開発者が誤動作に気が付かず「Quirksモード」を前提に画面のレイアウトを作りこむと、IEのバージョンアップ時に挙動がおかしくなることがあります。

移行時の対策

誤動作によりXHTMLドキュメントをQuirksモードで動作させてしまっている場合、IE8以上ではX-UA-Compatibe以外からQuirksモードを再現させる方法はありません。このため、サーバ管理者はシステムを動作させているAP製品に対して、HTTP Response Headerへ以下のパラメータを応答させるよう設定が必要になります。

X-UA-Compatible: IE=5

より詳細な設定の方法については、以下のページを参照して下さい。

どういうケースが想定されるか?

この事象は、決してレアケースというわけではありません。

業務系で利用されるServer-side Scriptingの既定は、HTML5のような新しいWeb標準を利用する場合でも、XHTMLに沿って記述することが多いです。JavaのJSFもまさにそうでしょう。

DOCTYPE宣言は、XHTML1.0で宣言しても、HTML5の機能を利用することが可能です。IEも含め多くのWebブラウザは、XHTML1.0、HTML5、どちらの宣言を行っても、同じレンダリングエンジンが選択されるようにできています。HTML5は一部の廃止タグを除き、XHTML1.0と相互運用可能な言語仕様になっているため問題になりません。

f:id:furoshiki0223:20131205200136p:plain

Webブラウザ以外のソフトウェアからHTMLを読み込ませる場合、XMLパースが行える方が便利でしょう。この場合、XML宣言が行えるXHTML1.0のDOCTYPE宣言は、非常に有用なものとなります。XML宣言は本来任意ですが、無いと動作しなパーサものもあります。素直にHTML5のDOCTYPE宣言を行いたいところですが、XMLパーサの活用を考えると、今後もあえてXHTMLのDOCTYPE宣言を行うということは少なくないはずです。

IE6向けシステムは、JSPのような古い技術を利用していた場合は問題になりません。しかし、それこそJSFのような新しい技術を使って強引に動作させようとすると、何かしらの問題を作りこむ可能性を持ちます。IEのバージョンの世代と、サーバ技術の世代に開きが大きい場合は、注意して下さい。

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

IEの持つ互換性機能の全て - DOCTYPEスイッチ/X-UA-Compatible/互換表示

IEはかつて、独自の機能実装により安定かつ高度な機能を持ったプラットフォームを実現しました。特に、IE6のポテンシャルの高さは、Web技術発展へ大きく貢献しています。

しかし同時に、他のブラウザとは異なる独立した挙動をしたり、バージョンごとに機能面に開きがあるなど、相互運用性の面に大きな課題を作ってしまいました。多くの企業は、IEの特定のバージョンへ強く依存した既存資産と、IEのアップグレード方法に頭を悩ませているでしょう。

Microsoftはこの問題に対応するため、IEは過去のバージョン向けに開発されたWebコンテンツを動作させるための仕組みを持っています。これを「ドキュメントモード」といいます。

本記事では、IEの持つドキュメントモードを利用した互換性の考え方について解説します。IEのアップグレード時に、移行方法の指針、手段の発見に活用して頂ければ幸いです。

★ 目次

  1. DOCTYPEスイッチ・・・開発者向け
  2. X-UA-Compatible・・・開発者向け
  3. 互換表示モード・・・IT管理者/ユーザ向け
  4. ドキュメントモードでは解決されない問題・・・開発者向け

★ 注意事項

ドキュメントモードは、IE11より非推奨となりました。このため、本対策が活用できるのは事実上Win7版IE10までとなり、Win7のEOLである2020年1月14日に正式なサポートは終了となります。Win8以上のOSへアップグレードするまでに、全Webシステムをドキュメントモード依存やIE8特化しない状態に改善することが求められています。
(※参考 : ドキュメント モードの非推奨 - Microsoft )
(※参考 : ドキュメントモードに依存しない開発方法について - ふろしき.js )

1. DOCTYPEスイッチ

「DOCTYPEスイッチ」とは、HTMLドキュメントの一番初めに「DOCTYPE宣言」というHTMLフォーマットを意味する特殊な文字列を記述することで、Webブラウザの動作をQuirksモードとStandardモードのどちらかの状態へスイッチさせる手法です。開発者が、IEのドキュメントモードを制御するために利用できます。

Quirksモードとは、主にHTML3.2以前のWebコンテンツに対して、IE5の古いレンダリングエンジンを提供する機能です。IE6〜10では標準的に提供されていますが、IE11ではドキュメントモードの非推奨化に伴い、限定的な手段により提供されています。

対してStandardモードは、最新のレンダリングエンジンにより動作をさせる機能です。

以下は、IEの各バージョン別のDOCTYPEスイッチの動作一覧です。全体を通しての考え方や注意点は、後述する5つのポイントを確認して下さい。

★ a. IE6〜10は、HTML3.2以前はQuirks、HTML4.01以降はStandardと解釈

IE6〜10ではDOCTYPE宣言の解釈は、基本的にHTML4.01を起点にしてスイッチされます。HTML4.01については、以前のバージョンのHTMLの仕様を許すDOCTYPEもあるため、その扱いは非常に煩雑です。

HTML4.01のDOCTYPE宣言において、おさえるべきポイントは以下の通りです。

1. Transitionalと明示した3.2と4.01の混在を意味する定義は、Quirksモード
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

2. Framesetと明示した3.2と4.01の混在を意味する定義は、Quirksモード
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN">

3. Transitional/Framesetの指定が無いStrictと呼ばれる定義は、Standardモード
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">

4. 4.01のDTDを明示的に指定した場合は、上記の条件に関係なく常にStandardモード
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

現在は、IE6~11で最新のドキュメントモードが選択される、HTML5のDOCTYPEが推奨されています。

★ b. IE11ではQuirksモードへスイッチできない

IE11からは、ドキュメントモードが非推奨になったため、DOCTYPEスイッチによってQuirksモードへのスイッチが行えません。
(※参考 : ドキュメント モードの非推奨 - Microsoft )

Quirksモードで動作させるには、IEの利用者/IT管理者による対策が必要です。以下の方法で解決が可能ですが、IE12以降でもこの方法が永続的に利用できることは保証されていません。Microsoftではこのような対策を必要とするWebコンテンツは、改修を推奨しています。

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

★ c. IE6のXHTML1.0のDOCTYPEの解釈に問題がある

IE6のXHTML1.0のDOCTYPE宣言は解釈に問題があり、IE6とIE7以上とでは、Quirksモードに切り替わるためのルールが異なります。具体的には、以下の文字列が宣言されている場合、IE6ではQuirksモードで、IE7〜10ではStandardモードとして動作します。

<?xml version="1.0" encoding="utf-8"?>

以下のページにて、この問題に対する解決策を説明しています。
>> XHTML1.0の場合、IE6からIE8〜10への移行時に表示が乱れることがある

★ d. IE10ではQuirksモードがIE5の動作にならない

IE10から、QuirksモードがIE5と互換性が無くなっています。ただし、IE5と互換性のあるドキュメントモードは内部的に「IE5 quirksモード」として残されています。

このドキュメントモードを利用したい場合、以下のページを参考に解決方法を探ってみて下さい。

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

★ e. RFC2070のDOCTYPEは正常に解釈されない

RFC2070には、HTML2.0を意味するDOCTYPE宣言があります。
(※参考 : Internationalization of the Hypertext Markup Language )

しかしこれは、IEでの解釈に問題があり正常に動作しません。具体的には、以下のDOCTYPE宣言は、歴史的に見るとIE6〜10ではQuirksモードとして動作すべきですが、実態としてStandardモードと解釈されてしまいます。

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML i18n//EN">

この問題を抱えたWebコンテンツを「Quirksモード」で動作させるには、次章の「X-UA-Compatible」による対策を検討して下さい。

2. X-UA-Compatible

IEは内部的に、IE5以降のレンダリングエンジンを再現させるための機能を持っています。これを制御するには、「X-UA-Compatible」を利用します。

以下は、IEの各バージョン別のX-UA-Compatibleの使い方/動作仕様です。動作の違いなどおさえるべき点は、後述する5つのポイントを確認して下さい。

★ a. IE6互換のドキュメントモードは無い

IE5以降のレンダリングエンジンを揃えているIEですが、歴史的経緯によりIE6の互換モードだけは提供できていません。多くの企業システムでは、移行時にIE6コンテンツをIE7互換モードで代替し動作させているようです。

★ b. IE10にはQuirksモードが2種類ある

IE6/7/8/9と、QuirksモードはIE5の機能性を維持してきました。しかしIE10からは、QuirksモードがHTML5との相互運用の観点から完全な互換性を持たないことを、Microsoftとして公式に発表しています。

ただし、IE10にはQuirksモードが2種類あり、新たに追加した「IE5 quirksモード」がIE5との互換性を持ちます。

単純なDOCTYPEスイッチでは、無印の「Quirksモード」が選択されます。対して、ドキュメントモードにより直接「IE5」の指定を行った場合は「IE5 quirksモード」が選択されます。

詳しくは、以下のページを参照して下さい。

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

★ c. X-UA-Compatibleの指定は全てにおいて優先される

ドキュメントモードを制御する方法としては、「互換表示ボタン/互換表示リスト」「DOCTYPEスイッチ」などがありますが、X-UA-Compatibleは全てにおいて最優先の制御を握ります。IE=EmulateIEが利用された場合も、互換表示の影響を受けません。

この特性を活かし、企業システムでは、互換表示機能により全体的に保護されたイントラネット内で、一部のシステムにのみ異なるドキュメントモードを適用する場合に利用されます。

★ d. IE11のIE=EmulateIE10には不具合特殊な動作がある

(※ 2013.11.27 - 不具合でなく仕様でした。)

IE11のX-UA-Compatibleへ「IE=EmulateIE10」を指定した場合、DOCTYPEスイッチが正常に動作しないという不具合がありますDOCTYPEスイッチの動作にはユーザには見えない仕様が含まれています。詳しくは、以下のページを参照して下さい。

>> IE11のEmulateIE10(X-UA-Compatible)でDOCTYPEスイッチに不具合がある(仕様でした)
>> IE11を裏ワザ的なやり方でDOCTYPEスイッチを有効化する方法

★ e. IE8とIE9以上の間ではIE=(数字)の判定式が違う

IE8とIE9とでは、X-UA-Compatibleの値の扱い方、そのルールが異なります。

この動作の違いは、互換表示リスト/互換表示ボタンの有効化に影響を与えます。将来に渡り有効になることを想定して、パラメータへ「IE=100」などの大きな値を設定した場合、IE9/10/11では問題にならないが、IE8では誤動作を起こすというケースがあります。

マルチバージョン対応が求められ、X-UA-Compatibleの振る舞いに厳密な限界値テストを必要とする場合、8と9以上とで分類してテストすることが推奨されます。

3. 互換表示モード

「互換表示モード」とは、Internet Explorerへの設定を利用して、IE5/IE7のドキュメントモードで動作させるための方法です。IT管理者/ユーザが、IEのドキュメントモードを制御するために利用できます。

IE11ではドキュメントモードは非推奨ですが、互換表示の機能は残っています。ただし、Microsoftはドキュメントモードは非推奨としており、互換表示機能も永続的にサポートされないことが予想されます。

互換表表示機能の利用方法としては、以下3つが挙げられます。

IE8〜10では、利用者側で互換表示を制御する「互換表示ボタン」が提供されています。

IE8〜11では、利用者側で互換表示を制御する「互換表示一覧(リスト)」が提供されています。

IE8〜11では、IT管理者向けに「ローカルイントラネット互換表示」が提供されています。

★ a. 互換表示リストはドキュメントモードのバージョンを選択できない

互換表示リストで定義できるのは、IE8の場合はQuirksか最新のドキュメントモードか、IE9/10/11ではIE7か最新のドキュメントモードかの、2種類のみから選択されます。バージョンの指定までは、互換表示リストからは制御できません。

Microsoftが提供している互換リストはドキュメントモードの指定が行えるため、ここへ直接書き込むというハックもあります。しかし、定期更新の際に上書きされるため、有用な手段とは言えません。Microsoftはこのような利用シーンでは、X-UA-Compatibleの利用を推奨しています。

★ b. IE10はQuirksが有効かつ互換表示が有効の場合、IE5 quirksモードで動作する

IE10にはQuirksモードが2種類あり、デフォルトのDOCTYPEスイッチで動作するQuirksモードはIE5との互換性を失っています。しかし、互換表示が有効の状態でQuirksモードが選択された場合、「IE5 quirksモード」というIE5と互換性があるQuirksモードが選択されます。

★ c. ローカルイントラネット互換表示が有効時は、互換表示ボタンが表示されない

ローカルイントラネット互換表示の適用範囲では、互換表示ボタンが表示されません。これを利用すれば、システム利用者の誤操作によるトラブルを避けることができます。

4. ドキュメントモードでは解決されない問題

★ a. 不具合とCSSデフォルト値までは再現されない

IEが持っている不具合やCSSデフォルト値までは、再現することができません。問題になりやすいものについては、以下のような対策がユーザによって考案されています。

★ b. OSのAPI依存の動作までは再現されない

IEは、他のWebブラウザとは異なり、WindowsOSのAPIを極力利用する方針です。このため、同一のWindowsブランドであっても、バージョンごとに差異が生じることがあります。

IEの互換系機能を利用して以降を行う場合、テストの目安として、OSレイヤーでの仕様の差異を意識して下さい。

詳細は、以下のページを参考にして下さい。

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

★ c. ドキュメントモードの動作が完全ではない

ここで紹介した3種類の互換性対策用機能は、全てIEの内部で持つドキュメントモードを利用しています。IEはバージョンアップを繰り返す都度、過去のIEのレンダリングエンジンを揃えてきましたが、筆者の検証環境の結果では、全く同じバイナリの状態を維持していないように見えます。テストの不足から、バージョン間でその機能性に微妙な差異が生じています。

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

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

川田 寛

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

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や業界内のトレンドなどの情報を発信しています。私と話をしてみたいという方は、以下のフォームより気軽にご連絡ください。

お問い合わせフォーム