Windows 7時代のWebシステム開発は、IEの大幅な設計指針の変更に伴い、開発指針を従来の「バージョン依存型」から「機能/動作検出型」へ変更する必要が生じています。
本記事では、その必要性について、IEの過去の歴史やロードマップ、また従来の開発方式を維持した場合のリスクについて解説します。
IEは何故、開発指針を変える必要があったのか？
過去のIEは、未成熟なWeb標準で高い機能性を獲得するため、独自実装という方針で開発を続けてきました。結果としてIEは、リリースするバージョンごとに、同じHTML/CSS/JSを利用しても異なる仕様で動作するようになりました。
当時のIEは、Webコンテンツを古いバージョンと新しいバージョンの双方で問題なく動作させるために、バージョン特化の対策を促す機能を提供しました。
開発者は、条件付きコメント(バージョンベクター)や、ユーザエージェントからバージョンを検出して、バージョンごとにビューを切り替えるという対策を行いました。また、IEのバージョンを上げる際には、IEが持っている過去のレンダリングエンジンを使ってエミュレートさせることで、移行コストを最小化してきました。
しかし、この方法には問題があります。
IEは、保守しなくてはいけない過去のエンジンが増え続けています。IE6や7の頃は2種類程度を扱えれば十分でしたが、2013年12月現在、最新のバージョンである11では、7種類のエンジンを抱えメンテナンスが困難になりました。
また開発者も、日に日にアクセスしてくるIEのバージョンの種類が増え、対策には多くのコストが必要となりました。IEがバージョンアップするほど、IE側とシステム開発者側の双方が、コストが増え不幸になるという悪い状況に追い込まれました。
Microsoftはこの問題に対応するため、IE9からは「機能/動作検出」による開発を促す方針に転換しました。この方法は、近年登場したWeb標準「HTML5」に準拠し、これまで維持してきた独自機能もこれに置き換えることで、ブラウザ間バージョン間での動作の違いを無くし、長期に渡り最新のレンダリングエンジンで動作可能なWebシステムの開発が行えるようにするというものです。
近年のIEは、バージョン検出が行える機能を削除しつつあります。また、Windows 8以降のOSのIEでは、過去のレンダリングエンジンを利用する機能は「非推奨」となり、今後削除される可能性があります。こうした背景から、Webシステムの開発指針は、本格的に「機能/動作検出」へ移行することが求められています。
「機能/動作検出」の考え方
Windows 7の最低バージョンであるIEの8までは、バージョン特化型の時代です。十分な相互運用性を獲得できていないため、複雑な作り込みをしてしまった場合、別のバージョンでは動作しない可能性が高いブラウザです。
IE8までは、サポートされていないブラウザに対して以下のような警告を出すのが、コスト面で最適化されるため、事実上は容認された手段でした。
このシステムは、Internet Explorer 8に対応しています。 システムを利用するには、IE8からアクセスを行う必要があります。
対して、IE9以上は機能/動作検出の時代のブラウザであるため、十分な相互運用性が確保できています。IE9以上で開発し、かつ機能/動作検出で開発すれば、Windows 8以降の最新のレンダリングエンジンしか提供されないIEであっても、理論上動作させることが可能になります。
この世代のWebシステムは、サポートされていないブラウザに対して、以下のような警告が出るのが主流になります。
このブラウザは、システムを動作させるために十分な機能を有していません。 システムを利用するには、ご利用のブラウザのバージョンアップが必要になります。
「機能動作/検出」は、ブラウザのバージョンをチェックするのではなく、機能の有無をチェックしています。バージョンはおろかブラウザの種類が何かまで意識されていません。このため、常に最新のレンダリングエンジンのみが使われることが前提になっています。バージョン依存時代のような、過去のバージョンをあえて選択させるという選択は最初から排除されています。
IEは、Webシステムがこの前提で開発されることを前提として仕様変更を繰り返すことになります。実はIE11の時点で既に、バージョン依存型の開発を行ってしまったWebシステムの運用で問題になるケースが出てきています。
指針に反したWebシステムの末路
★ 1. ユーザエージェント文字列の変更に伴うアクセス不良問題
IEのマルチバージョンを許容する場合、例えばIE6以上をサポート範囲とする場合、提供されるビューは「IE6-7用」「IE8用」「機能/動作検出型用」の3つにしなくてはいけません。IE9以上は機能/動作検出なので、レンダリングエンジンは常に最新のものを利用することを前提とし、ブラウザの種類の特定も行わない作りでないといけません。
IE11は、これを前提とした仕様変更を行いました。ユーザエージェント文字列からIEを特定する情報が失われてしまったのです。このシステムは、IE9以上を対象にしてもなお、従来型の方針を貫いていました。このため、動作対象ブラウザであるIEでさえもシステムが利用できない事象が発生しました。(※具体的な企業名は伏せますが・・・）
★ Windows 8版IE10のサポート期間が3年しかない
Windows 7と同じサポートライフサイクルポリシーが守られるなら、IEの全てのバージョンがOSと同じ期間サポートされるはずです。Windows 8自体のサポートは2023年1月と比較的余裕がありますので、そのシステムは、IE10特化で作りこんでもEOLまでバージョンアップの必要がなく、リスクは低いという判断がされたのでしょう。
ところがIE11がリリースされた際、Windows 8版IE10は、IE11のリリース後24ヶ月しかサポートされないことになりました。IE10からしかアクセスできないように作っていたWebシステムは一瞬にして、残り24ヶ月しか利用できない短命システムに化けました。IE側としては、バージョン9以上であればバージョンの特定はされていないだろうという前提だったのでしょう。
いかにしてこの問題を防ぐか
上記の2つのケースは、IE側が指針に従わないWebシステムを排除するため強引に行った対策です。ちょっとやり過ぎでは、、なんてことも思いますが、バッドプラクティスを生かしているのは我々開発者側なので、大声で文句が言える立場でもないでしょう。
世の中では、Webの作りは汎用的な作りにしろなどと良く言われていますが、それは不正確です。現実的な解としては、「IE8以下はバージョン特化の対策をし、IE9以上/Firefox/Chromeではブラウザレベルで検出しない汎用的な作りにしろ」が正確になるでしょう。つまりこういう状態です。
上記について、大規模開発でもコントロールができるよう、記述方法統一化や可視化の対策方法がありますが、これらはまた別の記事にて紹介します。概要レベルでは、この説明で間違いは無いでしょう。
IE側が想定していない方法で開発を続けた場合、IEは想定済みだけどシステム側は想定していないという、未知の問題にぶつかるリスクが高くなるでしょう。リスク面を考えると、従来の方法に拘るよりも最善の方法と判断できます。
技術を正しく使わなかった場合、リスクが高くなるのはどの分野でも共通しているわけですが・・・。SIは大人の事情も絡むので、技術云々でなく説得に使えるソースが必要になることがあるかと思います。役立ちそうなドキュメントを紹介します。どの程度力になるかはわかりませんが、力になれると幸いです。
★ バージョン依存時代のIEの指針を表すドキュメント
★ 機能/動作検出時代のIEの指針を表すドキュメント
★ IE8のEOL問題
- Microsoftプロダクト一覧、Win8のサポート期間変更 - Microsoft
- 次の移行先IEは、11以上で確定 - ふろしき.js
- IE8向けに開発するWebシステムのEOLは、2020年1月を超えてはいけない
ある程度、事情を証明できる資料はこれぐらいでしょうか。
