Web標準Blogでは、Web標準の利用に興味のあるWebサイト管理者、Webデザイナーの方向けに、Web標準を利用するための手法やノウハウ、参考になるリソース等を、国内外を問わずご紹介します。
なお当Blogでは、Web標準に関する疑問や質問を募集しています。Webコンテンツ実装プロセスにまつわるお悩みでも結構ですので、お気軽に電子メールでstandards@mitsue.co.jp宛にお送りください。
2009年06月25日
CSS WGのJune 2009 F2F
フロントエンド・エンジニア 矢倉
今月の頭になるのですが、CSS WGがフランスでFace to Faceミーティングを行っていました。ミーティングの議事録が公開されていたので、CSS 2.1やCSS3の現状について簡単に紹介しようと思います。
CSS 2.1のテスト
CSS 2.1の新しい勧告候補が4月23日に公開されましたが、次の段階に進むにはテストケースの完成と、それらに基づいた実装の検証が必要となります。テストケースはMicrosoftのものをはじめ数は集まりつつあるのですが、テストが正しいかを検証しなければならないため、時間がかかりそうです。
活動期限である2010年11月末まで1年半ほど。そこから逆算して、「テストは9月までにすべてを集め、その検証は12月まで」といった計画が立てられています。
Web Fonts
すでに草案が公開されていますが、CSS3 Fonts Moduleの新しい草案が公開されました。
新しい草案は、今まであった「CSS3 Fonts」と「CSS3 Web Fonts」として公開されていた草案を統合したもので、大幅に書き直されています。前のCSS3 Fonts草案にあった、フォントのエフェクト(エンボス加工など)を行うようなプロパティは省かれています。
新しい草案の公開
段組を実現するCSS3 Multi-column layoutの最終草案の公開が決定されました。また、これまでGeckoとWebKitが独自拡張として実装していたCSS3 FlexboxについてはCSS WGでの策定が受け入れられ、また近いうちに草案が公開されることも決定しました。
時期は定かではありませんが、getBoundingClientRectやscrollTopなど、座標を取得するプロパティを定義するCSSOM View Moduleについても、新しい草案を公開すると決まったようです。
その他の草案
CSS3にはさまざまなモジュールがありますが、数年間まったく動きのないものがほとんどです。ということで、注力する予定のない次の仕様は、作業を終了することが決定されました。
- CSS3 Math
- CSS
styleattribute syntax ― 拡張に関する部分を削除して、現在使われている構文のみを定義するように - CSS3 Hyperlink Presentation Module
- Introduction to CSS3 ― CSS Snapshotで置き換え予定
- CSS Reader Media Type
- CSS Aural Style Sheets
- CSS Scoping
- CSS3 Presentation Levels
終了ではありませんが、次の仕様についてはリソース不足のため作業ができないという確認がされました。
- CSS3 Ruby Module
- CSS Object Model
恒久リンク | コメント [0件] | 関連情報(トラックバック) [0件]
2009年06月23日
CSS Spritesでメモリ消費量が増える!?
フロントエンド・エンジニア 矢倉
WebサイトやWebアプリケーションの高速化のため、CSS Spritesを採用するサイトが増えてきています。
CSS Spritesは、ページで使うアイコンやロゴ、背景など、画像ファイルを大きな画像の塊にまとめ、CSS側でレイアウトを制御するテクニックです。複数の画像をまとめるため、HTTPリクエスト数を減らしことができ、高速化や負荷軽減につながるという利点があります。また、:hoverや:activeなどと組み合わせることにより、動的表現をJavaScriptなしで実現できることも、CSS Spritesが好まれている理由のひとつです。
一方で、CSSの画像置換に関連する問題や、画像の作成や配置にかかる手間など、懸念事項もあります。そんな中、Mozillaの開発者であるVladimir Vukićevićが、「メモリ消費量が増えてしまう」という問題について語っています。
CSS Sprites用にページ内の画像を全て統合した画像は、余白や色数が多くなることから、ファイルサイズ、面積ともに大きくなります。このような画像がページのあらゆるところで利用されると、レンダリングにおいてメモリを大量に消費してしまう問題があるようです。
例として挙げているのは、WHIT TVというサイトの背景画像として使われる、1299×15000の大きなPNG画像です。これはCSS Spritesと呼べるものではありませんが、CSS Spritesであれば画像の位置指定もありますし、色数も増えます。場合によっては、メモリ消費量がさらに増えてしまうのかもしれません。
ただし、CSS Sprites自体を否定しているわけではなく、大きさの異なる画像までまとめてしまうことについて問題があると考えているようです。ですので、アイコンなど大きさが似通ったものをまとめることについては、充分に利のあるテクニックであるとコメントしています。
恒久リンク | コメント [0件] | 関連情報(トラックバック) [0件]
2009年06月19日
W3CがWeb教育に関するグループを設立
フロントエンド・エンジニア 矢倉
W3Cより、Open Web Education Alliance Incubator Group (OWEA XG) の設立がアナウンスされました。
なかなかに長い名称ですが、ざっくり訳すならば「オープンなWeb教育のために協力しあうグループ」といったところでしょうか。活動内容ですが、OWEA XGのcharterにて次のように書かれています。
The mission of the Open Web Education Alliance Incubator Group, part of the Incubator Activity, is to help enhance and standardize the architecture of the World Wide Web by facilitating the highest quality standards and best practice based education for future generations of Web professionals
OWEA XGのミッションは、次世代のWebプロフェッショナルのために、高水準な教育を提供し、Webの価値をさらに高めるというものだそうです。そのための取り組みとして、ナレッジや資料を共有するための場を設けることを考えているようです。
グループが出す成果物についてですが、カリキュラムなどの作成は行わないとしています。カリキュラムについてはOpera Web Standards Curriculumなど、有用なリソースが既に存在しています。これらを「どのように利用するか」という観点から考えたいのでしょう。
グループのリードは、microformatsの書籍や、イベント「Web Directions」の主催でおなじみのJohn Allsoppです。何度かお話をしたことがあるのですが、Web技術やそれらの可能性についていつも熱心なひとという印象があります。活動は1年と短く、すべてが計画通りに進むかは分かりませんが、とても楽しみなアクティビティです。
恒久リンク | コメント [0件] | 関連情報(トラックバック) [0件]
2009年06月12日
<canvas>とアクセシビリティ
フロントエンド・エンジニア 矢倉
先月末のGoogle I/Oで取り上げられてから、HTML5がにわかに盛り上がってきました。
I/Oのキーノートでまず紹介されたのが、スクリプトからビットマップ画像を操作するcanvasでした。これまでGDやFlashが使われていた画像処理をブラウザー内で完結できるため、多くの開発者から期待されているようです。
しかし、一方でアクセシビリティの専門家は懸念を抱いているようです。The Paciello GroupのSteve Faulknerが先日公開した、canvasとアクセシビリティに関する記事が面白かったので、今回はこれを取り上げてみようと思います。
- The Paciello Group Blog » Thinking About HTML 5 canvas Accessibility
- The Paciello Group Blog » Notes on accessibility of text replacement using HTML5 canvas
canvas APIのアクセシビリティ対応
彼がcanvas APIの問題点として挙げているのは、次の二点です。
- テキストを描画するAPIはあるが、そのテキストへのアクセサがない
- 画像を挿入するAPIもあるが、代替テキストを与える仕組みがない
ここで難しいと思うのが、テキストを取得できたとしても、それだけでは代替となる適切な情報が得られるか分からないことです。とくにcanvasは視覚的な表現にかなり依存したものになることが多いでしょうから、APIが用意されるだけで問題が簡単に解決できるわけではないように感じます。
さらに、canvasは一度描画されてしまうと、一部を書き換えるといったことができません。動的な更新には全体の再描画が必要となるのですが、動きが加わってしまうと、さらに代替情報を提供することは難しくなるでしょう。
代替情報は入れられるが……
canvasがアクセシビリティについて何も考慮していないかというと、そうはありません。要素内容を持つことができるので、そこに代替情報を記述すればよいわけです。
たとえば、円グラフを描きたい場合を考えてみましょう。canvas内にtableを記述し、そこにデータを持たせるのです。canvasがセルの情報をひろって描画するようなコードを書けば、アクセシブルになりそうです。
<canvas id=pie-chart>
<table border id=data-browser>
<caption>2009年5月のブラウザーシェア</caption>
<tr><th>ブラウザー<th>割合
<tr><td>IE7<td>40.83%
<tr><td>Firefox 3.0<td>20.43%
<tr><td>IE6<td>16.94%
<tr><td>IE8<td>6.85%
<tr><td>Safari 3.2<td>4.56%
<tr><td>Safari 3.1<td>1.81%
<tr><td>その他<td>8.41%
</table>
</canvas>
ところが残念なことに、スクリーンリーダーはcanvas要素をすべて無視してしまい、中にある代替情報を読み上げることができないとのことです。
記事では、空のcanvasの後に代替情報を配置し、スタイルシートで画面外へ押し出すという回避策も紹介していますが、あまり賢い解決方法ではないように思います。
canvasだけの問題か
canvasには、代替テキストに関連するインターフェースがなく、スクリーンリーダーが内容を読んでくれないという問題があることがわかりました。
しかし、canvasは一つの手段でしかありません。canvasで表現される情報をアクセシブルにしても、実現したい機能すべてについてアクセシビリティが確保されなければ、問題の解決とはいえません。これは画像やFlashにについても同じことがいえるでしょう。
機能ごとのアクセシビリティ対応ももちろん重要なのですが、それだけに気をとられてしまって、ちぐはぐな「対応」になってしまわないように気をつける必要があります。それにはやはり、「何を実現したいのか」「何が適切な手法なのか」をきちんと考えることが大切なのではないかと考えています。
恒久リンク | コメント [0件] | 関連情報(トラックバック) [0件]
2009年06月02日
2009年5月のW3C: XHTML仕様の修正勧告案が撤回に
フロントエンド・エンジニア 矢倉
XHTMLの修正勧告案
5月7日に、XHTML2 WGは4つのXHTML仕様について、その修正勧告案 (Proposed Edited Recommendation) を公開しました。
- XHTML 1.0 - Third Edition
- XHTML 1.1 - Second Edition
- XHTML Basic 1.1 - Second Edition
- XHTML-Print - Second Edition
「修正勧告案」という見慣れない単語が出てきましたが、これは勧告に修正を施し更新する際に、コミュニティからの同意を得るために公開される仕様書を表します。XML 1.0などはこの仕組みを利用して更新されています。
「撤回」された修正案
さて、これらXHTML仕様がすんなり更新されるかと思いきや、5月19日にその修正勧告案が「撤回 (rescinded)」されたと発表されました。
「撤回」という表現もあまり見ないものですが、W3Cのプロセス文書には「勧告された文書に重大な問題などが見つかった場合には、勧告を撤回することができる」という規定があります。
修正勧告案に対しては撤回に関する条項がないのですが、問題があったので修正勧告案としての公開を取り下げたという意図があるのでしょう。
取り下げられた理由については、「仕様の修正や、修正事項の公開が満足に行われていない」というコメントが寄せられたためです。W3Cのプロセスでは、仕様が次の段階へ進むための要件を定義していますが、それを満たせていないということで、今回の撤回が行われました。
不備を減らすためのプロセス
なかなか厳しいように思えるW3Cのプロセスですが、「使える」仕様を作るためには、不備の数は可能な限り減らしてから展開する必要があります。過去のW3Cには不備を減らすプロセスが満足に用意されていなかったため、CSS 2.0やHTML4などが未成熟なかたちで勧告されてしまいました。
現在ではプロセスの改訂が行われており、不十分なかたちで仕様が勧告になることはありません。すでに勧告された古い仕様に対しても、CSS 2.1やHTML5などエラーを修正する大掛かりな取り組みも行われています。XHTMLについてもきちんと修正を行い、より安定したものが公開されるといいですね。
