Web標準Blogでは、Web標準の利用に興味のあるWebサイト管理者、Webデザイナーの方向けに、Web標準を利用するための手法やノウハウ、参考になるリソース等を、国内外を問わずご紹介します。
なお当Blogでは、Web標準に関する疑問や質問を募集しています。Webコンテンツ実装プロセスにまつわるお悩みでも結構ですので、お気軽に電子メールでstandards@mitsue.co.jp宛にお送りください。
2008年10月17日
メディアクエリーの最終草案が公開
フロントエンド・エンジニア 矢倉
CSS WGより、メディアクエリー (Media Queries)の最終草案が公開されました。
メディアクエリーとは
メディアクエリーは、link要素のmedia属性やCSSの@mediaを拡張したもので、デバイスの条件を指定しスタイルシートを適用可能にする技術です。
たとえば、「幅が1280pxなディスプレイ」と「幅が1600pxなディスプレイ」で、異なるスタイルを割り当てることができます。
/* 一般的なスクリーン */
@media screen and (device-width: 1280px) {
.main {
width: 600px;
}
.sub {
/* 何もせずフッターにする */
}
}
/* 幅の広いスクリーンでは2カラムに */
@media screen and (device-width: 1600px) {
.main {
width: 800px;
float: left;
}
.sub {
width: 250px;
float:right;
}
}「device-width」はデバイスの幅を表します。このような情報は「媒体特性 (media features)」と呼ばれ、メディアクエリーでは幅や高さ、カラーインデックスなど計13の媒体特性が定義されています。
各ブラウザーのサポート状況
メディアクエリーの実装状況ですが、正式版としてリリースされたものの中では、Operaが最も進んでいます。Operaはモバイル機器など、デスクトップコンピューター以外のデバイスにもブラウザーを提供しているため、メディアクエリーの実装も積極的に行っていたようです。このため、たとえばWiiのインターネットチャンネルでもメディアクエリーを利用することが可能です。
続いて、Safari (WebKit)です。iPhoneの登場もあり、Safariは3よりメディアクエリーに対応しています。しかし、現段階では動的な変更（ウインドウ幅を変えた、など）に対応していないため、すこし使い勝手がよくありません。現在開発版として提供されているSafari 4では、メディアクエリーの動的変更に対応しているため、来年あたりにはより良いサポート状況になっていると思われます。
Firefoxですが、来年公開予定のバージョン3.1での対応を表明しています。しかし、先日公開されたFirefox 3.1 Beta 1でサポートがされ始めているようです。
Internet Explorerについては、最新版のIE8でも対応していませんが、IE9以降でのサポートに期待したいところです。
メディアクエリーの今後と日本語訳
メディアクエリーは昨年6月に勧告候補となったものの、その時点でSafariやFirefoxでの実装がスタートしていませんでした。その後実装が進み、得られたフィードバックを反映させた結果、今回は再び最終草案として公開されています。しかし、3つのブラウザーベンダーが実装に動いていることから、勧告もそう遠くはないと考えています。
さて、勧告候補版は日本語訳を公開していたこともあり、新しい草案についても日本語訳を用意しました。
また、実装状況を調べるため、ほんの少しですがテストを作成しました。メディアクエリーがどのようなものなのかをつかむ手助けになれば幸いです。
- width-001.xhtml
- height-001.xhtml
- device-width-001.xhtml
- device-height-001.xhtml
- aspect-ratio-001.xhtml
- device-aspect-ratio-001.xhtml
恒久リンク | コメント [0件] | 関連情報（トラックバック） [0件]
2008年10月16日
10月前半のW3C
フロントエンド・エンジニア 矢倉
XMLHttpRequest Level 2
WebApps WGよりXMLHttpRequest Level 2の最新草案が公開されました。
XHR2はXMLHttpRequestを拡張し、クロスサイト通信などを可能にしたものです。先日公開されたAccess-Controlとあわせての利用が想定されています。
XHTML Modularization 1.1が勧告に
XHTML Modularization 1.1が勧告されました。
M12nはXHTML 1.0や1.1のようなプロファイルではなくフレームワークです。たとえば、XHTML 1.1はM12nのモジュールを組み合わせたプロファイルとして定義されています。ほかにも、role属性や、access要素、WAI-ARIAの属性は、XHTMLモジュールとして組み合わせられるように設計されています。
1.1では、1.0で見つかったエラーの修正や、XML Schemaへの対応が行われています。
M12nが固まったことを受け、XHTML 1.1もSecond Editionとして、早期の勧告が見込まれています。こちらもエラーの修正と、XML Schemaへの対応というアップデートになる予定です。
RDFaが勧告に
RDFaの構文仕様が勧告されました。
RDFaは、XHTMLでより詳細なメタ情報を表現するための仕様です。「メタ情報をXHTMLに埋め込むRDFa」や、「Web標準仕様 日本語訳一覧」で、書き方や実際の利用例を公開しています。
恒久リンク | コメント [0件] | 関連情報（トラックバック） [0件]
2008年10月14日
ズーム機能と文字サイズ変更機能のこれから
フロントエンド・エンジニア 矢倉
CSS Zen Gardenの創始者であるDave Sheaが、“Zoom”という記事で、ブラウザーのズーム機能の普及がこれからのWeb制作にどのような影響を及ぼすかを投げかけたことで、活発な議論が行われています。
画像やレイアウトを維持しながらページ全体を拡大するこのズーム機能は、Internet Explorerでは7から、Firefoxでは3から、そしてOperaにはかなり前のバージョンから搭載されています。従来からのテキストサイズ変更機能もIEやFirefoxには残っていますが、現在はズーム機能のほうをプッシュしているようです。Safari（WebKit）では今のところテキストのサイズ変更のみを搭載していますが、開発版ではズーム機能が実装され、デフォルトの挙動として採用されているとのことです。
つまり来年には、どのブラウザーもズーム機能を実装しているものと考えられます。ズーム機能の普及は、Web制作やユーザー体験、そして従来あるテキストの拡大・縮小機能にどのような影響を及ぼすのでしょうか。
テキストの拡大・縮小機能とズーム機能
テキストの文字サイズ変更機能は、CSSの書き方が悪いページのレイアウトをひどく崩してしまうという問題がありました。ブラウザーのせいではありませんが、ユーザー体験としてはあまりいいものではありません。ページをほぼそのまま拡大し、かつ横スクロールバーを出ないように配慮してくれるズーム機能は、デザイナーにとってもユーザーにとっても良い解決策のように見えます。
しかしながら、テキストのみを拡大するニーズというのも存在するのではないかと考えています。たとえば、一文の単語数や文字数を自分が読みやすいように調整するといったことは、ズーム機能では難しくなっています。また、画像など多いページでは、ズーム機能によって画像も拡大されてしまうため、画像の閉める面積が増えてしまい、テキストがかえって読みづらくなってしまうケースも考えられます。
また、ブラウザーによっては、本文領域がウインドウ幅を超えないように配慮してズームするようになっているものもありますが、すべてのページでこれが機能するわけではありません。本文領域の最大幅を指定しない場合、横スクロールバーが拡大時に現れ、ユーザーが不満をもってしまう懸念もあります。
さらに、各ブラウザーでズームの挙動が微妙に異なるため、ブラウザーごとに対応を迫られるといった手間が発生するかもしれません。また、IE7でズーム機能を利用すると、リンクがズーム前の位置に固定されたままになる場合など、バグも存在しています。
過渡期ということもありますし、ズーム機能にはまだまだ解決すべき問題が眠っているのではないかと感じます。
サイズ変更のインターフェース
近年、「小」「中」「大」といった、文字サイズをJavaScriptによって動的に変更するインターフェースを設けたWebサイトが増えています。アクセシビリティを向上させる対策というものなのでしょうが、一種の「トレンド」として用意されているようにも思えます。
しかし、このようなインターフェースは、ブラウザーが何らかの拡大インターフェースを備えていることにより、そもそも必要ないのではという指摘もあります。このため、「文字サイズを変更するには」といった、ブラウザーの拡大機能を利用するよう促すページを設けているWebサイトも存在します。
小中大ボタンが増えているのは、ブラウザーが持つ拡大・縮小機能へ簡単にアクセスできない、GUI上の問題があるからではないかと考えています。ユーザーが視認しやすい場所にインターフェースを用意することで、拡大・縮小をより身近な機能として認識させることができるのではないでしょうか。
恒久リンク | コメント [0件] | 関連情報（トラックバック） [0件]
2008年10月 8日
A List ApartからProressive Enhancementに関する記事が公開
フロントエンド・エンジニア 矢倉
10周年を迎えたA List Apartから、“Understanding Progressive Enhancement”という記事が公開されています。Progressive Enhancementによる
Web開発を解説するシリーズの第一弾ということで、今後の公開が楽しみです。
“Progressive Enhancement（漸進的な機能拡張）”を簡単に説明すると、基本となる機能はすべてのターゲットブラウザーに、より高機能なものはブラウザーの能力にあわせて実装するという設計思想です。ここでの「基本となる機能」はページの内容、コンテンツを指します。記事では、M&M’s ピーナッツをモチーフに、コンテンツ、CSSによる見た目、そしてJavaScriptによる挙動という三層構造を説明しています。
Progressive Enhancementは「Web標準」と呼ばれる思想を無理なく実現することができるものですが、現在のWeb制作では「どのブラウザーでも同じ見た目にする必要がある」といった要件を持つことが多いため、そのまま導入することはできません。また、Webアプリケーションのように動的処理が密接にコンテンツと関わるような形態では、基本機能の定義を行うことが難しいでしょう。
とはいえ、ブラウザーやモバイル機器など、閲覧環境は急速に多様化しており、「同じ」を求めることが理にかなう考えではないとの認識も広まりつつあります。Webの持つ柔軟性を最大限発揮するためにも、開発において広がりを持つProgressive Enhancementというコンセプトは、今後さらに注目されるのではないかと考えています。
恒久リンク | コメント [0件] | 関連情報（トラックバック） [0件]
2008年10月 2日
9月後半のW3C
フロントエンド・エンジニア 矢倉
9月前半については、「9月前半のW3C」をご覧ください。
SVG Tiny 1.2が最終草案に
モバイル機器向けとして開発されたSVG規格「SVG Tiny」、その最新版である、SVG Tiny 1.2の最終草案が9月15日に公開されました。
SVG Tiny 1.2は2006年8月に勧告候補となっていましたが、実装側のフィードバックを反映し、最終草案に一度差し戻されました。しかし、実装上の問題点は解決できたとして、二つ以上の実装が用意され次第、勧告提案へ進むとSVG WGが発表しています。
Geolocation Working Groupの発足
携帯電話などのモバイル機器と位置情報を連携させるサービスが増えていますが、Webアプリケーションにおいて、位置情報の取得などを行うインターフェースは標準化が行われておらず、また発展途上の段階にあります。このような流れをふまえ、W3Cは位置情報インターフェースの仕様を策定するGeolocation Working Groupを設立しました。
すでにGeolocation APIの内部ドラフトも存在しており、MozillaはFirefox 3.1でのサポート開始を表明しています。
恒久リンク | コメント [0件] | 関連情報（トラックバック） [0件]
2008年10月 2日
WAI-ARIAの普及と検証における課題
フロントエンド・エンジニア 矢倉
RIAをアクセシブルにするための規格「WAI-ARIA」の策定が進み、またブラウザーやJavaScriptライブラリー側での実装も少しずつですが増えてきています。ARIAの基盤が固まり始めたことをうけて、W3CのWeb Accessibility Initiativeは、ARIAの普及に向けた取り組みについて検討しているようです。
WAI-ARIAはまだ草案段階ではありますが、WAI-ARIA FAQ（日本語訳）では、今から導入することの利点を挙げ、利用を促しています。
しかしながら、ARIAの導入には2つの大きな問題があります。ひとつは、ARIA仕様が追加する新しい属性が、既存のXHTMLやHTMLに組み込まれていないこと。もうひとつは、マークアップや挙動が正しいかを確認する検証環境がないことです。
WAI-ARIAと文法的妥当性
ARIAでは、role や aria-checked といった、役割や状態をマークアップするための新しい属性が導入されています。これらの属性はXHTML Role 属性モジュールやARIA属性モジュールとして定義されていますが、利用にはXHTML 1.1など、モジュール化されたXHTMLが対象となっています。
このため、既存のXHTML 1.0やHTML 4で制作されたWebアプリケーションに、ARIAで利用する属性を組み込んでしまうと、文法エラーとなってしまいます。
また、XHTMLにARIAを組み込んだプロファイルも現在は定義されていません。利用を促しているとはいえ、文法的に「正しく」ARIAを利用することはまだできないのです。
動的なHTML文書の検証
ARIAはWebアプリケーションなど、スクリプトにより動的にページの内容が書き換わる文書のアクセシビリティを確保するための技術です。この「スクリプトにより動的に書き換わる」という性質が、ARIAを組み込んだ文書の検証における、大きな課題なのです。
一般的なValidatorはページのHTMLのみを取得し、文法違反がないかを確認しています。このため、スクリプトなどはその内容が解析されず、スクリプトがもたらす文法違反をチェックすることができません。動的処理がほとんどの場合前提となるWebアプリケーションにおいては、ARIAに関わらずその検証を行うことができないのです。
また、ARIAの検証においては、文法に適合しているかよりも、本当に正しい挙動を行えているかが重要です。マウスをクリックしたときに、特定の要素の役割や状態が適切に書き換わっているかを検証するには、状態が変更したときに都度検証をかける必要があります。従来のURLを入力して結果を出力するといった流れではあまり意味がないのです。
このため、ARIAの検証にはブラウザーのプラグインなど、新しい形態のツールが必要ではないかという意見もでています。
ARIAは今利用できない技術？
だからといって、WAI-ARIAの導入が現実的でないかというと、そうではありません。ブラウザーだけではなく、内部的にARIAを導入しているJavaScriptライブラリーが増えてきています。一番実装が進んでいるのはDojo Toolkitですが、jQuery UIやYahoo! UI Libraryも実装に向けた取り組みを開始しています。
これらのライブラリーが持つウィジェットを利用することで、検証についてはある程度のカバーができるでしょう。XHTML 1.0やHTML 4で文法的に利用できないといった問題は残りますが、それだけを理由に採用を行わないという判断は、すこしもったいないように感じます。
恒久リンク | コメント [0件] | 関連情報（トラックバック） [1件]
