ふろしき Blog

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

トップ > IE

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

IE 互換性対策 IE8 SI向け Web

IE8には、IE5の動作を再現させるQuirksモードと、最新のレンダリングエンジンとして動作するStandardモードがあります。HTMLドキュメントの一番上でのDOCTYPE宣言を行うことにより切り替えを行います。

IE8の場合、「X-UA-Compatibe」へ「IE=EmulateIE」というパラメータを与えることにより、過去のIEの動作を再現させることができます。EmulateIEは、5と7の2種類を持っています。5を指定すると常に「Quirksモード」として動作しますが、7の場合、DOCTYPE宣言の内容によって「Quirksモード」か「IE7 Standardモード」のどちらかへ遷移します。

▼ HTMLドキュメント内で宣言する場合

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

▼ HTTP Response Headerで指定する場合

X-UA-Compatible:IE=EmulateIE7

EmulateIEを指定した場合もそうでない場合も、Quirksモードへの判定条件は変化しません。このため、本記事ではEmulateIEを指定している状態で、IE7 Standardモードになる場合も「Standardモード」として扱います。

DOCTYPEスイッチ一覧

Quirksモードを「Q」、Standardモードを「S」と表記します。

HTML1系

Q 無し

HTML2系

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

HTML3系

Q <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 3.0//EN">
Q <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
Q <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">

HTML4系

Q <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
S <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
Q <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN">
S <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd">
S <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
S <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

XHTML1系

S <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
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 <!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
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 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">
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">

HTML5系

S <!DOCTYPE html>


＞＞ Internet Explorerの持つ互換性機能の全て

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

IE IE7 互換性対策 SI向け Web制作者向け テクノロジー

IE7には、IE5の動作を再現させるQuirksモードと、最新のレンダリングエンジンとして動作するStandardモードがあります。HTMLドキュメントの一番上でのDOCTYPE宣言を行うことにより切り替えを行います。

IE7からは、IE6まで問題になっていたXHTML1.0のDOCTYPE宣言の誤認識が解決されました。このため、XHTMLのDOCTYPE宣言を行っていたIE6のドキュメントは、IE7への以降時に動作に異常が生じることがあります。注意して下さい。

DOCTYPEスイッチ動作一覧表

Quirksモードを「Q」、Standardモードを「S」と表記します。

HTML1系

Q 無し

HTML2系

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

HTML3系

Q <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 3.0//EN">
Q <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
Q <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">

HTML4系

Q <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
S <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
Q <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN">
S <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd">
S <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
S <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

XHTML1系

S <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
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 <!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
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 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">
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">

HTML5系

S <!DOCTYPE html>


＞＞ Internet Explorerの持つ互換性機能の全て

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

IE IE6 互換性対策 SI向け Web制作者 テクノロジー

IE6には、IE5の動作を再現させるQuirksモードと、最新のレンダリングエンジンとして動作するStandardモードがあります。HTMLドキュメントの一番上でのDOCTYPE宣言を行うことにより切り替えを行います。

IE6の時代、XHTML1.0は存在はしたものの、DOCTYPEの判定アルゴリズムに不足があるという問題を抱えています。宣言の方法次第では、IE7以降とは異なる動作をするため注意が必要です。（※XML宣言で誤動作を起こす。）

DOCTYPEスイッチ動作一覧表

Quirksモードを「Q」、Standardモードを「S」と表記します。

HTML1系

Q 無し

HTML2系

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

HTML3系

Q <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 3.0//EN">
Q <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
Q <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">

HTML4系

Q <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
S <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
Q <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN">
S <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd">
S <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
S <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

XHTML1系

S <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
Q <?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 <!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
Q <?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 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">
Q <?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">

HTML5系

S <!DOCTYPE html>


＞＞ Internet Explorerの持つ互換性機能の全て

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

IE IE11 IE10 SI向け

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

IE10ではこの問題に対応するため、無印の「Quirksモード」と「IE5 Quirksモード」と２種類の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」の動作を再現させます。


＞＞ IE11に関する情報を探す
＞＞ (関連記事)Internet Explorer 11のユーザエージェント問題 - 対策方法の全て

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

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

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

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


＞＞ Internet Explorerの持つ互換性機能の全て
IE11を裏ワザ的なやり方でDOCTYPEスイッチを有効化する方法

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

IE IE11 SI向け ユーザ向け テクノロジー

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」の動作を再現させます。

★問題は解決されましたか？他にはこんな改善方法もあります
＞＞ IE11のユーザエージェント問題対策方法
＞＞ WebコンテンツからIE独自機能を削除する方法
＞＞ マイクロソフトが公開している無償のテストスイーツ
＞＞ IEの持つ互換性機能の全て
＞＞IEのバージョンごとの違い

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

IE IE11 ガイドライン SI向け テクノロジー

近年、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開発のガイドライン・ツール集

IE 用語・TIPS ガイドライン SI向け テクノロジー

★ Windows 7のWebシステム開発は、IEの方針転換により変化が求められる

f:id:furoshiki0223:20131211172718p:plain

Windows XP時代に主流であった「バージョン依存型」は、非推奨となりました。IEはかつて、様々なバージョン特化の作り込みを支援する機能を提供してきましたが、バージョンアップを繰り返す都度、非推奨化と削除を繰り返し、現在の最新のIEでは殆どが動作しなくなりました。

現在は「機能/動作検出型」で開発を行わないと、Webシステムは想定外のリスクに晒されることになります。場合によっては、システムのライフサイクルに致命的な問題を作りこむことになります。

★ Win7のIEの移行対応は、Win9x/WinXPの時ほど簡単にはいかなくなった

f:id:furoshiki0223:20131211172853p:plain

古いシステム、具体的にはIE8以下を対象に開発されたWebシステムを、上位のバージョンのIEでも維持させるには、IEの過去のバージョンの動作を再現させる機能「ドキュメントモード」を利用するのが一般的でした。しかし、Win8以上のOSでサポートされるIEから、ドキュメントモードは非推奨になりました。従来のIE6特化・IE8特化型のようなWebシステムは、Win9x→WinXP→Win7とOSのアップデートを繰り返す中で、ドキュメントモードの活用によりスムーズに移行が行えました。しかし、Win7→Win8以上の移行では、これが行えなくなります。

既存資産の移行方法についても、IEの「変化」へ対応していかなくてはいけません。常に最新のレンダリングエンジンを利用してWebシステムが動くよう、開発方法、テストに工夫が必要となります。

★ 上手く変化に対応しないと、サポートされないWin7端末が大量に溢れる

WinXPは12年という、比較的長い期間利用できたクライアントOSでした。Windows Vistaのリリースが遅かったため、WinXPはN+1サポートの恩恵を受け、2年強ほど長く利用することができました。現在、業務系でも多く利用されているWin7は、WinXPからなかなか移行できなかったユーザが移行先OSとして選択したようです。このようなケースでは、発売後に時間をあけてから移行を始めたため、EOLは2020年1月までと、WinXPと比較すると約半分程度のサポート期間しか持てなくなってしまいました。

この短い期間の間に、既存資産も新規の資産も、IEの変更された方針に適応しなければいけません。IE8特化システムやドキュメントモード依存システムを残すと、Win8以上のOSへの移行はほぼ確実に失敗し、結果としてサポートされていないWin7を継続して運用し続けなくてはいけない状況に陥ります。これはユーザ企業にとっても、開発ベンダ側にとっても、最悪の状況です。

本ガイドラインは、この最悪を防ぐために必要な、移行の手法、開発の手法、テストの手法について、MicrosoftやGoogleのドキュメントを元に、国内のSIに特化し汎用的な形でまとめてみました。

2013年は、Windows XP専用端末/Windows XP VMなどを何千台と購入し、コスト・セキュリティの双方で最悪な手段を選択しざる得ないこともあったようです。現場によって、やり方や文化はそれぞれ異なるでしょう。本ガイドラインは、次回やって来る2020年のWindows 7のEOLを無事乗り切り、「正しい方法」でWebシステムが維持されること目指すために、今何をすれば良いのか、ヒントを見つけるきっかけを与えることができればと考えています。

a. 開発のガイドライン・ツール

  1. Windows 7世代からWebシステム開発指針を変えなくてはいけない理由
  2. Compat Inspector - ソースコードからIE独自機能を機械的に検出しWeb標準へ置き換えさせる方法
  3. (近日公開)

b. 各ブラウザの技術的特徴・法人向けサービス

  1. Internet Explorerのバージョンごとの機能の違い、選定の目安
  2. Firefox向けWebシステム開発でできること・できないこと
  3. (近日公開)

c. 試験のガイドライン

  1. IEのマルチバージョンテスト「Modern.IE」開発での利用時の注意点
  2. (近日公開)

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

IE IE11 Mobile Web標準 ガイドライン SI向け Web制作者向け テクノロジー

これまで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デザインのようなマルチデバイス対策は進めていく必要があります。


＜＜ トップへ戻る(業務システム向けWeb開発ガイドライン)

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

IE IE11 互換性対策 SI向け テクノロジー

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

注意：EmulateIE10のDOCTYPEスイッチの不具合

＞＞ (こちらを参照)IE11のEmulateIE10でDOCTYPEスイッチに不具合がある


＞＞ IE11に関する情報を探す
＞＞ (関連記事)Internet Explorer 11のユーザエージェント問題 - 対策方法の全て

IE11のユーザエージェント問題 - IT管理者側でできる対策(IEAK/Active Directory/modern.IEの活用)

IE IE11 SI向け テクノロジー

古いWebシステムはIEに依存した処理を多く含む傾向にあり、企業内の標準ブラウザをアップデートする際に、IE11から変更されたユーザエージェントの書式仕様が問題となり正常に動作できない場合があります。

しかし、これを理由にしてアップデートを先延ばしにすると、古いIEに特化した業務システムを作り続けることになります。IEのアップデートが必要になった際には、大量の業務システムで「改修」の必要が生じ、コスト効果としては最悪の状態に陥ることになります。

新しいIEは、Web標準への準拠が高く、その上で動作するWebシステムも必然的に汎用的な作りとなるため、その後のIEアップデートで生じるコストも最小化させることができます。特にIE11は、Web標準への準拠が非常に高くユーザビリティ改善のための多くの手段(HTML5の利用)が提供できるため、Webシステムの健全化/高度化へ貢献してくれるでしょう。

本記事では、「IE11のユーザエージェント問題」に対して、Webシステムを扱うIT管理者の視点で、Windowsの持つ機能を駆使して、社内のIEに対して講じることができる対策とアイデアについてご紹介します。

IE11のユーザエージェント仕様の変更は、IEの特定のバージョンへの依存を減らすことを目的としたポジティブな改善です。既存のWebシステムについては本記事の対策により最小のコストで維持し、これから更改されるWebシステムについては、新しいIEの設計指針に従い、IEへの依存性を最小化したデザインを目指して下さい。

★ 対策内容一覧

  1. IEAK11を利用した対策
  2. ActiveDirectoryを利用した対策
  3. ローカル・イントラネット・ゾーンへの移行
  4. 動作のテスト手段

Microsoftは、Internet Explorerをエンタープライズ用途の製品の一つとして位置づけています。このため、Windows系OSやMicrosoftの提供する社内統制向け製品との親和性が高く、様々なIEの改善機能を提供しています。

1. IEAK11を利用した対策

IEAK(Internet Explorer Administration Kit)は、社内のIEの設定を統一化を行うためのMicrosoft公式ツールです。Internet Explorer Administration Kit (IEAK) Information and Downloadsにて、ダウンロードが行えます。

IEAK11は、IE11に特化した設定統一化ツールです。IEAK11を使えば、企業の保有するWebシステム向けにカスタマイズしたIE11インストールパッケージを作成したり、インストール済みのIE11に対して後から統一すべき設定情報を組み込むことができます。

f:id:furoshiki0223:20131113191849p:plain

作業の流れは、以下の通りです。

f:id:furoshiki0223:20131113033150p:plain

IEAK11は、互換表示に関する設定情報も含んでいます。互換性の設定情報を含んだ状態で、インストールパッケージの配布を行えば、既存の業務システムは互換モードの状態で表示させることができます。

IEAK11の互換表示として設定される情報は、IE11に含まれる「互換表示設定」画面上で設定された項目の全てです。互換表示対象として指定されたWebシステムは、IE7の動作をエミュレートして実行します。

マスターとなる環境のIE11にて、[設定ボタン]→[互換表示設定(B)]の順にクリックし、[互換表示設定]より変更が行えます。

f:id:furoshiki0223:20131113033836p:plain

  • ①. 互換性表示リスト : 指定されたドメイン名に属するWebシステムは、互換表示されます。ここに予め互換表示を必要とするWebシステムのドメイン名を登録することで、既存資産の変更リスクを低減させることができます。
  • ②. イントラネット互換モード : ローカル イントラネット ゾーンと判断できるドメイン名に属するWebシステムは、互換表示されます。本機能はデフォルトでONになっているため、これを利用した対策も行えます。詳細は、次章にて紹介します。
  • ③. Microsoft互換性表示リスト : Microsoftから配布されたリストに含まれるドメイン名のWebサイトは、互換性制御の影響下に置かれます。イントラネット内のWebシステムは通常登録することが無いため、業務システムの場合、B2Cでない限り出番は無いでしょう。

IE11には、バージョン5から10までの動作をエミュレートするレンダリングエンジンが含まれています。これらのレンダリングエンジンを細かく制御して利用するには、Webシステムを動作させているサーバのミドルウェア製品の設定値を変更するか、Webシステムのプログラムに手を加える必要があります。このため、IT管理者向けツールからのコントロールでは実質的にIE7しか互換表示に利用できません。

IE6世代のWebシステムは、IEのアップデートの際にIE7互換モードへ移行しているケースが多いようです。このため、OSに強く依存した機能(WindowsAPIに強く依存した動作)を利用していない前提下では、問題は小さいものと考えられます。

2. ローカルイントラネットゾーンへの移行

2.1. ローカルイントラネットゾーンへの移動

(※この箇所は執筆中です)

2.2. 強引な手段

IEAKは、全てのIEのバージョンを11で統一する場合に有効な手段です。ただし、この方法では配布に手間が生じるため、規模の大きい企業では、IEAKで追加パッケージを配布するなどのメンテナンスのコストが大きい場合もあります。組織が巨大だと、IE11へのアップデートを促しても一斉に移行できないケースもあります。

状況によっては、IEの持つデフォルトの設定を利用して、互換表示切り替え方法を行う手段も視野に入れるべきでしょう。

IEはかつてより、ローカルイントラネットゾーン上のWebシステムについては、デフォルトで互換表示設定で動作する仕様です。つまり、互換表示が求められるWebシステムへ、IEがローカルイントラネットゾーンと認識できるようなドメイン名を与えれば、IEはWebシステムを互換表示で実行します。

IEがWebシステムをローカルイントラネットゾーン上に配置されていると判断する条件は、ドメイン名に「.(ドット)」が含まれていない場合です。「http://example.com/test.html」はexampleとcomの間に「.(ドット)」がありますが、「http://system01/test.html」は「.(ドット)」が含まれないため、ローカルイントラネットゾーン扱いとなります。

f:id:furoshiki0223:20131113191112p:plain

社内システムの利用で専用のDNSサーバを社内で保有している場合、DNSサーバの設定を変更することにより実現できます。WINSの場合は、制約が加わる可能性があります。少々強引な技なので、あまり推奨されるものではないでしょう。

3. Active Directoryを利用した対策

Active Directoryの影響下にあるクライアント端末では、グループポリシー管理によりWebシステムへ互換表示を強制させることができます。運用中のInternet Explorerに対する対応策としては、最も堅実な手段でしょう。

http://www.danielclasson.com/guide-how-to-force-specific-sites-to-always-run-in-compatibility-view-using-group-policy/

http://www.atmarkit.co.jp/ait/articles/0905/27/news118_3.html

4. 動作のテスト手段

Microsoftでは、エンタープライズで利用されているIEのアップデートを促すため、Webシステムの互換性をテストするためのツールを揃えたサイト「modern.IE」を運営しています。このサイトでは、様々なバージョンのIEとOSの組み合わせをVMとして無償提供しており、動作のテストを行うことができます。

f:id:furoshiki0223:20131113194820p:plain

IE11については、2013年11月現在、Windows7版とWindows8.1版の2つを提供しています。

f:id:furoshiki0223:20131113195156p:plain

Webブラウザの動作は実装OSによっても変化するため、本サービスを利用して、できる限り本番環境に近い組み合わせでテストすると良いでしょう。

＜＜ 目次へ戻る(IE11のユーザエージェント問題)

IE11のユーザエージェント問題 - 運用者側でできる対策(Apache HTTP Server/IISの設定変更)

IE IE11 SI向け テクノロジー

運用しているWebサイト/システムがIE11からのアクセスへ対応できない場合、運用者側としてはHTTPヘッダを利用した対策を行うことができます。

対策可能な範囲としては、以下2つが挙げられます。

  1. アクセス元のWebブラウザの互換性モードを制御する
  2. アプリケーションへ透過的にIEであることを認識させる

前者はWebブラウザ上で動作が正常に行われなかった場合、後者はサーバ上のアプリケーションの動作が正常に行われなかった場合の対策です。どちらもミドルウェア製品のパラメータ設定の変更のみで対処が可能です。

当然ですが、これらの対処にはサーバの停止が必要になります。また、他の設定との競合などの問題により、動作が確実に保証されるものではないため、事前の動作検証が必要です。

1. アクセス元のWebブラウザの互換モードを制御する

サーバからIEの互換モードを制御して、IE10以下のWebブラウザの動作を再現させることができます。新規開発/制作では良い方法とは言えませんが、既存のWebサイト/システムを最小の変更のみで維持するには有効な手段です。

対策は、HTTPレスポンスヘッダへIEの互換モードを制御する、「X-UA-Compatible」というプロパティを追加することによって実現できます。どのWebサーバの製品を使うかによって、その制御方法は様々です。

ここでは、「Linuxベース(Apache HTTP Server)「と「Microsoftベース(IIS)」の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=10
</IfModule>

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

Apacheの場合は、「mod_rewrite」を用いたURLによる振り分けを行っているケースが多いでしょう。この場合、以下のルール変更のみで対応可能です。

# ✕ 従来の振り分け判定記述
RewriteCond %{HTTP_USER_AGENT} MSIE
# ◯ IE11対策された判定記述
RewriteCond %{HTTP_USER_AGENT} Trident

★ 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=10」
f:id:furoshiki0223:20131124004901p:plain

2. アプリケーションへIEであることを認識させる

ユーザエージェントが従来の方式でIEの判定が行えなくなった場合、サーバ上のプログラムが動作不良を起こしてしまうケースもあるでしょう。この場合、ユーザエージェントがサーバ上のプログラムへ渡される前に、従来の方式によって判定できるように偽装を行うことで対処できます。

Linux/Apacheの場合

Apache HTTP Serverには「mod_setenvif」と呼ばれるモジュールがあります。

元は第一次ブラウザ戦争時代に、NetScape用に作られたWebサイトをIEから入れないようにするために作られたものでしたが、今回はその逆で、Firefox(旧NetScape)のふりをしたIEを受け入れるために利用できます。時代の流れとは、恐ろしいものです。

http://httpd.apache.org/docs/2.2/mod/mod_setenvif.html

(※ 本記事は現在「執筆中」のステータスです。)

IE11のユーザエージェント問題 - 対策方法の全て

＜＜ 目次へ戻る(IE11のユーザエージェント問題)

Internet Explorer 11のユーザエージェント問題 - 対策方法の全て

IE IE11 SI向け Web制作者向け テクノロジー

f:id:furoshiki0223:20131113210652p:plain

Internet Explorer11へアップデートされてから1ヶ月。多くのWebアプリが動作不良を起こし、混乱が生じているようです。

IEは11から、「User Agent スニッフィング」と呼ばれる手段で、Webブラウザに依存した作り込みが行われることを防ぐため大胆な仕様変更を行いました。これまでWebブラウザ/バージョンの特定の手段として広く利用されていたユーザエージェント文字列から、重要な項目が削除されたのです。

ネット上では断片的な情報が散らばっているようですが、不十分な対策も多く見受けられます。そこで今回、対策の方法について体系的かつ網羅的に理解できるよう、4つの観点から整理してみました。

本稿が、読者の方が運用しているシステムへ万全の対策を行えることを、そして開発者がWebの正しい指針に従い開発を進める助けになれば幸いです。

対策一覧

  1. ユーザ側でできる解決策(互換表示機能の利用)
  2. 運用者側でできる対策(Apache HTTP Server/IISの設定変更)
  3. IT管理者側でできる対策(IEAK/Active Directory/modern.IEの活用)
  4. 開発者側でできる対策(判定方法の変更/互換性モードの利用)

IE11の設計指針「User Agent スニッフィング」の防止とは？

今回のIEの仕様変更は、少々強引とはいえ、Web技術にポジティブなインパクトを与えるきっかけになるでしょう。

IEは近年のWeb開発のお作法である「機能の有無によるクロスブラウザ型のWeb開発」という思想を広めるため、現在悪とされている「ユーザエージェント特定によるマルチブラウザ型のWeb開発」、つまりWebブラウザごとに個別の作りこみを行いにくい仕様へ徐々に移行を進めてきました。バージョンを上げるごとにユーザエージェントに含まれる.NETフレームワークのバージョンなどIE固有の情報を減らし続け、そしてバージョン10からは「条件付きコメント」の廃止という思い切った仕様変更を行っています。

サーバ側でIE/バージョンの特定を行うための実用的な情報は廃止しなかったため、サーバ側のミドルウェアへのインパクトはほぼ皆無でした。IEそのものがWeb標準への準拠が高くなったため、十分なマルチブラウザ対策が行われているサービスであれば、クライアント側でも問題は小さかったようです。

しかし今回、11へのアップデートでは、サーバ・クライアントの双方でWebブラウザの種類を判別するためにもっとも広く利用されている、ユーザエージェントの内容を大きく変更しました。この変更は、Webブラウザでの動作切り替えを行わないと現実的な開発が行えなかった3-5年以上前の古いWebアプリ・サイトで、動作不良を起こす原因となっています。また、JavaScriptのAPI経由でユーザエージェント情報を収集し動作を切り替えていたサービスでも、同様に問題となっているようです。

理想を言えば、このタイミングでIEに依存しない作り込みをサーバ側でも行うべきです。しかし実態としては、既存資産の維持へは最小のコストで対策し、次の更改まで維持し続けることが現場として求められることでしょう。本稿で紹介した4つの対策は、あくまで既存資産を延命させるための対策であるものと考えて下さい。新規開発であれば、これからご紹介する「クロスブラウザ対策」を参考に開発することが推奨されます。

正しい解決、クロスブラウザ対策

現在Webでは、Webブラウザの持つ機能の有無に応じて動作を変えるという手法が推奨されています。Microsoftが公開しているドキュメントからも、その思想が読み取れるはずです。

▼ 機能検出と動作検出の使用
http://msdn.microsoft.com/ja-jp/library/ie/ff986088(v=vs.85).aspx

MicrosoftのドキュメントではjQuery.supportを推奨していますが、より高度な機能を有したModernizrも有用です。その利用方法と思想については、本ブログでも記事としてまとめています。

▼ クロスブラウザ対応を助けるJSライブラリ"Modernizr"
http://furoshiki.hatenadiary.jp/entry/2013/06/29/220621

最後に、Microsoftが公開しているIE11の互換性/変更点に関するドキュメントを紹介します。

▼ ブラウザーの機能と互換性の変更点
http://msdn.microsoft.com/ja-jp/library/ie/dn467848(v=vs.85).aspx

IE11のユーザエクスペリエンスの改善の多くは、マルチデバイス時代への対応を意識したものが多いようです。今後のIEのアップデートでも、この傾向はより強くなるものと予想されます。

JSライブラリを利用した開発は高いユーザエクスペリエンスと相互運用性を確保できますが、デスクトップUIへ特化しているケースも多いように思えます。IEのバージョンだけでなくマルチデバイスへの対応もトータルに考えて、Web標準技術の利用ついて、考える必要があるでしょう。

IE11のユーザエージェント問題 - 開発者側でできる対策 (判定方法の変更/互換性モードの利用)

IE IE11 SI向け Web制作者向け テクノロジー

既存のWebサイト・システムがIE11で動作しない場合、ユーザエージェントの観点では以下の何れかで対策が可能です。

  1. navigator.userAgent文字列からの判定
  2. HTMLドキュメント内から、互換性モードの操作

上記の対策はどちらも、"課題"があります。

近年のWeb開発/制作の指針は、ユーザエージェントによる動作の切り替えではなく、Webブラウザの持つ機能による切り分けが推奨されています。あくまでここに書かれている対策は、既存資産を最小のコストで動作可能にするためのものです。

新規の開発/制作では、この記事を参考に対策して下さい。

1. navigator.userAgent文字列からの判定

IE11のユーザエージェントを、JavaScriptの「navigator.userAgent」から取得した場合、HTTPリクエストヘッダから取得するよりも多くの情報が得られます。しかし判定で利用する情報は、HTTPリクエストヘッダの時と変わりません。

▼IE10

Mozilla/5.0 (Compatible; MSIE 10.0; Windows NT 6.1; Trident/6.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C)

▼IE11

Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; NP06; rv:11.0) like Gecko

IE10まではMSIEの文字列とその直後の数字で、Webブラウザ・バージョンの判定ができていました。多くのサービスが、判定にはこの文字列を利用しているはずです。しかし、IE11からは「MSIE」の文字列が無くなり、バージョンを表す数字も削除されてしまいました。

ただし、Tridentというブラウザエンジンを判断する情報は残されています。また、新しく「rv:11.0」というバージョンを表す別の情報が追加されています。

注意が必要なのは、IE10までの「MSIE 10.0」の「10.0」の箇所は、互換性モードを利用した際にどのモードかに応じて変化しました。例えば、IE7互換モードであれば、「MSIE 7.0」といった具合にです。

しかし、IE11から追加された「rv:11.0」という情報は、互換モード動作時も同じ「rv:11.0」のままです。IE11をIE10の互換モードで動かしても「rev:11.0」という文字列は変わりません。

つまりIE11では、使っているレンダリングエンジン(Trident)であることの判定、どのバージョンのIEを使っているかという情報までは確認できても、互換性モードが有効な時にどのバージョンの状態で動作しているかまでは確認できません。

これらを踏まえたIEの判定、バージョンの判定は以下の通りです。

// IEであるか否かの判定
var isIE = false; // IEか否か
var version = null; // IEのバージョン
var ua = navigator.userAgent;
if( ua.match(/MSIE/) || ua.match(/Trident/) ) {
    isIE = true;
    version = ua.match(/(MSIE\s|rv:)([\d\.]+)/)[2];
}

上記のスクリプトを、Webブラウザの設定やHTTP Responseヘッダ、ActiveDirectoryなど他の設定手段を無視して確実に動作させるには、HTMLドキュメント内で以下の設定が必要です。

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

そもそもですが、本仕様はIE12まで継続されるかも不明です。Microsoftがこの手の実装を排除する指針である以上、ユーザエージェント周りにどのような変更が行われても不思議ではありません。

なお、上記と類似した実装をjQueryでも提供されています。状況によっては、利用してみるのも手でしょう。

▼plugin for the dependency problem
http://plugins.jquery.com/depend/1.1.5/

HTMLドキュメント内から、互換性モードの操作

IEがユーザエージェント文字列に「MSIE」を含んでいた時代の動作をエミュレートさせるよう、互換性モードを変更する制御情報を与えるという手段です。IEが最新でない状態で動作するためあまり良い方法ではありませんが、既存資産を維持する目的であればわりと一般的です。

以下の文字列を、HTMLドキュメントのhead要素内のできる限り序盤に配置することで実現できます。

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

このmeta要素は、IEがバージョン10以上の場合に、IE10のレンダリングエンジンで動作するように指示するものです。IE10時代はユーザエージェントに「MSIE」の文字列が含まれていたため、これに依存したJavaScriptコードは正常に動作できるようになります。

HTMLドキュメント内でも、Webブラウザの制御を行うもの、例えば上記以外にも＜meta charset="utf-8" /＞のようなタイプのものは、head要素の序盤に配置しないと有効になりません。今回紹介したUA-Compatibleも、割りと敏感な部類に入りますので配置場所には注意して下さい。

たまに新しく開発する業務システムでも、非常に古い互換性モード(Quirksモード)で動作させるような対処をしているという話を聞きます。しかしそれは、良くない対処方法です。今のところMicrosoftはIE5時代からの動作がエミュレートできるような機能を提供し続けていますが、今後それが維持されることまでを保証していません。そもそもですが、新規で開発するものをわざわざ下位互換のために提供した機能で動作させる事自体、ナンセンスであることは言うまでもないでしょう。

新規では最低でも、開発対象バージョンをUA-Compatibleの下限にする程度の対処に抑えましょう。使うこと自体は全く間違いではないのですが、使い所を間違いやすい危険な機能です。入門レベルのプログラマが、ネット上のブログからコピペしてしまうなんていう地雷を含む恐ろしい機能です。ご注意下さい。

＜＜ 目次へ戻る(IE11のユーザエージェント問題)

IE11のユーザエージェント問題 - ユーザ側でできる解決策 (互換表示機能の利用)

IE IE11 SI向け Web制作者向け テクノロジー

IE11でのみWebサイト・システムへアクセスできない場合、以下の問題が考えられます。

  1. サーバ側でIE11からのアクセスを拒否している。
  2. IE11のレンダリングエンジンに問題があり利用できない。

以下の対策で、改善される可能性があります。

1. サーバ側でIE11からのアクセスを拒否している場合

この問題は、IE11のHTTPリクエストヘッダに含まれるユーザエージェント情報を元に、出力するHTMLドキュメントを変えているケースに生じます。IE11のユーザエージェントから、MSIEの文字列が削除されたため、サーバがWebブラウザの特定を行えず予期せぬ動作を起こしている状態です。

サーバ側で拒否されているかを確認するには、IE11に付属している「F12開発者ツール」の利用が有益です。対象のWebサイト・システムへアクセスしている状態で、F12を押下して下さい。

Webブラウザの下方に、F12開発者ツールの画面が表示されます。
f:id:furoshiki0223:20131111185123p:plain

↓
ツールの左下「の逆三角のボタン」を何度かクリックして下さい。
f:id:furoshiki0223:20131111185948p:plain
↓
一番下に見つかる「デスクトップPC風アイコン」をクリックして下さい。
f:id:furoshiki0223:20131111190048p:plain
↓
「ユーザーエージェント文字列」という項目を、「Internet Explorer10」に変更して下さい。
f:id:furoshiki0223:20131111190445p:plain
↓
f:id:furoshiki0223:20131111190209p:plain

この対策で表示されることが確認できた場合、原因はサーバ側の問題にあることが確定されます。不便ですが、アクセスする都度、本手順を行わなくてはいけません。Webサイト・システム管理者の改善を待たなくてはいけないでしょう。

ただし、次章の手順を実行すると状況が改善される可能性があります。

2. IE11のレンダリングエンジンに問題があり利用できない場合

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

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

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

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

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

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

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

社内システム用途のWebアプリケーションでは、古いものはIE6用として開発されたものが多いという状況でしょう。IE8以上への移行では大抵の場合、IE5〜6の動作を再現させる「Quirksモード」でなく、「IE7互換モード」で動かすのが定番となっているようです。

IEの「Quirksモード」はバージョン10以降、IE5～6の世代には付随していない最新のWeb標準の機能が追加されています。したがって、IE6のかなりコアな機能を利用したWebサイトは、正しく動作しない可能性があります。

比較的機能の近い「IE7互換モード」を利用するのは現実的な手段であり、IE11のこの動作は理に適っていると言えるでしょう。


★考えられる要因
IE11ではDOCTYPE宣言がチェックされない ＞＞
IE6〜9とIE10/11とでQuirksモードの動作が違う ＞＞

パッチによる改善

IEはセキュリティパッチを定期的にリリースし、不具合については基本的にそのままにしておくことで、安定したプラットフォーム提供を実現しています。

しかしIE11はリリース直後に信頼性に関わる問題が発覚し、急遽パッチが配布されることになりました。これを適用することで、かなり改善されたという声も聞きます。特に、Windows8.1を利用している方は、IEの最新化を行わないと最高のパフォーマンスは発揮できないものと考えてください。

▼Download Center(パッチの配布先)
http://www.microsoft.com/ja-jp/download/default.aspx

新しいIEは、ActiveXのようなIE独自のテクノロジーが減ったため、アップデートで動作不良を起こすリスクも減っています。企業をターゲットとしたゼロデイ攻撃は今もなお増えていますので、安全な運用を行うため、IEのバージョン最新化も計画的に進めていくよう心がけて下さい。

＜＜ 目次へ戻る(IE11のユーザエージェント問題)

1300の優良サイトが選んだ「フルスクリーンバックグラウンドイメージ(Full Screen Background Image)」対策ライブラリ集

1300サイト調査 ライブラリ 用語・TIPS IE Web制作者向け テクノロジー

1300の優良サイトを調査してみたシリーズ、第10回は「フルスクリーンバックグラウンドイメージ(Full Screen Background Image)」です。

背景にフルスクリーンの状態で画像を表示させるには、独特なノウハウを必要とします。この対策への呼び名は日本にはまだ輸入されていませんが、海外だと「Full Screen Background Image」と呼ばれています。

CSS2のみでも対策は可能です。以下が、その記述方法です。

▼ CSS

html, body {
  height: 100%;
  width: 100%;
  padding: 0;
  margin: 0;
}
#full-screen-background-image {
  z-index: -999;
  min-height: 100%;
  min-width: 1024px;
  width: 100%;
  height: auto;
  position: fixed;
  top: 0;
  left: 0;
}
#wrapper {
  position: relative;
  width: 800px;
  min-height: 400px;
  margin: 100px auto;
  color: #333;
}

▼ HTML

<body>
  <img alt="full screen background image" src="/background.jpg" id="full-screen-background-image" /> 
  <div id="wrapper">
    <p>Content goes here...</p>
  </div>
</body>

ただし、ライブラリを使えばノウハウが無くても対策が可能です。ふろしき.jsの調査では、1300中18サイト(1.38%)にてライブラリによる対策が確認されました。

jQuery MaxImage (12件 - 0.92%)

f:id:furoshiki0223:20131023000012p:plain
背景画像をフルスクリーン化させるだけでなく、スライダーとしても機能します。

jQuery Backstretch (6件 - 0.46%)

f:id:furoshiki0223:20131023000157p:plain
背景画像をフルスクリーン化させます。

最後に

ノウハウが多いとはいえ、やろうと思えばやれてしまう気軽さが悩みどころですね。JSライブラリは、なんだかんだ言っても、ロード時間を遅らせますからね。

<< 目次へ戻る(1300の優良サイトが選んだWeb制作のベストプラクティス)

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

川田 寛

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

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

お問い合わせフォーム
© Hiroshi Kawada, Bootstrap Inc.