[論文] Web標準と慣習の競合

   このエントリをはてなブックマークに登録    2006/11/6

「The Web designer's dilemma: When standards and practice diverge, Aaron Weiss, Web design '06: balancing standards and practice ,Pages: 18 - 25, March 2006, ACM Press」 という論文を読みました。 面白かったので要約してみました。 以下の文は論文に書いてある事の要約です。 私の誤訳や誤解があるかもしれないので、詳細は論文を読んでください。



ブラウザ戦争

1991年にTim Berners-LeeがWebサーバとブラウザを配布し始めたときには、理論と実装は整合性を保っていました。 しかし、他の人たちが独自のブラウザを作り始めて、それぞれ独自の拡張を加え始めました。 Webデザイナーは、Netscapeの<BLINK>タグのような独自拡張を使うようになりました。 そのため、Web標準と実際に使われているものは急速に乖離しはじめました。 この乖離は現在も続いています。

ブラウザがW3Cで定義されているHTML 4.01、XHTML 1.0、CSS 1/2に完全準拠していて、ブラウザの違いによる差が無ければWebデザイナのジレンマは発生しませんが、残念ながら今はそうなっていません。 90年代のブラウザ戦争では、マイクロソフトとネットスケープが戦いを繰り広げました。 その戦いの一環として独自機能追加合戦が繰り広げられました。

結局Microsoftが戦いに勝利し、Netscapeの市場シェアは0パーセント近くまで下落しました。 その結果、WebデザイナはInternet Explorerを前提にWebサイト製作を行う事を余儀なくされました。 これは、IEコンパチなWebサイトを製作することであり、W3Cに準拠することではありませんでした。 W3Cで定義されているいくつかの機能はIEで正常に動作しませんでした。

世の中のブラウザがIEだけである限り、このジレンマは単なるアカデミックな問題であると言い切れました。 IEは未だにブラウザ市場を独占していますが、その占有率は2005年末には85%まで落ちました。 現在の競合相手であるFirefoxはW3C準拠をうたっています。 マイクロソフトはInternet Explorerを更新する努力をほとんどしませんでした。 その不満をFirefoxが吸収する形になりました。 一部の人は、Firefoxはノルウェー産ブラウザであるOperaに大きく影響されていると言っています。 Operaは最も長い間標準準拠をうたっていたブラウザです。

リキッドデザイン

どのように情報を受け取るかはユーザが決定すべきで、コンテンツプロバイダが決定すべきではない、というのがWeb design創世記時の美学の一つでした。 画面に表示されるコンテンツのコントロールを誰がするか、ユーザかもしくはデザイナか、という綱引きの根本は画面の幅をどのように決定するかに代表されます。

例えば、ブラウザ内に表示される画面のサイズはどのようになるべきでしょうか? ユーザ決定派は例えば、ブラウザ画面の90%などという相対的な指定方法を推薦しています。 この方式は「Liquid design」と呼ばれています。

一方、デザイン派は例えば750ピクセルなど絶対的な指定方法を推薦しています。 これは「Fixed design」と呼ばれています。

Webが出現した初期の頃は、fixed designは紙媒体の悪習として技術者に嫌われていました。 しかし、出版系のバックグラウンドを持つ人たちがWebを作り始めた第二世代では、Fixed designが多く採用されました。 ビジュアルな表現を主とするデザイナーにとっては、複雑な配置を決定できるFixed designのみが有益でした。

今日では、fixed designの方が大勢を占めているようです。 700〜800ピクセル幅でブラウザの中央に表示されるというのが最も一般的であると考えられます。

Liquid design採用時に超高解像度ディスプレイで画面を表示すると、画面幅が開きすぎて読みにくくなるという問題を解決するためにCSS2ではmax-widthというプロパティがあります。 ただ、大きな問題として、IEではmax-widthが動作しないというものがあります。 FirefoxとOperaではmax-widthが利用可能です。 IEでもwork aroundはありますが、JavaScriptが必要になってしまいます。

このmax-width問題はWebデザイナが抱えるジレンマの一つです。 理論的にはLiquidデザインが推奨されていますが、実際にはfixed designの方が互換性があります。

TABLE

さらに大きなジレンマの一つにHTML TableによるレイアウトとCSSによるレイアウトが挙げられます。 多くの人は「Tableは悪なのでCSSを使うべきだ」と言うかも知れません。

Tableは1997年にHTML3.2で登場しました。 当時はW3CでTableはtabular dataもしくは「layout purposes」で利用されるべきだとしていました。 HTML 3.2の時点でもTableはtext-onlyブラウザ、もしくは音声読み出しブラウザで問題を発生させる事はわかっていましたが、当時はより良い選択肢がありませんでした。

1997年の12月末頃には、HTML 4.01 が発表され、Tableによるレイアウトは推奨されなくなりました。 Tableの代わりに、レイアウトにはCSS(Cascading Style Sheets)の利用が推奨されました。

それから9年たった今でもTableはレイアウト用途に利用されています。 まず、WebデザイナにとってTableの方がCSSよりも簡単でした。 また、現状ではCSSの方がブラウザの種類やバージョンに依存した挙動がTableよりも多くなっています。

しかし、TableはCSSのようにコンテンツとデザインを分離することができません。 CSSを使うと、デザイナはコンテンツのための「skin」を作成することが出来ます。 例えば、採用するCSSを変えることで印刷用、PC用、PDA用に別々のレイアウトを採用する事ができます。

ただし、多くのデザイナがTableを使っているように、標準で最も推奨されている方法よりも、その場しのぎの方法が好まれる場合もあり得ます。

AJAX

Google suggestのように、AJAXで動的にサーバと通信をするWeb applicationが実現可能になりました。

AJAX技術の根本は、W3C標準では定義されていないXMLHttpRequest Objectというものを中心としています。 W3Cでは、似たような機能を持つ「Load and Save」という機能をDOM Level 3で定義しています。 Load and SaveはIEでもFirefoxでも実装されていません。 Operaでは実装されていますが、Webデザイナを奮起させるだけのシェアがありません。

さらに話をややこしくしているのが、IEではXMLHttpRequestを利用するために他ブラウザとは異なるコードを用意しなくてはならない事です。 これは、複数のブラウザでWebアプリケーションを動作させたいデザイナがブラウザ毎にコードを分岐させないといけないという結果につながります。

XMLHttpRequestはOutlook email applicationの機能向上のためにMicrosoftが発明しました。 Firefoxやその他ブラウザがそれを真似はじめてからAJAXが一気に普及しました。

将来のブラウザは非標準であるXMLHttpRequestをサポートし続けるのか、W3Cが現状に即した標準を規定するのか、W3Cが既にあるLoad and Saveの利用を推奨するのか、など課題が多くあります。 Webデザイナは顧客に流行しているがobsoleteになる可能性がある技術を勧めるべきかなどのジレンマがありますが、どうすべきかは結局誰も知りません。

今後の競合

将来の競合としてXFormsとWeb Forms 2.0が挙げられます。 現状のHTMLでは、片方のForm fieldを使うともう片方がdisableされるような事ができません。 現状では、このような機能はJavaScriptで実現されています。

当初、W3CではXFormsが策定されましたが、難しすぎるということでApple,Mozilla Foundation,Operaが独自にWeb Forms 2.0を作りました。 W3CではXFormsとWeb Forms 2.0の両方がそれぞれのWorking Groupで作成されています。 サードパーティブラウザは両方の標準を実装し始めていますが、Webデザイナはどちらを学習すれば良いかまだわかっていません。

まとめ

例えば、車のスペシャリストと呼ばれるような人は、あなたの車をいじりまわした後「以前に車を調整した奴は間違っている」と言うでしょう。 Webデザインの世界でも同様です。 Webデザイナは様々なジレンマに対処しなくてはなりません。 標準で定義されている手法やユーザインターフェース専門家が正しいという事が必ず正しいわけではありません。 また、思ったとおりに動くものが標準通りであるとは限りません。 Webデザインは様々な妥協案とBest Effortの集合体です。 一つ確実に言える事は「御社のWebデザイナの給料を上げても良いだろう」という事です。

   このエントリをはてなブックマークに登録   




アカマイ 知られざるインターネットの巨人

インターネットのカタチ もろさが織り成す粘り強い世界
「インターネットのカタチ - もろさが織り成す粘り強い世界 -」関連資料

マスタリングTCP/IP OpenFlow編
「マスタリングTCP/IP OpenFlow編」関連資料

Linuxネットワークプログラミング




外部サイト

プレコ王国
ディスカス魂
金魚タイムズ
YouTubeチャネル
Twitter
Facebook

フィードメーター - Geekなぺーじ
Copyright (C) Geekなページ.
All rights reserved. 無断転載や無断コピーなど、私的利用の範囲を逸脱した利用はおやめ下さい.