Web標準Blog
Web標準Blogでは、Web標準の利用に興味のあるWebサイト管理者、Webデザイナーの方向けに、Web標準を利用するための手法やノウハウ、参考になるリソース等を、国内外を問わずご紹介します。
なお当Blogでは、Web標準に関する疑問や質問を募集しています。Webコンテンツ実装プロセスにまつわるお悩みでも結構ですので、お気軽に電子メールでstandards@mitsue.co.jp宛にお送りください。
当Blogの更新情報は、Twitter経由でも配信しています。興味のある方はぜひ、@mlcstandardsをフォローしてください。当Blogへのご意見・ご質問は、Twitter経由でも受け付けております。
2012年2月17日
Mutation Event から Mutation Observers へ
“Detect DOM changes with Mutation Observers” で紹介されているように、DOM4 では Mutation Observers という新しいインタフェイス群が定義されました。これらを用いると、DOM2 Events で定義された Mutation Event を置きかえることができます。
Mutation Event は数々の問題点を抱えていることが明らかになっています（策定中の DOM3 Events では該当箇所に警告文が記述されているほどです）。例えばパフォーマンスに関わる問題があります。Mutation Event では子ノードだけでなく、すべての子孫ノードからイベントが発送されます。よって、子孫ノード数が多く、ルートノードに近いノードでは、場合にもよりますが膨大な数のイベントを拾ってしまいがちになります。それらをいちいちイベントリスナ内でチェックする必要があるため、その処理だけで時間がかかりがちです。また、すべて同期（Sync）イベントでもあります。複雑な Web アプリケーションではノード数も多くなりがちなので、よりパフォーマンスに与える影響が大きくなります。
Mutation Observers は、こうした Mutation Event の問題点を解決、もしくは軽減するために定義されたといっても過言ではないでしょう。Mutation Observers は様々なオプションを与えて「どの範囲の何を対象にするか」を決定することができます。
例えば、先程問題点として挙げたすべての子孫ノードからイベントが発送されうる問題も、オプションを { childList : true } とすれば対象を子ノードに限定することが可能であるため、簡単に回避することができます（子孫ノードをすべて対象にしたいなら { childList : true, subtree : true } とする）。
本エントリの執筆時点では、WebKit のみベンダー接頭辞つきで実装されています（が、完全ではありません）。Gecko (Mozilla) はベンダー接頭辞つきで実装している途中です。Presto (Opera) は 12.00 Build 1272 時点では未サポートです。Trident (IE) は IE10 PP (10.0.8103.0) 時点では未サポートです。
2012年1月 5日
2011年12月のW3C
Geolocation API Level 2, DeviceOrientation
12月1日付で、Geolocation WGから2仕様の草案がLast Callとして公開されました。
Geolocation API level 2はGeolocation API仕様の拡張仕様で、住所を取得するAddressインターフェースが追加されています。DeviceOrientation Eventはデバイスの傾きや加速度などに関するインターフェースを定義しています。
Geolocation APIは初めての草案ですが、Last Callとなっています。追加される機能が少ないことや、数年前からEditor's Draftのかたちで存在していたことがいきなりのLast Callに繋がっているのでしょう。
Media Fragments URI 1.0
Media Fragments WGが策定するMedia Fragments URI 1.0仕様が、12月1日付で勧告候補となりました。
Media Fragments URIは、画像やビデオなどのメディアリソースのURIについて、画面上の領域や時間の一部をフラグメント識別子から表す仕組みです。
仕様で定義されているTemporal dimensionというフラグメントでは、ビデオや音声ファイルの一部分を、そのURIから指定できます。
<video src="nevergonnagiveyouup.webm#t=43,60">...</video>このようにメディアファイルに特別なフラグメント識別子を与えることで、「43秒から60秒まで」といった範囲を指定できます。昨年12月20日にリリースされたFirefox 9で一部実装されており、利用できます。
Media Fragmentsには他にも画像の一部を指定するフラグメントなども定義されていますが、いまのところ実装はありません。
CSS3関連3草案
12月6日付で、新しいImage Valuesモジュールの草案が公開されました。
昨年紹介したradial-gradient()の構文変更も反映されています。
12月13日付で、CSS Exclusions and Shapesモジュールの草案が公開されました。
12月15日付で、CSS 2D Transformsの草案が更新されました。
今後はSVG WGとの合同タスクフォースであるFXTFでの作業となり、CSS 3D Transforms, SVG Transforms仕様と統合されることもあり、仕様書に注釈が加わっています。
WebSocket API, Web Storageの勧告候補
12月8日付で、WebSocket APIとWeb Storageが勧告候補として公開されました。
WebSocketのプロトコル仕様については、昨年末にRFC 6455として発行されています。
Touch Events 1の勧告候補
12月15日付で、Web Events WGからTouch Events version 1仕様の勧告候補が公開されました。
Audio WGから3仕様が公開
12月15日付けで、Audio WGから音声処理に関する仕様の草案が3つ公開されました。
仕様書の名前を見ると、3つの音声関連API仕様が策定されているように見えますが、最初のAudio Processing APIについては今のところ、Web Audio APIとMediaStream Processing API仕様を簡単に比較した文書となっています。
Web Audio APIはGoogleが提案したもので、Chromeで試験実装が行われています。MediaStream Processing APIはWebRTC仕様やMozillaの拡張であるAudio Data API、そしてWeb Audio APIを参考に作られた新しい仕様とのことです。
2011年12月27日
2011年のWeb標準
2011年も残すところあと数日となりました。というわけで、Web標準に関する今年の出来事を簡単ですがまとめてみました。
HTML5のLast Call
5月25日に、HTML5がLast Callとして公開されました。
Last Call期間中には、1500を超えるコメントがバグとして登録されました。
上のエントリでは当時のLast Call後のスケジュールについて触れていますが、その後引き直され、現在は年末までにバグの解決、4月上旬にissueを解決し、次のステップについて発表することになっています。
"Last Call"というラベルではありますが、機能が完成したというわけではありません。他のグループや実装側からのフィードバックによって、仕様には今も大小様々な変更が行われています。
たとえば、Last Call以降、HTML5には次のような機能が追加されました。
crossorigin属性typemismatch属性download属性
WHATWGのHTML仕様では、data要素の導入とtime要素の改定も行われています。
追加だけではなく、分離も行われています。DOM関連では、getElementsByClassName()などいくつかの概念がDOM4に、編集に関わるAPIはHTML Editing APIs、UndoManager and DOM Transactionといった別の仕様で定義されるようになっています。
WHATWGのHTML仕様で定義されていたいくつかの機能も、W3Cで協議されるようになりました。
getUserMedia()メソッドなどは、WebRTC WGのWebRTC仕様の基礎となりました。video要素のtrack要素で利用するテキストトラック仕様WebVTTも、Web Media Text Tracks Community Groupという専門のCommunity Groupでの検討に入りました。
2012年の終わりには勧告候補というスケジュールが考えられているようですが、継続して加えられる変更をどう反映していくかが課題となりそうです。
CSS 2.1勧告、CSS3の前進
CSS 2.1やいくつかのCSS3モジュールが勧告されました。
また、2週間前にはCSS WGの新しいcharterが発行されました。2013年9月末までの活動計画をうかがえます。
期限内には背景&ボーダーモジュール、Values & Unitsモジュール、Basic UIモジュールの勧告が見込まれているようです。勧告に向け仕様も動き始めており、たとえばUIモジュールでは実装や相互運用性に乏しいappearanceプロパティの削除など、今後のコンテンツ作成に影響しうる大きな変更もあります。
Text, Fonts, Flexbox, Image Valuesについては、勧告候補が見込まれています。多くの機能が実装中ですので、実装状況やテストケースの作成状況によっては、それ以上の段階に進めるのかもしれません。相互運用性に乏しい機能が分離される可能性もあるでしょう。
さて、今年はRegions, Exclusions, Grid Alignmentなど、レイアウトに関する新しい仕様が提案されました。RegionsはAdobeが提案したものですが、Microsoftが賛同しIE10のPlatform Previewに実装されるなど、実装の動きが早く驚かされます。
とはいえ、レイアウトに関する仕様は増える一方で、どう標準化するかを協議している段階でもあります。デバイスの多様化や雑誌・書籍の電子化といった流れから、高機能なレイアウト仕様はこれまで以上に求められています。
SVG 1.1 SE勧告、FXTF
SVG 1.1 Second Editionも改訂作業が完了し、8月に勧告されました。
次期バージョンのSVG 2.0に向けた作業も進み、要件や決定事項も増えています。
グラフィックに関しては、SVG 2.0以外にももうひとつ動きがあります。CSSとSVGの両方で利用可能な機能を定義するため、両WGが合同で作業するFXTF (CSS-SVG Effects Task Force)です。FXTFの活動は2年前から始まっていましたが、CSS 2.1, SVG 1.1という大掛かりな改訂作業が終わり、活動が本格化しています。
対象となる機能は、Transforms, Transitions, Animations, Filter Effectsなどが挙げられます。Transformsについては、CSS 2D Transforms, CSS 3D Transforms, SVG Transformsの3仕様がCSS Transforms仕様として統合されることが決定しています。
継続的な変化への対応が課題か
今年はFirefoxがChromeに続きスケジュールベースのリリース方針に移行したことで、新しい機能が早く利用できるようになりました。また、多くのベンダーが比較的安定した開発版を提供し、開発者へのアピールも積極的に行うようになりました。
仕様策定においても、多くの仕様がEditor's Draftを公開し、公式な草案となる前からフィードバックを受け付けています。Editor's Draftは実装者や開発者からのフィードバックが継続的に編集されるため、草案よりも安定しているケースも少なくありません。
こうした流れに、W3Cの現在のプロセスがうまく適応できていないという問題提起も起こっています。W3Cプロセスについて議論するCommunity Groupなども立ち上がり、議論が始まったところです。
継続的に変化する仕様や実装に適応できていないのはプロセスだけでなく、制作側の方針にも言えることでしょう。仕様と実装がお互いを作り替えるいまの流れによって、安定した仕様は求めにくくなっています。コンテンツを制作・提供する側はどれだけ柔軟に変化を受け入れられるか、その方針づくりが課題となるでしょう。
大まかですが、2011年のまとめとさせて頂きます。 2012年もWeb標準Blogをよろしくお願いいたします。
2011年12月 2日
2011年11月のW3C
TPAC開催
10/31から11/4まで、米国カリフォルニア州のサンタクララでW3Cの総会TPAC 2011が開催されました。
週半ばのTechnical Plenaryについては、今月発売のWeb Designingの連載で取り上げております。
W3Conf開催
TPACから2週間後の11月15日と16日には、ワシントン州シアトルでW3Cが主催する初めてのカンファレンスである「W3Conf」が開催されました。
セッションの動画も公開されています。Web標準によるデータ視覚化やブラウザ開発者のパネルディスカッションなど、面白いセッションが多数あったようです。
CSS3の4草案と新しいスタイルシートの実験
11月29日付で、CSS WGからCSS3の4モジュールが更新されました。
- CSS Flexible Box Layout Module
- CSS Template Layout Module
- CSS Regions Module Level 3
- CSS Generated Content for Paged Media Module
Regionsモジュールについてはスタイルシートが随分違うものになっていますが、これは先日CSS WGに加入したBen Schwarzが他のCSS WGのメンバーと共に実験中の新しいスタイルシートです。
Benは開発者版のWHATWG HTML仕様のスタイルも手がけています。
Content Security Policy
11月29日付で、Web Application Security WGからContent Security Policyの草案が公開されました。
最初の公開草案ではありますが、GeckoやWebKitが試験的に実装を進めており、Chromeでは内部で利用しています。拡張にも適用するという話があるようです。
2011年11月28日
CSSグラデーションの構文変更とベンダー接頭辞
前回のベンダー接頭辞に関するエントリで、接頭辞なしの機能を併記してもうまくいかないことがあると書きました。
これは、標準化された（接頭辞のない）機能の構文もしくは解釈が変わってしまう場合を意図しています。そして、CSSのグラデーションでそうした変更が加えられています。
linear-gradient()のキーワードが変更に
少し前の話になりますが、9月8日に更新されたCSS3 Image Values草案では、linear-gradient()の構文で利用されるキーワードの書式が変更されています。
| これまでの構文 | linear-gradient( [deg | side] , color-stops)
|
|---|---|
| 提案された構文 | linear-gradient( [deg | to side-or-corner] , color-stops)
|
これまで、キーワードは、topなら下向きのグラデーション、rightは左向きのグラデーションなど、グラデーションの基点を示していました。
しかし、7月12日版の草案でdegの解釈が変更され、0degが下から上へのグラデーションを表すことになりました。
ここで、0degは「上向き」topは「下向き」になります。どちらも「上」を想起させますが、グラデーションの方向が正反対になります。これは混乱のもとになります。
このため、9月8日版の草案でキーワードの構文が変更されました。新しいキーワードは、to bottom、to topなど、方向を示していることが文字から分かりやすくなりました。
/* これまでのキーワードは基点を指定する */
background-image: -moz-linear-gradient(top, #eee, #ddd);
/* 新しいキーワードは方向を指定する */
background-image: linear-gradient(to bottom, #eee, #ddd);
キーワードが変わってしまったため、linear-gradient(top, #eee, #ddd); など古いキーワードを利用した接頭辞なしの記述は無視されてしまいます。
解決策ではありませんが、上から下へのグラデーションについては、キーワードを省略すると良いかもしれません。キーワードを省略すると、それは下方向へのグラデーションになると定義されているのですが、これは接頭辞つきの実装と新しい仕様においても共通だからです。
background-image: -moz-linear-gradient(#eee, #ddd);
background-image: linear-gradient(#eee, #ddd);
radial-gradient()の構文が変更
構文の変更はlinear-gradient()だけなく、radial-gradient()にも及びそうです。今月初めに開催されたTPAC 2011のCSS WG F2Fミーティングで議論され、CSS WG BlogやCSS3.infoに、コメントを求める記事が投稿されています。
提案されている新しい構文では、to size, at positionなどキーワードを追加し、値だけだった以前の構文に比べて「読める」ようになっています。
| これまでの構文 | radial-gradient(position, [size || shape], color-stops)
|
|---|---|
| 提案された構文 | radial-gradient(shape [to size || at position], color-stops)
|
/* 位置、大きさ、カラーストップ */
background-image: -webkit-radial-gradient(10% 20%, 25px 25px, #999 50%, #fff);
/* 一例 */
background-image: radial-gradient(circle to 25px at 10% 20%, #999 50%, #fff);
/* 次のようにも書ける */
background-image: radial-gradient(at 10% 20% to 25px 25px, #999 50%, #fff);新しい構文によって将来的な拡張も容易になったとのことですが、既存の接頭辞つき実装と構文が異なるため、いま書かれている接頭辞なしの記述は無視されてしまいます。
追記 (2011-12-07)12月6日付で、[新しいImage Valuesモジュールの草案](http://www.w3.org/TR/2011/WD-css3-images-20111206/)が公開されました。radial-gradient()の構文が更に下記のように変更されました。
| 新しい構文 | radial-gradient( [ shape || size ] at position, color-stops)
|
|---|
既存コンテンツへの影響も
接頭辞なしの記述が無視されるだけであればよいのですが、接頭辞つき機能の実装が将来削除されることも否定できません。
たとえばMozillaは、-moz-background-sizeなど一部の接頭辞つき機能について、正式な機能を実装してから一定期間後に削除しています。接頭辞つきのグラデーション実装が削除されるとは思えませんが、すべての接頭辞つき機能が残り続けるわけではありません。
構文は変更されず、その解釈だけが変更されるとさらに厄介です。linear-gradient()の項でdegの解釈が変わったことに触れましたが、これは解釈の変更であり構文の変更ではないので、現時点で接頭辞なしの記述を含めたコンテンツで表示に影響が出かねません。
たとえば、AdobeがAdobe Labsにて実験的に提供しているFireworks CSS3 Mobile Packがでは、Fireworksで作成したグラフィック要素からCSSコードを自動生成する機能が提供されています。
デベロッパーセンターの紹介記事から、生成したコードの一部を取り上げます。
/* Firefox v3.6+ */
background-image:
-moz-linear-gradient(50% 0% -90deg,...
/* Chrome v10.0+ and by safari nightly build*/
background-image:
-webkit-linear-gradient(-90deg,...
/* Opera v11.10+ */
background-image:
-o-linear-gradient(-90deg,...
background-image:
linear-gradient(-90deg,...接頭辞つきの宣言の後に、接頭辞なしのlinear-gradient()が書かれています。記事中の画像から、このコードは垂直方向のグラデーションを意図したものと分かります。
しかし、degの解釈の変更によって-90degは左方向のグラデーションとして解釈されるようになりました。接頭辞なしの宣言を最後に書くことは通常よいプラクティスであるのですが、linear-gradient()ではdegの解釈が変わってしまったので、degを利用する場合は180degと角度を書き換える必要があります。
/* Opera v11.10+ */
background-image:
-o-linear-gradient(-90deg,...
background-image:
linear-gradient(180deg,...今回はたまたまの記事を見つけたこともありCSS3 Mobile Packを取り上げましたが、これはこの拡張パックに限った話ではないでしょう。グラデーションのコードを生成するWebアプリはいくつか公開されていますし、SassやLESSなどでMixinを定義している場合などにも、degの扱いに注意する必要があります。
2011年11月16日
ベンダー接頭辞は有害か
MozillaでHTML5パーサなどの開発に関わっているHenri Sivonenが、自身のWebサイトにベンダー接頭辞はWebにとって有害であるいう考察記事を公開しています。
ベンダー接頭辞はWeb開発者にも、利用者にも、そしてブラウザの競争においても有害であり、ベンダーは接頭辞つきの実装をやめるべきだという指摘を、様々な点から分析し考察しています。
利用者やブラウザの競争においても有害？
CSSのベンダー接頭辞に関する「手間」については、CSS3の機能が広く利用されているいま、説明する必要はあまりないかと思われます。
最近ではAPI仕様についても、ベンダー接頭辞をつけた実装が行われるようになりました。標準の実装において慣習となりつつあるわけです。しかし、利用者やブラウザの競争においても有害となるのはなぜでしょうか。
この背景には、とくにWebKitが挙げられるのではと考えられます。WebKitには多くの大企業が開発に関わるようになり、幅広い機能が短い期間の間に動くレベルまで実装されるようになりました。こうした新しい機能については、かなり多くのものがWebKitの接頭辞つきで実装されています。
新しい機能の多くは、短いリリースサイクルを持つChromeでいち早く利用可能になります。また、こうした新しい機能を紹介する目的で作られたデモの多くは、WebKitの接頭辞のみを利用しているため、たとえ同じ機能が別のブラウザで後に実装されたとしても、動作しません。
デモだけで済めばよいですが、モバイルでのWebKitの寡占状態によって、WebKit接頭辞つきの機能に依存したWebコンテンツは増加する一方です。その機能がなければ動かないコンテンツも増えています。
WebKitだけに限定される話ではありませんし、接頭辞つきプロパティを使うべきではないと言いたいわけではありませんが、最低限の対応は心がけたいところです。
HTML5では推奨されないベンダー接頭辞
さて、こうした接頭辞つき機能への依存もあり、他のベンダーの接頭辞も解釈するよう求めるバグ報告なども上がるケースがあります。接頭辞の導入された目的を考えると、これは受け入れがたいことです。
しかし、広く使われている機能であれば、ベンダー固有であるにせよデファクト標準に近い性質を持ちます。非標準であった機能の標準化を数多く行なっているのが、HTML5仕様です。
実は、ベンダー接頭辞の仕組みはHTML5仕様にも記されています。拡張性について書かれたセクションに、ベンダー固有拡張の属性に関して定義があります。
固有拡張の属性は、x-attributenameという形式で、先頭にx-がつきます。GoogleがChromeに実装した音声入力機能などがこの仕組みを採用し、<input x-webkit-speech>として実装されています。
ただし、HTML5仕様では「この仕様に対し、ベンダー固有のプロプライエタリな拡張は強く推奨しない」と但し書きがついた上で、拡張に関する定義がなされています。ベンダー固有拡張は詳細な挙動が仕様として公開されないこともあり、HTML5の目的である相互運用性の確保に相反することが理由として考えられます。
また、そうした拡張に依存したコンテンツが増えてしまうと、HTML5の方針である「既存コンテンツのサポート」「車輪の再発明を避ける」に従い、接頭辞つきの機能をそのまま取り入れる可能性も否定できないですから、それを避けたいとも考えられます。
CSS WGのco-chairも反対が
CSS WGにおいても、ベンダー接頭辞に反対しているメンバーが居ます。なんとWGのco-chairであるDaniel Glazmanがその一人です。先日もベンダー接頭辞に関するエントリを自身のBlogに投稿しています。
Danielは次のような提案をしています。
- 試験的な機能は安定するまでWebコンテンツではデフォルトで無効とする（アプリケーションレベルでは有効）
- デバッグメニューから有効にすることで利用可能とする
- 試験的な機能を有効にするか利用者に尋ねる機能をAPIとして用意する（有効範囲はドメイン単位）
- ブラウザーがバージョンアップしたら、いま一度無効化される
議論を広げるためにすこし大きく表現したようですが、試験的な機能の有効化については、冒頭に取り上げたHenriの記事でも「開発版に留めるべき」といった見解を示しています。
ベンダー接頭辞とつき合うにあたり
ベンダー接頭辞に関する問題提起は定期的に盛り上がりを見せますが、大きな動きになることはありません。また、ベンダー接頭辞がなくなったとしても、接頭辞つき機能との互換性を考えると、しばらくはベンダー接頭辞とつき合う必要があるでしょう。
CSSについては、昨年投稿した 「ベンダー接頭辞は使ってもよいか」というエントリで、次のような方針を紹介しています。
- 接頭辞つきプロパティを書くのであれば、正式なプロパティも含める
- 仕様の安定度や実装状況をみて、新しい機能に大きく依存しないように使う
APIに関しても、同じように考えることができるでしょう。
しかしながら、「正式なプロパティを含める」という点に関しては、うまくいかないこともあります。この点については、別に取り上げたいと思います。
2011年11月10日
2011年10月のW3C
CSS3 Fonts更新
10月4付で、CSS WGから新しいCSS3 Fontsモジュールの草案が公開されました。
フォントの読み込みは基本的に同一originからという規定がat-riskとされたほか、font-variantの例が追加されるなどの変更が加わっています。
Web Testing Activity
10月13日に、Web Testing Activityの設立がアナウンスされました。
Web Testing Activityは、Web Testing IGとBrowser Testing and Tools WGの2グループから構成されます。
Web Testing IGは、Web標準のテストフレームワーク開発やテストケース・テストスイートの管理手法などについて活動を行うグループです。Browser Testing and Tools WGは、ブラウザの開発者ツールで広く使われるようになったconsoleオブジェクトの標準化や、テストにおいてクリックや文字入力など利用者の行動をシミュレートするWeb Driver APIという仕様を策定予定です。
Web Testing Activityについては、18日発売のWeb Designingのコラム「Web Standards Plus」でも取り上げております。
WebAppsから3仕様更新
10月20日付で、WebApps WGから新しいFile API, Server-Sent Events, HTML5 Web Messaging仕様の草案が公開されました。
File APIはほぼ1年ぶりの更新ということもあり、数多くの変更が加わったようです。
Server-Sent EventsやHTML5 Web Messagingでは、DOM4で導入されたイベントコンストラクタへの対応などが行われています。Last Callとして公開されていましたが、草案に差し戻されています。
Web StorageのLast Call
10月25日付で、WebApps WGよりWeb Storageの新しい草案がLast Callとして公開されました。
エラーの名前がSECURITY_ERRからSecurityErrorに変更されており、またDOM4のイベントコンストラクタにも対応しました。
Touch Events version 1のLast Call
10月27日付で、WebEvents WGよりTouch Events version 1の新しい草案がLast Callとして公開されました。