これまで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レイヤーに依存することになります。
レンダリングエンジンのソースコードの大半は、どのような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ブラウザの持つ思想の違いが読み取れるでしょう。
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に依存した業務システムでは、問題になることがあります。
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システム/サイトに多いのが、ピクセル単位での動作に依存したデザインです。以前よく見た事例としては、ポップアップウィンドウの幅とテキストの横幅が揃うことを前提としたレイアウトが問題になるケースです。
このシステムが開発されたのは単一ブラウザが当たり前な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)
かつてIEには、CSS上でJavaScriptを動作させることができる、CSS Expresionsというアンチパターンがありました。古いコンテンツの多くは、この機能に依存していました。Webブラウザが新しいWeb標準に追いつけていない場合にも、CSS側で不足した機能を埋めることができたからです。CSS ExpressionsはIE8で既に、サポートが削除されています。
(※参考 : CSS Expressions のサポート終了について - Microsoft)
互換表示機能を使えば、IE8〜10のWebブラウザでもCSS Expressionsを利用することができます。古いコンテンツがネックになって、IEのバージョンアップができなくなるという問題を回避するために行われた対処です。既存資産の維持という目的であれば、互換表示機能は価値の高い機能でしょう。
しかし、2章の内容を読んだ人であれば、この動作には限界があるということがわかるはずです。「互換表示」が機能するのは、あくまでレンダリングエンジンの層に限定されるのです。OSをエミュレートするための機能を、Webブラウザは持ってはいません。
★ 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)
デバイスも、キーボードをつなげればデスクトップ型になり、外せばスマートデバイス型へ変化するというコンピュータを広げようとしています。このようなデバイスが広がれば、必然としてサーバサイドでデバイスの種類を区別するようなWebコンテンツのデザインは歓迎されないでしょう。
(※参考 : Surface 2 - Microsoft )
近年「レスポンシブWebデザイン」という手法が広がっていますが、Microsoftもこれを推進しており、必要なOSSのJSライブラリを一式、Microsoft側でサポートしています。Webサイト/システムは、サーバ側でデバイスに応じて返すビューを変えるのでなく、クライアント側でマルチデバイスに対応したビューを用意する必要があります。
(※参考 : オープンソースのJavaScriptライブラリでベンダサポートを受ける方法 - ふろしき.js)
レスポンシブWebデザイン導入のメリットが見いだせない制作/開発者の方もいるようですが、デバイスがデスクトップとスマートデバイスの違いが無くなろうとしている今の状況を鑑みれば、導入は必然なものとして考えることができるでしょう。エンタープライズ系の場合、企業にタブレットの導入が広がっているのであれば、レスポンシブWebデザインのようなマルチデバイス対策は進めていく必要があります。
