古い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のインストールを行ってみましょう。
▼ Fiddlerのダウンロード
http://fiddler2.com/get-fiddler
- Windows版 : .NET2版と.NET4版が提供されています。Windows 7には.NETの3.5.1がインストールされているため、前者の.NET2版を選択するとトラブルリスクも低いでしょう。
- Mac/Linux版 : MacやLinuxのようなUNIXベースの環境では、Xamarin社が開発するMonoという.NET互換フレームワークをインストールする必要があります。
▼ インストールの流れ(Windows版)
▼ Fiddlerの起動方法(Windows版)
2. Compat InspectorをFiddler側へ組み込む
前章でFiddlerを実行するまでの流れは、理解できたかと思います。FiddlerはWebサーバとWebブラウザの間を繋ぐ、ただのプロキシツールです。Compat Inspectorをボタン一つで起動できるようにするには、個別に設定が必要です。本章では、この設定方法について説明します。
先述した通り、Compat InspectorはただのJavaScriptライブラリです。HTMLドキュメント上から呼び出せるよう、Scriptタグで参照させることで利用可能になります。Fiddlerのプロキシとしての特性、機能を活用して、検証対象のWebページにScriptタグを埋め込ませてWebブラウザに読み込ませます。
簡単に「Scriptタグを埋め込む」とは言っていますが、この処理は地味に複雑だったりします。というのは、埋め込みの条件は「全てのScriptタグの読み込みが終わった後」とか、コンテンツタイプはこれじゃないといけないとか、色々な判定処理をFiddler側にスクリプトとして記述し、読みこませなくてはいけないからです。
しかし臆する必要はありません。必要なコードスニペットは、こちらで用意しています。以下の手順に従い、設定ファイルへコードスニペットを埋め込みましょう。
メニューバー「Rules」→「Customize Rules…」
メモ帳で開かれた「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表記だと、動作しないようです。画像のように、赤・黄・青の枠と数字が表示されれば成功です。
枠内をクリックしてみましょう。以下のような一覧が表示されます。
どのような対処が必要かについては、参照されたリンクの内容を確認することになります。リンクで参照されているドキュメントはデフォルトでは英語ですが、「/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
4. 問題に対する対応手順
各色には、以下の意味を持たされています。
| 青 | Info | 許容状態。ユーザによって許容した状態。JSライブラリの検出も行う。 |
| 黄 | Warning | 警告状態。将来的に動かない可能性があり、修正が求められる。 |
| 赤 | Error | エラー状態。既に動かない、致命的な問題を持つ状態。 |
青色は許容状態なので、カウントは不要です。jQueryなどのJSライブラリの検出も行います。品質をチェックする際に、参考程度に確認して下さい。黄色と赤色は対処が必要な項目です。対処としては、以下2種類のワークフローをCompat Inspectorが想定しています。
- 対策を行わない。無視する。許容する。
- 対策を行う。ソースコードに修正を加える。
★ 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標準を使うことが正義という前提であり、今というよりこれからの技術とも捉えることができます。
Webアプリのパフォーマンス改善と言えば、JavaScriptやDOMアクセスなど、既存の技術ベースな改善手法を想像する方も多いでしょう。最近では、こうした改善のあり方を、別の視点からもう少し広げようというアイデアが存在感を持ち始めています。それは「Web標準」です。
Microsoftは、6以降の全てのIEの動作をテストできる手段として、「Modern.IE」というサービスを提供しています。
わざわざ複数のWindowsのマシンを起動しなくても、異なるOS、異なるバージョンのIEがテスト出来るというのは、環境の多様化が進んだ現在において必須のツールでしょう。特に、IE8を動作対象ブラウザにしてしまった場合、IE8とIE9以上の2バージョンでテストしないといけないため、使わないという道すら残されていないように思えます。(→
