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) 時点では未サポートです。
]]>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 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には他にも画像の一部を指定するフラグメントなども定義されていますが、いまのところ実装はありません。
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仕様と統合されることもあり、仕様書に注釈が加わっています。
12月8日付で、WebSocket APIとWeb Storageが勧告候補として公開されました。
WebSocketのプロトコル仕様については、昨年末にRFC 6455として発行されています。
12月15日付で、Web Events WGからTouch Events version 1仕様の勧告候補が公開されました。
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を参考に作られた新しい仕様とのことです。
]]>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モジュールが勧告されました。
また、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 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をよろしくお願いいたします。
]]>10/31から11/4まで、米国カリフォルニア州のサンタクララでW3Cの総会TPAC 2011が開催されました。
週半ばのTechnical Plenaryについては、今月発売のWeb Designingの連載で取り上げております。
TPACから2週間後の11月15日と16日には、ワシントン州シアトルでW3Cが主催する初めてのカンファレンスである「W3Conf」が開催されました。
セッションの動画も公開されています。Web標準によるデータ視覚化やブラウザ開発者のパネルディスカッションなど、面白いセッションが多数あったようです。
11月29日付で、CSS WGからCSS3の4モジュールが更新されました。
Regionsモジュールについてはスタイルシートが随分違うものになっていますが、これは先日CSS WGに加入したBen Schwarzが他のCSS WGのメンバーと共に実験中の新しいスタイルシートです。
Benは開発者版のWHATWG HTML仕様のスタイルも手がけています。
11月29日付で、Web Application Security WGからContent Security Policyの草案が公開されました。
最初の公開草案ではありますが、GeckoやWebKitが試験的に実装を進めており、Chromeでは内部で利用しています。拡張にも適用するという話があるようです。
]]>これは、標準化された（接頭辞のない）機能の構文もしくは解釈が変わってしまう場合を意図しています。そして、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の扱いに注意する必要があります。
ベンダー接頭辞はWeb開発者にも、利用者にも、そしてブラウザの競争においても有害であり、ベンダーは接頭辞つきの実装をやめるべきだという指摘を、様々な点から分析し考察しています。
CSSのベンダー接頭辞に関する「手間」については、CSS3の機能が広く利用されているいま、説明する必要はあまりないかと思われます。
最近ではAPI仕様についても、ベンダー接頭辞をつけた実装が行われるようになりました。標準の実装において慣習となりつつあるわけです。しかし、利用者やブラウザの競争においても有害となるのはなぜでしょうか。
この背景には、とくにWebKitが挙げられるのではと考えられます。WebKitには多くの大企業が開発に関わるようになり、幅広い機能が短い期間の間に動くレベルまで実装されるようになりました。こうした新しい機能については、かなり多くのものがWebKitの接頭辞つきで実装されています。
新しい機能の多くは、短いリリースサイクルを持つChromeでいち早く利用可能になります。また、こうした新しい機能を紹介する目的で作られたデモの多くは、WebKitの接頭辞のみを利用しているため、たとえ同じ機能が別のブラウザで後に実装されたとしても、動作しません。
デモだけで済めばよいですが、モバイルでのWebKitの寡占状態によって、WebKit接頭辞つきの機能に依存したWebコンテンツは増加する一方です。その機能がなければ動かないコンテンツも増えています。
WebKitだけに限定される話ではありませんし、接頭辞つきプロパティを使うべきではないと言いたいわけではありませんが、最低限の対応は心がけたいところです。
さて、こうした接頭辞つき機能への依存もあり、他のベンダーの接頭辞も解釈するよう求めるバグ報告なども上がるケースがあります。接頭辞の導入された目的を考えると、これは受け入れがたいことです。
しかし、広く使われている機能であれば、ベンダー固有であるにせよデファクト標準に近い性質を持ちます。非標準であった機能の標準化を数多く行なっているのが、HTML5仕様です。
実は、ベンダー接頭辞の仕組みはHTML5仕様にも記されています。拡張性について書かれたセクションに、ベンダー固有拡張の属性に関して定義があります。
固有拡張の属性は、x-attributenameという形式で、先頭にx-がつきます。GoogleがChromeに実装した音声入力機能などがこの仕組みを採用し、<input x-webkit-speech>として実装されています。
ただし、HTML5仕様では「この仕様に対し、ベンダー固有のプロプライエタリな拡張は強く推奨しない」と但し書きがついた上で、拡張に関する定義がなされています。ベンダー固有拡張は詳細な挙動が仕様として公開されないこともあり、HTML5の目的である相互運用性の確保に相反することが理由として考えられます。
また、そうした拡張に依存したコンテンツが増えてしまうと、HTML5の方針である「既存コンテンツのサポート」「車輪の再発明を避ける」に従い、接頭辞つきの機能をそのまま取り入れる可能性も否定できないですから、それを避けたいとも考えられます。
CSS WGにおいても、ベンダー接頭辞に反対しているメンバーが居ます。なんとWGのco-chairであるDaniel Glazmanがその一人です。先日もベンダー接頭辞に関するエントリを自身のBlogに投稿しています。
Danielは次のような提案をしています。
議論を広げるためにすこし大きく表現したようですが、試験的な機能の有効化については、冒頭に取り上げたHenriの記事でも「開発版に留めるべき」といった見解を示しています。
ベンダー接頭辞に関する問題提起は定期的に盛り上がりを見せますが、大きな動きになることはありません。また、ベンダー接頭辞がなくなったとしても、接頭辞つき機能との互換性を考えると、しばらくはベンダー接頭辞とつき合う必要があるでしょう。
CSSについては、昨年投稿した 「ベンダー接頭辞は使ってもよいか」というエントリで、次のような方針を紹介しています。
- 接頭辞つきプロパティを書くのであれば、正式なプロパティも含める
- 仕様の安定度や実装状況をみて、新しい機能に大きく依存しないように使う
APIに関しても、同じように考えることができるでしょう。
しかしながら、「正式なプロパティを含める」という点に関しては、うまくいかないこともあります。この点については、別に取り上げたいと思います。
]]>10月4付で、CSS WGから新しいCSS3 Fontsモジュールの草案が公開されました。
フォントの読み込みは基本的に同一originからという規定がat-riskとされたほか、font-variantの例が追加されるなどの変更が加わっています。
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」でも取り上げております。
10月20日付で、WebApps WGから新しいFile API, Server-Sent Events, HTML5 Web Messaging仕様の草案が公開されました。
File APIはほぼ1年ぶりの更新ということもあり、数多くの変更が加わったようです。
Server-Sent EventsやHTML5 Web Messagingでは、DOM4で導入されたイベントコンストラクタへの対応などが行われています。Last Callとして公開されていましたが、草案に差し戻されています。
10月25日付で、WebApps WGよりWeb Storageの新しい草案がLast Callとして公開されました。
エラーの名前がSECURITY_ERRからSecurityErrorに変更されており、またDOM4のイベントコンストラクタにも対応しました。
10月27日付で、WebEvents WGよりTouch Events version 1の新しい草案がLast Callとして公開されました。
]]>jQuery Standards Teamは、標準化団体やベンダーに対し、Web開発者という立場から働きかけていくチームです。Web標準やブラウザ相互運用性の重要性は高まるばかりですが、Web開発者コミュニティと、標準化団体・ベンダーとの連携はそこまでうまくいっていないという問題意識から生まれたようです。
ブログの中では、標準化団体の持つ標準化プロセスの難しさ、長くなりがちな議論に割ける時間が開発者にない、ブラウザ開発者が活発に議論するメーリングリストでは技術への深い理解が必要という雰囲気になっているといったことが課題として挙げられています。
jQuery Standards Teamは次のゴールを掲げ、関係するコミュニティに働きかけていくようです。
Standards TeamはGoogleグループでのディスカッションやIRC上の定例ミーティングを行うようです。仕様に関する細かな指摘は、GitHubのIssueシステムを使うようで、すでにいくつかのIssueが登録されています。
]]>しかし先週、Mark Pilgrimが、自身の運営していたWebサイトや、各種Webサービス上のアカウントを削除し、オンライン上での活動をストップしました。これにより、http://diveintohtml5.org/ 上に公開されていたDive Into HTML5が消失しています。
幸いなことに、Dive Into HTML5はCreative Commonsのライセンスのもと公開されており、GitHub上にレポジトリもあったことから、有志が引継ぎ diveintohtml5.info 上に新しく公開されました。
diveintohtml5.infoでは、ただの修正だけではなく、HTML5をとりまく状況の変化をふまえた更新も行なっていくとしています。一部古い内容も出てきていますから、今後の更新に期待したいです。
]]>9月15日付で、WebApps WGからDOM4の草案が公開されました。
DOM4はこれまでWeb DOM CoreやDOM Coreと呼ばれていた仕様です。これまでのDOM仕様はDOM Level 3などレベルが付けられていましたが、DOM Coreにはそれがなく、混乱するといったコメントが寄せられたことから、名称がふたたび変更されました。
9月15日付で、CSS WGからCSS Device Adaptationの草案が公開されました。
Device Adaptationはスマートフォン用サイト制作で欠かせない "viewport" をCSSから指定するための仕組みです。Operaによって提案され、すでにOpera Mobileで実装が進められています。
また、meta要素による指定の処理についても定義されています。
9月22日付で、WebApps WGから、Progress Eventsの勧告候補が公開されました。
9月29日付で、WebApps WGから、WebSocket APIの草案がLast Callとして公開されました。
9月29日付で、Selectors Level 3 (CSS3セレクタ)仕様と、CSS3の名前空間モジュールがW3C勧告として公開されました。
公開している日本語訳も勧告をふまえたものに更新しました。
CSS3セレクタ勧告と同日付で、CSS WGからSelectors Level 4という、新しいレベルのセレクタ仕様の草案が公開されました。
まだ初期段階にあることもあり、提案されている機能が実装されるかどうかも分かりませんが、要素の「親」を選択できる仕組みなど、待ち望まれていたセレクタなどが現時点で提案されています。
新しい機能についてまとめているノートもありますので、ご一読ください。
]]>9月1日付で、CSS WGから以下の草案が公開されました。
新しく開されたConditional Rulesは、UAのサポート状況や文書URLをもとに、CSSで条件分岐を行う仕組みを提供します。
CSSは知らないものは無視するという仕様があり、それをフォールバックとして利用できますが、Grid LayoutやCSS Regionsなどの新しいレイアウト仕様や、CSS Animationsなど実装のまだ少ない仕様では、うまくフォールバックさせられない懸念があります。これらに対し、Conditional Rulesでは@supportsというブロックを導入し、サポート状況による条件分岐を提案しています。
文書のアドレスでスタイルを切り分ける仕組みは、Mozillaの@-moz-documentの仕組みを拡張したものです。ユーザースタイルシートで特に便利でしょうか。
9月6日付で、CSS WGよりCSS3 Values & Unitsモジュールの新しい草案が公開されました。
前の草案が5年前のものと古く、CSS 2.1の勧告もあったことから、再構成が行われたとのことです。
9月7日付で、Web Application Security Working Groupの設立がアナウンスされました。
Webアプリケーション関連技術にはいくつかのセキュリティポリシーがありますが、それらに仕様がないため相互運用性を欠くという問題意識のもと設立されたようです。
活動内容としては、セキュリティポリシーに関する仕様を策定するようです。これまでWebApps WGで策定されていたCORSなどをベースにしたSecure Cross-Domain Resource Sharingという仕様や、Mozillaが提案しGeckoに実装し、後にWebKitも追従したContent Security Policy (CSP)という仕様の規格化は、ベースがすでに存在し、実装も進んでいます。
そしてクロスドメインのフレーム間でのやりとりを安全に行うSecure Cross-Domain Framingについては、CSP, iframeのsandbox属性、X-Frame-Optionsヘッダなどいくつかの仕組みがあるので、CSPをベースに、統一要件を定めていくやり方をとるようです。IETFのWeb Application Security Working Groupとも強調していくようです。
9月8日付で、CSS WGから新しいCSS3 Image Values & Replaced Contentモジュールの草案が公開されました。
9月8日付で、Tracking Protection Working Groupの設立がアナウンスされました。
Tracking Protection WGは、インターネット上で利用者の行動を追跡するものについて、ユーザーの意志を示す仕組みを定義し、プライバシーやセキュリティを向上させることを目的としています。
昨年終わりにFTCのレポートで"Do Not Track"という仕組みの提案を行なってから、ブラウザやコンテンツ提供者がどのような仕組みを実装すればよいのかという議論が行われていました。W3Cは4月にトラッキング防止に関するワークショップを開催しており、そこでの議論をもとに今回のWGの発足に至ったようです。
9月13日付で、Web Events WGからTouch Events version 1の草案がLast Callとして公開されました。
]]>Acid3の改訂はこれが初めてではありません。テスト自体にバグがあったケースや、:visited擬似クラスのプライバシー対応に追従するなど、過去にも数度変更がされています。しかし、今回の変更ではこれまで100点に数点満たなかったIE9とFirefoxでスコアが100点になったこともあり、受け取られ方が多少異なっているようです。
今回の改訂は、策定中のDOM4で提案されている変更と、Acid3で使われているいくつかのサブテストが衝突することがわかり、テストしている項目を見直すことが良いと判断された結果行われました。その経過で、複数のブラウザで実装される見込みのない機能もコメントアウトされました。結果として、IE9やFirefoxでスコアが上昇しています。
Acid3は「次世代Web標準」への対応度をはかるひとつの指標とみられる事が多いように感じますが、これだけで対応度を図ることはできません。Acid3は包括的なテストスイートではなく、むしろショーケースのようなものです。スコアが100点に数点満たないからといって「遅れている」とも言えないのです。
また、100点をとったからといって、準拠度が高いとは必ずしも言えません。今回コメントアウトされた「すべてには実装見込みのない」SVG Fontsに関するテストは、WebKitやOperaでパスしていたものの、その実装はAcid3をパスするための最低限な実装だったという指摘があります。不十分な実装では使いたい機能が使えないということも起こりうるわけです。
Acid3が作られた目的は、当時「安定している」と考えられた仕様（CRが中心）のうち、実装が進んでおらず開発者が使えない機能をテストとして選ぶことで、相互運用性を向上させようとするものでした。そういった目的をもつテストが、相互運用性やプラットフォームの漸進を妨げてしまうのは本末転倒ですから、仕様や実装だけでなく、テストの改訂にも意義があるわけです。
]]>6月に公開されたPlatform PreviewでもHTML5フォームやFile APIなど機能追加が多数ありましたが、今回公開されたIE10 Platform Previewでも、HTML5関連技術やCSSのサポートがさらに進んでいます。
CSSでは、CSS 3D Transforms, CSS Transitions, CSS Animations, CSS Regionsが新たにサポートされました。Transitionsは他のブラウザで早く実装されたこともあり遅れた印象もありますが、Animationsや3D TransformsはFirefoxが最近実装したくらいで、RegionsについてはAdobeが今年提案したとても新しい仕様です。MicrosoftのWeb技術へのさらなる注力がうかがえます。
HTML5関連では、IndexedDB, WebSocket, Application Cache, History APIなど「HTML5らしい」機能がサポートされているようです。Windows 8ではWeb技術でアプリケーションが開発可能になりますし、オフラインでも動作するアプリケーション向けの機能が必要だったのでしょう。
]]>7月12日付で、CSS WGよりCSS Image Values and Replaced Content Module Level 3の新しい草案が公開されました。
CSSグラデーションでの角度の解釈で紹介した、degの扱いが変更されています（方位角が採用されました）。
Image Valuesは以降も活発に動いており、変更を反映した新しい草案の公開も計画されているようです。
7月21日付で、WebApps WGからFrom-Origin Headerという草案が公開されました。
Webフォントなど利用許諾が求められることの多いコンテンツや、ビデオのように大容量のため埋め込みを許可すると帯域負荷が懸念されるコンテンツがあります。埋め込みの制御にはRefererヘッダのチェックが使われることが多いですが、コンテンツのURLに直接アクセスした場合、内容が見られなくなるケースも有り不都合でした。
From-Origin Headerは、は埋め込みを許可するoriginを指定するFrom-Originレスポンスヘッダを定義します。
7月21日付で、WebPerf WGからPage Visibilityの草案が公開されました。
Page Visibilityはページがバックグラウンドで表示されているか、そうでないかを検出するdocument.hiddenプロパティなどを定義しています。すでにChromeとIE10 PP2で実装されており、IEBlogでも取り上げられています。
8月16日に、SVG 1.1 Second Editionが勧告されました。
SVG WGは現在、次期バージョンのSVG 2.0について要件やユースケースを検討しているようです。
]]>Web標準カリキュラムは、それまで使われていたWeb制作・Web開発に関する教材がWeb標準に基づいた古いもので、実践的なことを学べないという問題がきっかけとなり誕生しました。利用しやすいように教材を無料でオープンに公開したことには一定の成果があげられたようで、多くの学校や大学、企業内での利用が始まっているようです。
この試みを更に広げ、またより多くのフィードバックを得られるように、Dev.OperaからW3C Wikiへの移動が決定されました。英語版のコンテンツはすでにW3C Wikiに移動しており、W3Cのアカウントを申請すれば誰でも編集可能となっています。
さて、Web標準カリキュラムにはミツエーリンクスも翻訳というかたちで協力しており、現在までに8本の訳を寄稿しています。
カリキュラムには日本語の他にもいくつか翻訳があるのですが、それらについてはW3C Wikiの多言語対応などを調査している段階のようです。解決次第、これらも移動されるのではないかと思います。
]]>