10月26日から31日にかけて、Santa Claraで開催された「TPAC 2014」。本レポートでは、TPACで行われたWebRTCワーキンググループについてレポートします。

TPACとは?

TPACとは、Webの標準化団体であるW3C(World Wide Web Consortium)が開催する1週間のイベントのことです。様々な国、様々な企業からメンバーが集まり、現在のWeb標準・将来的なWebの機能(例えば、cryptoやaudio)について議論します。

本記事では、WebRTC WG(ワーキンググループ)で議論された注目の話題をレポートします。WebRTC WGには、WebRTC(※)をより安心・安全に、一方で開発者には強力な柔軟性を与えたいと考えるメンバーが集まっています。

※ WebRTCとは？： WebRTC(Web Real Time Communication)とは、サーバを経由せずにブラウザ同士が通信する技術のことで、ブラウザから音声や映像を取得するようなAPIを含んでいます。これらのAPIにより、プラグインなしで、お好きな複数のデバイス間で音声・映像通信を実現できます。WebRTC自体の技術的な内容については、本サイトのWebRTCを使ってみよう！をご覧ください。

Media Capture タスクフォース

Media Captureタスクフォースは、Device APIsとWebRTC WGsの両者が参加するタスクフォースです。音声・映像をデバイスから取得するgetUserMedia APIを担当しています。今年のTACでは、いかに開発者に簡単にAPIを利用させるか、また、ラストコール(勧告候補の前にコメントや提案を受け付けるタイミングです)の準備ができた、という点について議論が集中しました。

Promises

MozillaのJan-Ivar Bruaroeyが推進するPromiseが議論が白熱したトピックです。 具体的には、getUserMediaを取り巻くイベント(例えばMedia Stream Track onended イベント)について、Promiseを利用する案が出ています。Promiseによってコードを綺麗に書くだけでなく、より詳細なエラー情報を開発者が利用可能になると、彼は述べています。

対して、RFTMの創設者であるEric Rescorlaは「不必要に複雑で、開発者が悪いコードを書いてしまう可能性がある」と述べ、強く反対しました。また、Promiseは複数回発生ようなイベントを扱えない、という問題があるとも述べています。 結局、MediaStreamTrack onendedイベントのようなイベントについては、reason codeを付けるのが最適という妥協点に達しました。getUserMediaは、メディアキャプチャに関するAPIの中でPromiseを使う唯一のAPIとなります。

出力デバイスの選択

WebRTCのアプリ開発の上で、開発者が直面する問題の1つに、音をスピーカから出力するか・ヘッドセットから出力するか、指定できないという問題があります。残念なことに、自由に出力デバイスを選択できるようにしてしまうと、セキュリティ上の懸念（例えば、悪意のあるサイトが広告を音声として流すようにな懸念）が出てきます。

GoogleのJustin Ubertiは、デバイスグループを定義するという、シンプルな解決方法を提案しました。 もし、入力と出力のデバイスが同一であるなら、同じデバイスグループに属するという考え方です。例えば、ヘッドセットや会議室のマイクが典型になります。本機能の前提として、もしユーザが入力デバイスに制御権を与えるなら、出力デバイスにも同じ権利が与えられてもよい、という考えがあります。本提案は歓迎されましたが、参加者はさらなる詳細(permissionの継続や仮のデバイス利用)について要望しました。

WebRTCワーキンググループ

WebRTC WGで議論された主なトピックは、オブジェクトを利用してWebRTC APIをモダンなものにする、ということ。マイクロソフトが推進するORTC(Object RTC)は明に言及されていないものの、明らかに多くの提案はORTCが推進力になっているものでした。

RTPSender と RTPReceiver

GoogleのJustinが、WebRTCでSDPを使うための新たな方法である、RTPSenderとRTPReceiverを提案しました。 現時点でストリームのビットレートを変更するためには、SDPのプレインテキストを書き換える必要があり、かなり大変です。また、SDPを見なければ、セッションで使われている最大のビットレートのような情報を取得できません。 Justinの提案は、これらの問題を解決するための第一歩になります。

この提案の中で最も受け入れられた部分は、RTCPeerConnectionオブジェクトの扱いにおいて、ストリームベースからトラックベース(RTCSender/Receiverオブジェクトにトラックを結びつける方法)へ、メディアを扱う方法を変えていくといった部分でした。

つまり、全てのトラックがRTCSenderオブジェクトを送り、全てのトラックがRTCReceiverオブジェクトを受け取ります。このようにすることで、同じトラックを複数の箇所で複製・利用できるようになり、ビットレート等もトラックごとに操作できるようになります。

また、提案の中には、ローカル/リモート候補、リモートのDTLS証明書、ユーザに対するビットレートのようなエンコードパラメタに挙げられる、トランスポートに関するデータを公開する方法も含まれています。全体として、この提案は良いと考えられたものの、エラーに対する操作やWebRTC 1.0に含める最小の仕様については、さらなる議論が必要となっています。

最後に、Justinはトラックを直接編集可能にする、という提案をしています。この提案によりモバイル機器の全面と背面のカメラを切り替えるときに発生する問題が解消できます（現在は、古いトラックを削除して、新しいトラックを追加し、再度ネゴシエーションする方法で対応しないといけません）。提案されたAPIであれば、トラックの内容を変更するだけで済み、再度ネゴシエーションする必要がありません。

またまたPromises

Jan-Ivarが再度登壇し、WebRTCについてもPromiseを利用するという、提案をしています。Media Captureセッションから受け取るフィードバックを利用して、promisesの実験的な利用を削減し、ICE・ピアコネクション・コールの発信のフローの中でPromiseを利用する教科書的な利用方法を提案しています。

Eric Rescorlaはまだ納得していなかったようなものの、エラー処理の簡単さに対するJan-Ivarのアピールが残りのグループの同意を勝ち取り、promiseが含められる点が合意され、既存のコールバックは非推奨となりました。

DTLS証明書

DTLS証明書は、ピア自身が本人であることを証明するために利用できます。マイクロソフトのMartin Thompsonは、Web Crypto APIを利用した、DTLS証明書を生成する新たなAPIを提案しました。

これにより、ドメイン毎・ユーザ毎に同じDTLS証明書を再利用できるようになりますし、証明書を毎回作成し直すことも可能になります。ただし残念なことに、Elliptic curve cryptography (日本語リンク)がWeb Crypto APIで動作するか誰も知らなかったので、明らかになるまで延期するのがよいという結論になりました。

Stats API (統計API)

Callstats.ioのファウンダであるVarun Singhは、新しいWebRTC stats APIドラフトの詳細について、WGの意見を募集しました。詳細とは例えば、変数名、コード名のフォーマット、bytesSent/Receivedがヘッダに計算結果を加えるべきか・それとも単にペイロードにすべきか、等になります。

Bugs, bugs and more bugs!

翌朝2日目の8:30という早朝から、bugzillaに出されているWebRTC関連のバグについて議論をするために、グループが集まりました。グループはそれぞれのバグについてのアクションを決めるために、3時間以上を費やしました。グループの参加者は徐々に減っていき、最後にはアクションを決定できなくなってしまいました。（主要メンバーが既に帰ってしまった！）

結論

2日間に渡り続いたTPAC 2014のWebRTC WGも終わりです。WebRTC劇場へPromiseが追加されますし、策定中の大きな仕様変更もまだあります。今後数年間で追加されるである新機能が楽しみですね！

(本記事は、飯田 アレン真人が英語で執筆し、編集部の岩瀬 義昌により翻訳されました)

Extensible Web Summitとは

2014年9月11日にドイツ・ベルリンにて、Extensible Web Summitが開催されました。本イベントは、Exntensible Web Manifestoに興味を持つ、Web開発者・ブラウザベンダ・W3Cメンバ等が一堂に会し、未来のWebについてディスカッションを行うというイベントです。

イベント自体は、アンカンファレンススタイルで進められるため、会議の前に議題は決まっていません。会議当日の前半のセッションにて、ライトニングトークが5本あり、その内容を参考にしつつ、参加者自らがトピックが設定していきます。設定されたトピックに沿って、本イベントでは3つのブレイクアウトセッションが平行して開催されます。そして、各参加者は自分の興味のあるセッションに参加します。

本記事では、Extensible Web Summit Berlinでの設定されたトピック、およびトピックの中から特にExtensible Web に関係する議論が行われたトピック2つをピックアップし、その議論模様を紹介いたします。世界中のWeb関係者が、どのような点に興味を持っているか参考になるはずです。

当日決定されたトピック

当日決定されたトピックは以下の通りとなりました。

当日の議論の議事録は、こちらで公開されています。各ディスカッショントピック議事録へのリンクもありますので、詳細確認されたい方は、是非チェックしてみてください。

ディスカッショントピックは、Extensible Webに関するものだけではなく、「このトピックについて、W3Cメンバーと開発者との間で議論したい！」というものも多く存在しました（例えば、WebRTCのセッションでは、『iOSってWebRTCサポートされないの？』『こればっかりは分かんないね〜』といった話題も）。

本稿では、各種トピックの中から特に Extensible Web に関わりの深い二つのトピック（上表にて、強調表示）の議論模様を紹介いたします。

セッション紹介：Extensible Web, Huh?

本セッションのみ、全員参加のセッションとなりました。本セッションでは、『Extensible Webって、実際どうなの？』というテーマで、参加者がディスカッションが行われました。

セッションの進行形式としては、質問/疑問を持っている参加者がそれを発言し、他の参加者が回答する流れとなります。ここでは、主な議論事項を紹介いたします。（議事録は、こちら。要旨理解を助けるため一部、議論の順番を組み直して記載しています。）

まず最初の質問として投げかけられたのが、「Exntensible Webでは、低レベルのAPIを公開することになるが、Webのセキュリティモデルに適しているのか？」という点でした。これに対しては、

同様の課題は、Service WorkerやCORSにもある。

や、

もしExtensible Webを実現するためのテンプレート/パターンのようなものがあれば、セキュリティモデルに対する1つの解になるのではないか。

という回答が上がっておりました。

また、Extensible Webでは、世界中のWeb開発者が独自のWeb拡張を進めることが出来ます。このとき、 「多くの開発者が同じ目的を持って、Webの拡張に取り組んだ場合、どうやってまとめていくのか？複数のWebの世界を作ってしまうのではないか？」 という懸念があります。これらに対しては、少しジョークのニュアンスを含みますが、

READMEが最も簡単で理解しやすいものが、生き残るのではないか。

という回答、また世界中の開発者を巻き込むという観点から

技術に取り組むなら、英語が必要だ。優れなコントリビュータの中でも、英語を使えない人をほとんど知らない。 また、仕様に使われる英語をもっと簡単にする必要もある。

という回答がありました。

その他にも、「必要以上に低レベルなAPIを公開することにより、パフォーマンスに影響が出てしまうのではないか？」という懸念も出てきていました。この懸念に対しては、

JavaScriptのパフォーマンスはそこまで悪くない。

といった意見や、

ブラウザネイティブの機能を利用した方が、polyfillを使うよりもパフォーマンスが良いのは理にかなっている。polyfillを毎回ダウンロードする必要もない。

のように、ネイティブの機能のほうがパフォーマンスは良くなる、といった回答も挙がっておりました。

ここまで記載してきたのは、技術的な側面からの質疑でしたが、その他の側面からのコメントとして、

Extensible Webでは、低レベルなAPIを公開する等の技術的な側面はもちろんだが、社会的な側面も必要となる。社会的な側面とはつまり、世界中の開発者をどうやって巻き込んでいくか？ということだ。

というもっともな疑問も挙がっています。本疑問については、参加者の多くが重要と考えており、以下に続く別セッションへ切り出しとなっております。

セッション紹介：New way to do specs; how to connect specs and developers, next generation standardization, etc…

(本セッションレポートは、小松 が執筆しました。要旨理解を助けるため、議論の順番を組み直して記載しています）

本セッションでは、『開発者が標準化プロセスにもっと関われるようになるためには、どのような取り組みが必要か？』についてディスカッションが行われました。W3C HTML5仕様のメインエディター、Robin Berjon 氏がセッションモデレーターを務めました。（議事録は、こちら）

本セッションのポイントは、仕様エディターと開発者との間の連携やコミュニケーションの実効性を上げていくこと。理由は、仕様と実際のニーズとの乖離を防ぐためです。例えば、この手の議論で失敗例としてよく出てくる AppCache ですが、

「AppCacheの失敗は、開発者が望んでいる機能を仕様化しなかったこと」 「AppCacheの考え方（オフラインWeb）自体は、間違っていない。仕様化の進め方が間違っていた」

という分析を行ったとのこと。これを受けて、Indexed Database APIの仕様化にあたっては、エディターとデータベース技術者とで連携したことを紹介し、W3Cの仕様化に普段は関わっていない、実際の利用者から密にフィードバックを得ることが、良い仕様を作るためには重要との考えが示されました。

開発者からのフィードバック手段として現在良く利用されているのが、BlogやSNSへの書き込み。これらのフィードバックは、エディターにとって非常に重要な情報ですが、

「それらを追いかけるのは、大変」

このため、Specifictionというフォーラムを開設しており、仕様へのフィードバックは、是非ここに書き込んでいって欲しいとのことでした。

また、このようなオープンな標準化プロセスを進めるにあたり、その大枠の考え方を WebPlatform Specs として文書化していることが紹介されました。現状、ポイントとしては

• Forkable
• Hackable
• Thoughtful
• Royalty-Free
• Software Practices
• Tested

が挙げられています。最初の二つは、GitHubのイメージですね（参考まで、W3Cではないですが、HTTP/2はGitHub で、オープンに管理されています）。当日のディスカッションでは、

Polyfillの開発やサンプルコードによるユースケースの提示は仕様化を進めるのに有効

との発言もあり、Forkable, Hackableは大変重要な概念と感じました。

あと、3番目の Thoughtful を補足すると、仕様化にあたって「何をゴールにするか？」のルールを複雑に考えていると、それだけで無駄な時間がとられてしまうので、（アジャイルの考え方で）仕様化も継続的に進められると考え、ゴール設定やルールはシンプルでスマートにしようといったことが述べられています。

ほかには、

開発者は普段別の仕事をしており、仕様化貢献にそこまで時間を割くことはできない

というコメントがあり、これを解決するために仕様を機能分割し、開発者の学習コストを下げる取り組みを行っているといった議論もありました。

まとめ

本記事では、Extensible Web Summit Berlinの議論模様を一部紹介いたしました。前述のように、詳細な議事録は、こちらで公開されています。各ディスカッショントピック議事録へのリンクもありますので、詳細確認されたい方は、是非チェックしてみてください。

W3Cの標準化担当者・Web開発者が支持を表名している、「Extensible Web」という概念をご存知でしょうか？ Extensible Webとは、一言で表すと、標準化組織であるW3Cとブラウザベンダだけでなく、 Web開発者も巻き込んでWebの未来を拡張していこう、という考え方のことです。

本記事では、Extensible Webの登場背景、その内容について紹介いたします。

登場の背景

これまでのWebの新機能は、長い年月をかけてブラウザベンダによって開発されてきました。 そのため、多くの場合、Web開発者がブラウザへフィードバックをするには、 まずブラウザ側の機能実装を待つ必要がありました。

しかし近年、Webの開発者が先導して、ブラウザの新機能へ影響を与えるケースが出てきています。 例えば、querySelector や、Object.observe が具体例です。 これらの例は、以下のフィードバックループによって生まれてきています：

1. Web開発者が自身が必要とするユースケースに沿ってAPI(ライブラリ)をデザインする
2. Web開発者は、他の開発者が作成するAPIと切磋琢磨し、自身のAPIを洗練させていく
3. 洗練されたAPIの中から、ブラウザが実装すべき基本的な機能が抽出される（ブラウザがNativeに実装すればパフォーマンスが向上し、かつライブラリのコードも小さくできる)

Webに本当に必要な機能を生み出すためには、 上記のように、ユースケースに沿った実践的なフィードバックループを回すことが重要です。

既にこのプロセスはWeb標準化にも取り込まれています。例をあげると、

といったところが代表的でしょう。例えば、セレクタを用いたDOM操作は jQuery で実践的に有効性が示され、querySelectorとして標準化されました。これにより、jQueryのパフォーマンスは向上し、さらに Zepto.js のような軽量化ライブラリが登場・・・といったWebの好循環を起こしました。

一方、ユースケースの考慮が浅いまま実装されてしまったAPIは、 結果的に実践にそぐわず、憂き目にあってしまうケースが多々見受けられます。(その代表的な例が、Application Cache です)

これまで説明してきたフィードバックループを、 Webを構成するHTML・CSS・JS等の様々な分野で更に展開できるといいのですが、 現在のWebを取り巻く環境では限界があります。なぜならば、
　「Web開発者が、拡張(extend)できるポイントが少ない」
ためです。 例えば、CSSの構文を拡張するのは、既存の拡張ポイント(API)では困難であるため、 そもそもフィードバックループを回しはじめることが出来ません。

Extensible Web Manifest

もし、Web開発者が拡張できるポイントが多くあれば、 言い換えれば、低レベルのAPIがWeb開発者に公開されるとしたら、どうなるでしょうか？ Web開発者が実際に必要とするケースに沿って、 さらに多くのAPIやライブラリを開発できるようになります。

このような考え方は、Extensible Web Manifestoにまとめられています。

Extensible Web Manifesto

Extensible Web Manifestoでは、ExtensibleなWebのプラットフォームの設計原理として、 以下の点を提言しています：

(Extensible Web Manifestoより抜粋、意訳)

Focus on adding new low-level capabilities to the web platform that are secure and efficient.

安全で効率的な、新たな低レベル機能をWebのプラットフォームに追加する

Expose low-level capabilities that explain existing features, such as HTML and CSS, allowing authors to understand and replicate them.

既存の機能(HTMLやCSS)が、これら低レベル機能によりどのように実装されるかを示すことで、開発者の理解を促進し、複製を可能とする

Develop, describe and test new high-level features in JavaScript, and allow web developers to iterate on them before they become standardized. This creates a virtuous cycle between standards and developers.

新機能の開発、表現、テストをJavascriptで実施し、標準化の前にWeb開発者が参画できるようにする。これにより、Web開発者と標準化担当者の間で素晴らしいサイクルが実現される

Prioritize efforts that follow these recommendations and deprioritize and refocus those which do not.

上記のような提言に沿った取組みの優先度を高くし、そうでないものは優先度を低くするか、もう一度フォーカスを練り直す

原典ではそれぞれの項目について、更に詳細な記載がありますので、興味のある方は参照ください。

Extensible Webの今後

Extensible Web Manifestoは、標準化団体であるW3C・各種ブラウザベンダ(Google, Mozilla等)・著名ライブラリの開発者が支持を表明しており、今後より具体化していくことが期待されます。

具体的な活動の一部として、フェイスツーフェイスのミーティングも既に開催されています。 そこで次回の記事では、2014年9月11日にドイツ ベルリンで開催された Extensible Web Summit の議論模様を紹介いたします。

HTML5を活用したハイブリッドアプリ開発について、Web業界を代表するエキスパート陣が様々な観点からレポートをお届けした「ハイブリットアプリ開発最前線」特集。

最後のレポートは「ハイブリッドアプリ開発、ホントのトコロ」と題し、第48回HTML5とか勉強会「ハイブリッドアプリ開発最新動向」の懇親会で行われたぶっちゃけトーク対談を再現レポートします。

▲登壇者（左から）：株式会社ニューフォリア 畠田喜丈さん、アシアル株式会社 久保田光則さん、AngularJS Japan User Group管理人 金井健一さん、Google Developer Expert（Chrome）吉川徹さん
モデレーター：HTML5 Experts.jp編集長 白石俊平

ハイブリッドアプリ開発にしてよかったことは？

白石：ハイブリッドアプリ開発が注目され出してもう数年が経つんですが、まだくすぶってる感があると思うんです。今日は本音でいろいろ聞けたらと。まず、ハイブリッドアプリ開発にしてよかったと思うことを聞かせてください。

久保田：僕はハイ・フィデリティ（忠実度の高い）なプロトタイプをさくっと作れることですね。アプリの機能は動かないけど、アプリのユーザーインターフェイスやインタラクションがわかる。動きやさわった感じが確かめられるし、アプリケーションの見た目の“ガワ”を作るのが断然早くなります。

これがいいアプリなのか判断に迷うフェーズでも、実際のUIの“ガワ”をがっちり作ることで、高い確度で確かめることができる。それに、クロスデバイス,クロスプラットフォームでがしがし動くので、アプリのUIを確かめるのに役立っています。サービスの受託でやってたときに、お客様にもそんなに早くできるのかって驚かれたこともありますね。

アシアル株式会社　久保田 光則さん

白石：ところで、ここまでクロスプラットフォームでの移植性の話があまり出てきていませんね。ハイブリッドの利点といえばそこだと思っていたので、意外。

畠田：ああ、移植性については、まずありきのつもりで話してました。

久保田：そうですね。ちなみに私はAndroid版は動作が遅いので、先に作るようにしています。前にiOSから作ってAndroidに移植したら遅くて大変な目に合ったことがあって…。

白石：ちなみに最近は、Androidは2.3以上をターゲットにして開発しているんですか？まだ2.2もスコープに入ってるのかな。

畠田：2.2が要求仕様書に入ってるところはまだ多いですね。ただ「端末買い換えが2年だからそこは切り捨てましょう」って、そこは削ってもらうように説得しようと試みますけどね（笑）。

吉川：私は一エンジニアとしての視点から、ハイブリッドアプリでよかった点をお話すると、やはりWebエンジニアがJavaやObjective-Cが書けなくても、AndoroidやiOSアプリの仕事が受けられることですね。最近はWebのコードで書いて、Cordovaでコンパイルすればアプリが作れる。仕事の幅が広がって楽しいです。

──ここで会場から質問が寄せられた

Q.ハイブリッドアプリというと移植性の話もあるけど、クックパッドの事例が成功として挙げられます。ユーザーを絞り込んだABテストが容易にできるだけではなく、デブロイの早さなどを考慮してハイブリッドアプリにしていると聞いたことがあるのですが、そのほかにハイブリッドアプリにしかできないことってありますか？

畠田：ハイブリッドアプリって遅いんじゃないか？というハイブリッドアプリに否定的な声に対抗できるので、クックパッドさんの成功事例は我々にとってありがたいですね。

詳しくは存じ上げないのですが、クックパッドさんにとっては、新機能のデプロイまでの時間を短くするための、現時点での最善策がハイブリッドアプリなのではないでしょうか。

株式会社ニューフォリア　畠田喜丈さん

ハイブリッドアプリで開発してドはまりしたことある？

白石：ところで、ハイブリッドアプリでドはまりした経験はありますか？デバックが全然できなかったとか、移植したら動作が違うとか。

金井：端末によって同じCSSなのに見た目が全然違うのもそうですが、JavaScriptの挙動も違うところ。一方の端末は滑らかに動くのに、別の端末だとカクカクだったり、もっさりしたり。とにかく端末ごとに挙動が違うのは予想できないので、トライ＆エラーを繰り返すことになりましたね。

html5j Web先端技術味見部部長　AngularJS Japan User Group 管理人　金井 健一さん

標準化の動きはどうなってる？

白石：CordovaやニューフォリアのAPI、Chrome AppsのAPIなど、モバイルデバイス向けのWeb APIは細分化しつつありますが、これって標準化できないものなんでしょうか。

──ここで、白石さんが突然会場の羽田野太巳さんを指名

羽田野さん、現状ってどんなかんじなんですか？

羽田野：最新情報はあまりよく知らないんだけど、統一はしばらくないんじゃないかと思います。もちろんいつかは一緒にするために施策を立てているとは思いますが、現在はFirefox OS/Windows 8/Chrome Appsなど、各ベンダーが独自にAPIを作り込んでるのが現状です。

でも、いつか標準化してくれるからそれまで開発を待とうなんてベンダーはないわけで。いろいろAPIが出てきて、いろんな事例を経験して、みんなが試していいものが残っていくし、ある意味健全です。だからまだまだ時間がかかる。個人的にはベンダーがそれぞれ独自のAPIで作っていくのは大歓迎ですね。

これまではネイティブでしかできなかったことが、JavaScriptで何でも開発できるようになってきました。今はばらばらだけど、一つのプログラム言語だけでできるようになりつつあると思います。これはまだデファクトではないけど、コンソーシアム標準的には前向きに捉えていいのではないでしょうか。

有限会社futomi 代表取締役、株式会社ニューフォリア　取締役　最高技術責任者 羽田野 太巳さん

HTML5でデバイスごとの互換性や移植性がとれてない？

白石：ところで、HTML5ならデバイスごとの互換性や移植性がとれると言われていたのに、結局選ぶプラットフォームに依存していて、互換性がとれてないですよね？その辺はいかがでしょうか。

HTML5 Experts.jp編集長　白石 俊平

さまざまなデバイスでWeb技術が果たす役割

白石：これからさらに様々なデバイスが登場し、Web技術が果たす役割も増えていくと思います。皆さんはどのようにお考えですか？

吉川：いろんなデバイスにWebの技術が広がっていくのはうれしいですね。Webの進化のスピードに合わせて、デジタル家電のUIやデザインの進化も加速するはず。期待したいです。

畠田：ユーザーインターフェイスもだんだんWebに準じたものになり、今まで古くさかったデザインやUIが洗練されたものになっていくはずです。Webで活躍しているエンジニアやデザイナーたちによって使いにくいインターフェイスやマニュアルなどが革新されていく。誰でも使えるようになる世界が早く来てほしい。

白石：ただ僕が心配しているのは、ウェアラブルなデバイスなど、デバイスの小型化がどんどん進んでいる現状では、デバイスの「非力化」も進んでいるんじゃないかと思うのです。そうなると、比較的高いCPUパワーを必要とするWeb技術は敬遠されて、ネイティブが当たり前になっちゃうんじゃないかと。Webブラウザを搭載しないデバイスも増えてきそうです。

吉川：それは心配ないんじゃないでしょうか。ハードウェアの進化があったからこそ、ウェアラブルが出てきたはず。今後もハードウェアの進化は続くでしょう。

例えば、昔のインターネット回線が遅かった時代は動画なんてありえませんでしたが、回線が早くなったからこそ品質が良くなって動画サービスがブレイクした。要は、環境次第で変わるということです。今は、ハードウェアの性能が上がってきているからこそ、Webを組み込んでも大丈夫じゃないかという流れですね。未来はそんなに暗くはないんじゃないかな。

Google Developer Expert（Chrome）　吉川 徹さん

さらに会場からは、HTMLとJavaScriptとCSSで書くから重くなるのではないかという声も。JavaScriptだけにすれば軽くなるのではという意見や、3つ以外の言語や新たなレンダリングエンジンが生まれる可能性、WebGLやFamo.usなどに対する期待の声も多く聞かれました。

未来のデバイスとWeb技術にも夢を馳せながら語り合った対談もここで終了。Webとネイティブのメリット、デメリットを合わせ持つハイブリッドアプリが、今後デバイスやWeb技術の進化とともにどう技術的課題をクリアしていくのか。編集部では今後も最新事情をお伝えしていきたいと思います。

★今回の登壇者が執筆したハイブリッドアプリ特集記事もぜひ合わせてご覧ください。

• 久保田光則さん執筆：HTML5ハイブリッドアプリ開発、最新動向はやわかり！
• 金井健一さん執筆：キミはionicを知っているか？AngularJS+PhoneGap+美麗コンポーネント群！
• 畠田喜丈さん執筆：PhoneGapとは一味違う！純国産ハイブリッドアプリフレームワーク、「アプリカン」事始め
• 吉川徹さん執筆：Chrome AppsをモバイルでもーChrome Apps on mobileー
• ハイブリッドアプリ開発最前線：特集レポート一覧はこちら

ServiceWorkerとは

ServiceWorkerは、リソースの永続的なキャッシュを可能にする、およびWebアプリケーションのリソース要求の処理を可能にする新しい機能です。Webページを開く前であっても（ネットワークの接続/切断の有無にかかわらず）、独自の処理を挟み込めるのがポイントです。クライアント側に、一種のプロキシサーバがあるようにイメージされると分かりやすいと思います。

ServiceWorker自体は、WebWorker同様にJavaScriptで記述し、特にWebWorkerの一種であるSharedWorkerに似ています。最大の違いとしては、SharedWorkerはWebページによってコントロールされるのに対し、ServiceWorkerはWebページをコントロールします。任意のWebアプリケーション(ServiceWorker)がひとたびインストールされると、次回以降のアクセスでは、ブラウザ側の処理がはじまる前に、ServiceWorkerの処理が起動します。

注意点(ブラウザのサポート状況について)

執筆時点では、ServiceWorkerをサポートするブラウザはありません。Chrome Canaryでは、以下のようにchrome://flagsにて一部の機能を有効化できますが、あくまで一部の機能であり、後述するキャッシュからリソースを取得する機能等、多くの機能は動作しません。

Chrome://flagsのスクリーンショット

登場の背景

オフラインWebアプリケーションの開発において、よく知られるキャッシュ機能にApplicationCacheがあります。ApplicationCacheは、ネットワークが切断されている状態であっても、事前にキャッシュしたコンテンツを、Webアプリケーションに提供しますが、こちらの記事でも言及されているとおり、様々な問題を抱えています。

例えば、ApplictionCacheは一部のキャッシュのみを更新することができません。ApplicationCacheでは、キャッシュしたいリソースを以下のようなmanifestファイルにすべて記載しておく必要があり、

CACHE MANIFEST
index.html
stylesheet.css
yourapp.js
myimage.png   

ブラウザがWebページにアクセスした際に、これらのリソースはすべてダウンロードされます。仮に上記のコメント箇所のように、リソースの一部のキャッシュのみを更新したいと考えていても、不可能となります。

上記の例は、ApplicationCacheの抱える問題点の一例に過ぎず、その他にも問題点が多くあります。ServiceWorkerは、これらの問題点に対する解決方法となります。

以下で、W3Cの草案で示されるコードサンプル(本記事では一部簡略化)を参考に、利用イメージを解説します。W3Cの例では、非同期処理にpromiseを利用しています。本記事ではpromiseの解説はいたしませんので、必要に応じてMDN等を参照ください。なお、前述した通りで、執筆時点でServiceWorkerが動作するブラウザはありませんので、以下のコードは実際には動作しない点にご注意ください。

ServiceWorkerの利用イメージ

例えば、https://www.example.com/index.htmlにて、ServiceWorkerを利用するケースを考えます。(ServiceWorkerはセキュリティの都合上、HTTPSが必須となる点に注意ください) 先に処理フローを図示し、その後にコード例で解説いたします。

※ 2014/05/23 追記：ServiceWorkerの処理フローを示す図を追加いたしました。（本図は、Expertsの川田さんから提供いただきました）

Register(登録)

まずServiceWorkerとして動作させたい処理を登録(register)します。

if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('/assets/myapp.js').then(
  	function(serviceWorker) { 
  	  console.log("myapp.jsのインストールに成功しました")
    },
  	function(why) { 
  	  console.log("myqpp.jsのインストールに失敗しました");
  	}
  );
}

上記により、/assets/myapp.jsがブラウザにダウンロード＆インストールされます。ひとたびmyapp.jsがインストールされると、次回以降のhttp://www.example.com/配下に存在するページにアクセス時に、myapp.jsの処理が起動します。前述したように、ネットワークが切断状態であってもmyapp.jsは起動しますし、もちろんブラウザ自体が持つキャッシュ機構よりも先に動作します。

なお、上記のコード例では http://www.example.com/ の配下すべてのリソースが対象となりますが、/hoge/* のように、scopeを制限することも可能です。その場合、以下のとおり、オプション引数であるscopeを設定してください。

if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('/assets/myapp.js', {
    scope: 'hoge/*' // スコープを設定している
  }).then( ... );
}

続いて、ServiceWorkerの処理を記載するmyapp.jsの例を見ていきましょう。

Fetch(リソースの取得)

myapp.jsは、WebWorker同様にWorkerスレッドで動作します。そのため、DOM操作はServiceWorkerでは利用できません。ServiceWorkerは、fetchイベントを利用してリソースへのリクエスト・レスポンスを処理します。

this.addEventListener('fetch', function(event) {
  console.log(event.request);
});

上記の例では、http://www.example.com/*へアクセスしたすべてのタイミングで、fetchイベントが起動し、event.requestオブジェクトがコンソールに表示されます。event.requestオブジェクトは、例えば、URL、メソッド、ヘッダ等を含んでいます。

上記は単にリクエストを処理しているだけですが、任意のレスポンスをブラウザへ返すこともできます。

this.addEventListener('fetch', function(event) {
  event.respondWith(
    new Response({
      body: 'この内容はServiceWorkerが提供しています！'
    })
  );
});

この例では、http://www.example.com/* へアクセスすると、「この内容はServiceWorkerが提供しています！」と表示されます。

リソースのCache

オフラインでも動作させるためには、キャッシュを利用する必要があります。キャッシュするためのコードは以下のようになります：

this.addEventListener('install', function(event) {
  var coreCache = new Cache();

  event.waitUntil(Promise.all([
    caches.add('core-v1', coreCache),
    coreCache.add(
      '/app.html',
      '/fallback.html',
      '/assets/v1/base.css',
      '/assets/v1/video.webm'
    )
  ]));
});

ServiceWorkerのインストール成功時に発生するinstallイベントを利用して、キャッシュを準備します。Cacheおよびcaches(cacheListのインスタンス)は、ServiceWorkerが用意するストレージAPIです。上記例では、coreCache.add()にて、4つのリソースをキャッシュしています。

Cacheしたリソースを取得する

Cacheしたリソースを取得するには、fetchイベントを利用します：

this.addEventListener('fetch', function(event) {
  event.respondWith(
    caches.match(event.request).catch(function() {
      return cache.match('/fallback.html');
    })
  );
});

上記では、event.requestで指定される内容がすでにcachesにあれば(caches.matchでrejectされなければ)、cacheされている内容を応答します。cachesにない場合は、.catch(…)の処理に進み、fallback.htmlの内容がブラウザに返されます。

ServiceWorkerの更新

ServiceWorkerは、Webページにアクセスするたびに、更新があるかどうか確認します。HTTP Cache-Controlヘッダにて、確認頻度を減らすことも可能ですが、ApplicationCacheに存在する問題を解決するために、長くとも24時間ごとにブラウザが更新を確認します。

もし、ServiceWorkerが以下のコード例のように少しでも異なるならば、新しいバージョンであるとブラウザは判断し、ServiceWorkerをインストールします。

this.addEventListener('install', function(event) {
  var coreCache = new Cache();

  event.waitUntil(Promise.all([
    caches.add('core-v2', coreCache), // v2にしている
    coreCache.add(
      '/app.html',
      '/fallback.html',
      '/assets/v2/base.css', // v2にしている
      '/assets/v1/video.webm'
    )
  ]));
});

インストール処理の間は、現段階のバージョンがfetchイベントに対応し、新しいバージョンのServiceWorkerのインストール動作はバックグラウンドで動作します。

インストールが完了したら、新しいバージョンのServiceWorkerは待ち状態になり、、すべてのページにて現段階のバージョンの利用されなくなるのを待ちます。現段階のバージョンが利用されなくなると、新しいバージョンが動作を開始します。このとき、activateイベントが発生します：

this.addEventListener('activate', function(event) {
  event.waitUntil(
	// 古いキャッシュの削除等を実施
  );
});

activateイベントは、上記コード例のように古いキャッシュの削除等、新しいバージョンのServiceWorkerで不要となるリソースの掃除に利用されます。

まとめ

本記事では、ServiceWorkerの登場背景、利用イメージについて解説しました。ServiceWorkerは今後、オフラインWebアプリケーションのコア技術となっていくと想定されます。まだ、ブラウザの実装も進んでいないことからも分かるように、ServiceWorkerはWebの最先端です。

今後も、HTML5 Experts.jpでは、今後も読者の皆様にWeb最先端の情報をお届けいたします！

参考

• Service Workers – W3C First Public Working Draft（英語）
• ServiceWorkerの詳細（英語）
• ServiceWorkerのユースケース（英語）

斉藤祐也の海外WEBテク定点観測＜Issue.12: 2014/03/01-2014/03/31＞

今月の定点観測はWeb Componentsに関するパネル、WebとDOMとの関係性、ARIAのWeb標準化などを紹介します。

注目ニュースピックアップ

Web Componentsに関するパネルディスカッション

原題: EdgeConf 3: Components

3月21日にロンドンにて開催されたEDGE Conferenceにて議論されたWeb Components。このカンファレンスでの議論そのものも非常に興味深いものですが、このカンファレンスをきっかけに多くの議論がブログなどで展開されました。Web開発の未来を担うとすら表されるWeb Componentsがその未来へと着実に歩みを進めるためにどんな障害があるのでしょうか。様々な領域で活躍するエキスパートたちの意見を以下に関連リンクとしてまとめましたので、興味がある方はぜひそれぞれ一読を。

関連リンク:

• A Detailed Introduction To Custom Elements – Smashing Coding
• Web Components Best Practices – WebComponents.org
• Web Components and the Three Unsexy Pillars – Aerotwist
• The Web’s Declarative, Composable Future.
• Notes on accessibility of Web Components – Bruce Lawson’s personal site
• The Golden Path
• Notes from the edge – Adactio

Shadow DOM – Acko.net

Steven Wittens氏により書かれたこの記事のタイトルはShadow DOMですが、あのShadow DOMではなく、DOMに関する問題点へ指摘と解決策の提言です。React.jsのようにDOMらしいものを生成しDOMを制御するアプローチがあったり、Angular.jsのようにHTMLによく似たシンタックスでDOMへのアプローチを隠蔽するアプローチがあったりと、DOMから離れれば離れるほどWebそのものがよいものになったように思えてくる。氏の狙いは非常に的確なものだと言えると思いますが、以下に関連リンクとして紹介しているCSS TricksのChris Coyer氏による反論も併せて読んでおくと良いでしょう。

関連リンク: Hatin’ on Web Tech by CSS-Tricks

WAI-ARIAがWebのアクセシビリティを拡張する – W3C Blog

原題: WAI-ARIA Expands Web Accessibility

Accessible Rich Internet Applications 1.0 (WAI-ARIA)、そして関連する仕様であるWAI-ARIA 1.0 User Agent Implementation GuideがW3C Recommendationとなりました。つまり、WAI-ARIAはWeb標準となったことを意味します。広範囲に及ぶ、実装だけではなく、テスト、そしてバグ修正を行い、多くのモダンブラウザですでにサポートされ、モバイル・ブラウザにおけるサポートも広がってきています。またHTMLだけではなく、EPub 3.0やSVG 2などの仕様にもWAI-ARIAを適応し、より広範囲でのアクセシビリティを提供していくそうです。

関連リンク:

• We Make the Web. Let’s Make It Accessible. – The Changelog
• What is WAI-ARIA, what does it do for me, and what not? | Marco’s accessibility blog

Browsiness – Adactio

本連載、Issue. 11にて紹介したJeremy Keith氏による「Webに課せられたある1つの矛盾」の考察に対する追記に当たる記事といえるでしょうか。記事はAndroidとiOSの違いについての考察から始まり、ネイティブとWebの差に話が及ぶ。その段になってKeith氏はWebとは何かという根源的な疑問に対し、氏がどのように考えているかについて語っていきます。
氏は次の文で記事を締めくくります。 『分裂として捉えるのを辞め、多様性として捉え始めるべきだ。』
氏の言葉通り、WebとはHTMLやCSS、JavaScriptで書かれたものだけを意味するものではないでしょう。

関連リンク: Why don’t designers take Android seriously? : Cennydd Bowles

Web標準化に貢献するために必要なこと – Anne’s Blog

原題: Contributing to standards

Anne van Kesteren氏はWeb標準化に貢献するためには、Web標準がコミュニティによって作られていることに気がつくことが大切なステップだとし、そのコミュニティでコミュニケーションに利用されているミディアムを追いかけることを次のステップとしています。もちろん貢献しようとしている標準そのものに詳しい必要もありますが、それらを取り巻く環境にまず慣れることが活動の第一歩だとしています。

関連リンク: How to win friends and influence standards bodies – Domenic Denicola / Domenic Denicola氏がLXJS 2013にて発表した彼自身がどのように標準化団体にアプローチしたかについてのプレゼンテーション。

海外トレンドコラム

Picture要素に関するQ&A – An A List Apart

原題: [A Q&A on the Picture Element

Picture要素の復活に尽力したMarcos Caceres氏とYoav Weiss氏に対して、同じくResponsive Images Community Groupに所属しているMat Marquis氏がインタービュー。 Picture要素が以前のバージョンとどこが違うのか、それまでに登場したsrcsetやsrc-nという仕様や提案が現在のPicture要素にどのように影響しているのかなどについて詳しく解説しています。

Srcsetとsizes – ericportis.com

原題: Srcset and sizes

Picture要素の現行仕様はどうしてそのシンタックスを採用したのでしょうか? この記事ではその疑問に対して、具体的なソースコードを見ながら現行の仕様とほかのレスポンシブ画像に対する解決案を比較しています。srcsetに加えて新たに追加されたsizesという属性が重要な役割を担っているのが一目でわかります。

モバイル・ファーストはもう終わった、のか? – Forbes

原題: Mobile-First Is Dead, Says Google Display Ad Chief Neal Mohan

Googleのディスプレイ広告部門の副社長を務めるNeal Mohan氏によると、多くのユーザーはもはやモバイルだけにフォーカスをしているだけでは時代遅れになりつつあるとしています。消費者達は多くのデバイスを駆使して、利用シーンに合わせてタスクを完遂しているとしています。なんと約90%ものユーザーがあるデバイスで開始したタスクを別のデバイスで完了しているとしています。モバイル・ファーストはすでに過去の問題を解決しようとしているに過ぎないと氏は語り、今後はマルチデバイスの最適化にフォーカスを移していくべきだとしています。

若いデザイナー、デベロッパに対するアドバイス – Andy Budd

原題: My Advice to Young Designers and Developers

日本ではそうでもないと思いますが、大学を卒業するよりも業界の経験を積んでいる方が重宝される業界であるWeb業界において、大学に行く意味とはなんなのかをAndy Budd氏がアドバイス。

パフォーマンス最適化 #perfmatters

Paul Lewis氏のパフォーマンスチェックフロー – Aerotwist

原題: My Performance Audit Workflow

Googleの中でもパフォーマンスに注力しているPaul Lewis氏本人のパフォーマンスチェックのワークフローについて。氏はまずPageSpeed Insightsでサイト全体の状態を確認し、WebPageTestを使ってネットワーク周りのパフォーマンスを細かくチェック。それから、レンダリングに関わるパフォーマンスチェックを、このリストを参照しながら行っているそうです。このワークフローは手動で行うものがほとんどですが、自分が担当するプロダクトでは自動化できる部分は可能な限り自動化をしているとのこと。

ブラウザキャッシュは”とても”壊れている – JakeArchibald.com

原題: The browser cache is Vary broken

HTTPキャッシュはURLとHTTPメソッド(GETやPOSTなど)でコントロールするものですが、”Vary”ヘッダを利用してより細かく制限をすることができます。しかし、この”Vary”ヘッダは少々やっかいもので、IEでは”max-age”が無視され、Safariでは少々バグがあったりもします。この記事では具体的な例を見ながら”Vary”ヘッダの挙動について詳しく紹介しています。

CSSアニメーションとトランジションのパフォーマンスについて – Web Platform Team Blog

原題: CSS animations and transitions performance: looking inside the browser

ブラウザ内部がどのように動作しているのかを知ることで、CSSアニメーションやトランジションの記述をする前に、そのアニメーション/トランジションのパフォーマンスがよいものか、そうでないのかを知ることができます。この記事では特にGPUがどのようにパフォーマンスに作用するのか、そしてなぜ特定のプロパティをアニメートすることがパフォーマンスのボトルネックになるのかについて、詳しく解説しています。

WebKitのCSS JITコンパイラについて – Surfin’ Safari

原題: Little overview of WebKit’s CSS JIT Compiler

ブラウザはユーザーに対してよりよい体験を提供するために日々改善を行っています。この記事ではWebKitがCSSの解析にかかる時間をどう改善していくのかについて、JavaScriptの解析では当たり前のように利用されているJIT(Just In Time Compilers)をCSSのセレクタの解析に応用してみた結果について紹介しています。

jQueryはモバイルには大きすぎるのか? – Flippin’ Awesome

原題: Is jQuery Too Big For Mobile?

モバイルWebにおいて、パフォーマンスが特に重要なファクターであることはよく知られています。パフォーマンスの最適化に際し、デスクトップの時代には当たり前のように利用していたjQueryは、そのファイルサイズからモバイルでは利用されない傾向にあります。しかし、本当にjQueryはモバイルには大きすぎるのでしょうか?　この記事では実際のモバイル端末でjQueryを読み込み、どのくらいの時間がかかったのかを詳しく解析しています。また読み込みだけではなく、解析にかかる時間も加味した詳細なデータで疑問に答えてくれています。

クローズアップ“ビデオ/スライド/ツール”

スライド

Viewportとレスポンシブデザインの関係

原題: Viewports or: why responsive design works

Peter-Paul Koch氏がjQUery EUで発表したこのプレゼンテーションは氏の得意とする詳細なテストによるデータを使ったViewportから見たレスポンシブ・デザインに関する実利的なアドバイスについてです。氏はまずピクセルとはなにかから解説し、モバイルとデスクトップのViewportsの違い、JavaScriptやMetaタグによるViewportsの仕組みについて詳しく解説しています。

関連リンク: The Great Table / Peter-Paul Koch氏による本プレゼンテーションで発表したViewportに関連するコンセプトのモバイルブラウザ別の対応状況をまとめた表。

Flexboxを使って一歩上行くレイアウトを – Zoe Gillenwater

原題: Leveling Up with Flexbox

Smashing ConferenceにてZoe Gillenwater氏が発表したFlexible Box Layoutを使ったレイアウトテクニックに関するプレゼンテーション。
仕様として少々バタバタしていたFlexible Box Layoutですが、ようやく様々なブラウザで同じシンタックスが利用できるようにもなってきて、現実的なアプローチとして注目が集まってきています。氏はこのプレゼンテーションで様々なレイアウトテクニックを紹介しつつ、Flexible Box Layoutをサポートしていないブラウザに対するフォールバックについても紹介しています。

関連リンク: Leveling Up With Flexbox presentation at Smashing Conference

Guardian誌のレスポンシブデザイン対応について

原題: Responsive design at the Guardian

イギリスの新聞であるGuardianにて、クライアントサイドWebデベロッパとして働くMatt Andrews氏によるプレゼンテーション。数年前にレスポンシブデザインを採用したBoston Globe誌を始め、最近ではBBCもレスポンシブデザインを採用しています。ニュースサイトにおけるレスポンシブデザインはなかなかハードルが高い部分がありますが、そのいくつものハードルをGuardianではどのように超えていったのかについて詳しく紹介しています。

ツール

HTML5 Security Cheatsheet

HTML5に関連する技術を使ったセキュリティに関する注意点と、その回避についてのチートシート。

CSSynth

CSSアニメーションを実際に目視しながらカスタマイズできるエディタ。特定のアニメーションに限ったエディタではありますが、エディタが作り出すスムーズなアニメーションは見ていて飽きません。

CSS Filters Demo

上で紹介したCSSynthの作者による別プロジェクト。こちらはCSSのフィルタを使ったデモ。

★次回の「斉藤祐也の海外WEBテク定点観測」は2014年5月1日にお届け予定です。★

TPACという大きなイベントも終了し、またホリデーシーズンに入ったこともあり、12月のW3Cはとても静か…と思いきや、結構な数の仕様に更新ありました。

また、先月ちょっとだけ取り上げたShared Workersの今後について議論されるなど、思ったよりも動きのある12月でした。

Shared Workers復活！？

先月の記事にて、WebApps WGのF2FにてShared Workersが削除されることを取り上げました。これはShared Workersの実装が乏しく、2つ以上の実装という勧告への要件を満たせないという懸念を受けてのアクションです。

• Refactoring SharedWorkers out of Web Workers W3C spec

しかし12月に入り、FirefoxがShared Workersを有効にしました（Firefox 29より利用可能となります）。

• mozilla-central: changeset 159853 — Bug 924089 – Enable SharedWorker by default

これを受け、Shared Workersを削除する必要があるのかといった議論が、WebApps WGのメーリングリストで交わされています。議論の中で実はPrestoも実装していたという話も出てきて、こないだの話はなんだったのだろう感が否めません。

とはいえ、この議論が出てきたのはその実装状況が不明だった、テストスイートによる検証がなされていなかったなど、現状把握を誰も行っていなかったことに起因します。メーリングリストでは、その後各ベンダーの担当者にWeb Workersのテストスイートを実行するよう要請したことで、実装状況と相互運用性の状況がわかりつつあります。

• Webapps/Interop/WebWorkers – W3C Wiki

議論を追うとテストケース自体への問題も指摘されており、Shared Workersが削除されるというよりもWeb Workers自体の問題に移行しているようです。

なお、Web Workersについてはいくつか機能追加の要望もあり、Level 2仕様への希望も出ました。CanvasのImageDataをWorkersで扱うインターフェースなどはすでにWHATWG HTMLで提案中ですが、synchronous message channelsなど別の機能も求められているようです。

冬休みに入ったためか議論が止まってしまい、今後は以前不透明です。とはいえ、実装が増えたことはShared Workersについて明るいニュースだったのではないでしょうか。

CSSOM Viewが更新 ― devicePixelRatio、スムーズスクロール機能が追加

2013年12月17日付けで、CSS WGから新しいCSSOM Viewの草案が公開されました。

• CSSOM View Module

CSSOM ViewはCSS関連のオブジェクトモデルのうち、ブラウザやシステムに関わるプロパティを定義する仕様です。古くからあるclientWidthやgetBoundingClientRect()、比較的最近ではmatchMedia()などが定義されています。

今回の草案の見どころは、window.devicePixelRatioとスムーズスクロール関連の機能が定義されたことでしょうか。window.devicePixelRatioプロパティはAppleが高解像度モードのためにWebKitに導入した独自拡張で、Retina Displayをはじめ高密度ディスプレイへの対応をする際に使われています（ちなみにこのプロパティ、iPhone 4で初めてRetina Displayが登場するよりもずっと前の2006年に実装されています）。他のベンダーも追従し、最近ではIE11でも実装されました。

今回のCSSOM Viewではブラウザのズームとピンチズームの概念も導入され、さらにdevicePixelRatioがブラウザズームの影響を受けると定義されました。これはGecko, Blink, Tridentの挙動に沿ったものですがWebKitの実装はそうではなく、Appleはこの定義に反対しています（WebKitではブラウザのズームにも、画面解像度の変更においてもdevicePixelRatioの値が変化しません）。

スムーズスクロール機能は現在、JavaScriptライブラリやスニペットを使って実装されていますが、タイマーを使ってちまちまscrollTo()をするものであまり効率が良い感じがしません。 今回の草案では新たにscroll-behaviorプロパティというCSSプロパティが定義されました。scroll-behavior: smoothと指定すれば、対応する実装がネイティブのスムーズスクロールを利用するよう支持できます。

ほかにも、新たなメソッドmoveTo()、moveBy()、resizeTo()、resizeBy()の導入や、resizeイベントとscrollイベントが定義されたりなど盛りだくさんです。

続CSSOM View ― PPK氏によるDPR調査など

ブラウザの互換性調査などで有名なPeter-Paul Koch氏が、devicePixelRatioやズーム、screen関連のDOMプロパティについてコメントを寄せました。デスクトップのページズームはdevicePixelRatioに影響させるすべきでないなど、今の流れと正反対の意見を唱えており、ちょっとした議論になりました。

• [css-om] Issues with width and resolution media queries

CSSOM Viewはもともとあまり互換性のなかったデスクトップブラウザ間の挙動を、なんとか合わせるために策定が始まりました。しかしviewportやデバイスピクセル比などモバイルからもたらされた概念が関わり、さらにはブラウザのバグなどもあり混沌としています。今回の議論は、そういった概念の整理に加え、現在出回っているモバイルブラウザの挙動と、プラットフォームとしてどうあるべきかという仕様の方向が異なっていることも背景にありそうです。

なお、デバイスピクセル比については、ほかにもresolution媒体特性が返す小数点の位がとる幅について議論されています。

仕様の断片化にどう対処するか

Jens O. Meiert氏がHTML WG、CSS WG、WHATWGに、仕様の断片化についてアドバイスをしていました。

• CSS, HTML, and the Problem of Spec Fragmentation · Jens O. Meiert

CSSはモジュール化というアプローチで策定されていますが、氏は以前より機能が増えすぎていることを問題視していました。また、CSSモジュールだけではなく、WHATWG仕様の一部やHTML仕様、SVGでもセレクタやプロパティが定義されてることに触れ、見通しの悪さも指摘しています。

HTMLについても、WHATWG HTMLとW3CのHTML5、それにHTML 5.1と細かなバリエーションがあります。氏は触れていませんが、拡張仕様やHTML仕様が参照するいくつかのDOM仕様も含めると、HTML関連仕様も数がかなり多くなりそうです。

Meiert氏は、実装する方においては都合がよいかもしれないが、開発者は複数の仕様の違いに戸惑うことを問題視しています。仕様の断片化についてはW3Cの勧告プロセスにあるのではないかと思いますが、たしかに仕様の分割が頻繁で、どの機能がどこにあるのかがわからなくなることしばしばと思います。

Custom Elementsのメソッド名が変更

いろんな「今年注目すべきWeb技術」的エントリで、ここ数年取り上げら続けているWeb Componentsですが、そのいち仕様であるCustom ElementsについてAppleよりコメントが寄せられました。Custom Elements仕様はWeb Componentsの独自の要素を定義するための仕組みを用意します。要素を定義するためのメソッドはこれまでdocument.register()という名前でしたが、registerという単語1語の名前が汎用的すぎるといったコメントが寄せられました。

• [custom elements] Improving the name of document.register()

こういった名前に関する指摘は自転車小屋の議論に陥りやすく、W3Cで過去に起こった同様の議論でもあまりいい解決を見たことがありません。しかしながら、今回はApple, Mozilla, Googleなどベンダーの開発者からのフィードバックもあり、それなりに思慮深い話になった感じがします。

結果として、仕様はdocument.registerElement()を使うことになりました。Chromeの実装も変更されています。

その他12月に公開されたWeb標準

• 12月3日付けで、CSS ShapesがCSS WGよりLast Callとして公開されました。大きな変更はTPACでのF2Fにて決定された構文の変更が仕様書に反映されたことでしょうか。
• 12月3日付けで、High Resolution Time Level 2の草案がWeb Performance WGより初公開にしてLast Callというすっとんだかたちで公開されました。Level 2での機能追加は今のところWeb Workersでのサポートとなっています。
• 12月5日付けで、CSS Object Modelの草案がCSS WGより公開されました。カスケードされた後のスタイルや利用されるスタイルといったスタイルを取得するインターフェースや、CSSOMとしてセーフな値にするCSS.excape()メソッドなどが新たに定義されています。
• 12月10日付けで、DOM Parsing and SerializationがWebApps WGよりLast Callとして公開されました。innerHTMLやinsertAdjacentHTML()を定義する仕様です。
• 12月12日付けで、Performance Timeline、User Timingが勧告されました。
• 12月17日付けで、Pointer LockがWebApps WGより勧告候補として公開されました。
• 12月17日付けで、Input Method Editor APIの草案がWebApps WGより公開されました。IMEの候補ウインドウを描画するAPIが削除されたほか、Microsoftが提案したイベントやインターフェースが追加されました。

それでは実際、レスポンシブ・ウェブとは何についての対応（レスポンシブ）なのでしょうか。

現在のところ、私たちがいうレスポンシブ・ウェブデザインとは、どんなスクリーンの幅や表示領域、デバイスの画面解像度や画面の縦横の向きにも対応したウェブデザイン、というのが事実上の定義となっているようです。

そこで今回、私はその定義を超えたレスポンシブ・ウェブのユースケースについて考えてみました。

太陽光下でのスクリーン・リーダビリティ

私は普段の仕事ではNokia Lumiaというスマートフォンを使っているのですが、これがなかなかの優れもの。環境光センサーでスクリーンの輝度値を自動調整してくれるので、晴天の空の下でもスクリーンのコンテンツがはっきり読めるのです。ところが私の個人用で使ってる別機種の場合、そうもいきません。例えば読みたいウェブがたとえ「レスポンシブ」であれ「モバイル・ファースト」であれ、まぶしいカリフォルニアの空の下では、全くコンテンツが見えないので使い物にならないのです。

一方、W3CのCSSメーリングリストでは、次世代のCSS Media Queries 4のひとつである

luminosity

しかしこれが実現するのは一体いつの日になることやら…

Ambient Light Events API

というわけで、今現在のブラウザでは、CSSを使って環境光の度合いに合わせてウェブのUIを調整するのは不可能。

しかし私たちには、HTML5を使ってブラウザから各種センサーやカメラなどのハードウェアが持つ機能にアクセスするための仕様、デバイス APIのひとつであるAmbient Light Eventsがあるでないですか！
これならJavaScriptを使って環境光センサーから照度を知ることができるはず。これを使えば、次世代メディアクエリをまねて、太陽や照明にレスポンシブなウェブが作れるかもしれない！
そう思って私は、実験的に簡単なデモを書いてみました。

Devicelight events

デバイスのセンサーが照度の変化に反応すると、ブラウザ側では

DeviceLightEvent

devicelight

そこで得られるプロパティの値、

value

実際、大変簡単にこう書くことができます。

window.addEventListener('devicelight', function(event) {
  console.log(event.value + 'lux');
});

照度にレスポンシブなウェブを作ってみる

これを使って、環境光が変わってもウェブの内容を読みやすくするためのUIを考えてみました。

デフォルトではライトグレーの背景に黒の文字、明るい照度の時には白地に黒の文字、そして暗い時には暗めな背景に白の文字、というUIにしてみましょう。

例のAPIを使って、照度によってコンテンツのコンテイナー（このデモではわかりやすいように

document.body

window.addEventListener('devicelight', function(e) {
  var lux = e.value;

  if(lux < 50) {
    document.body.className = 'dim';
  }
  if(lux >= 50 && lux <= 1000) {
    document.body.className = 'normal';
  }
  if(lux > 1000)  {
    document.body.className = 'bright';
  } 
});

body,
body.normal {
  background-color: #ddd;
  color: #111;
}
body.dim {
  background-color: #444;
  color: #fff;
}
body.bright {
  background-color: #fff;
  color: #333;
}

実際に、このデモが動いている様子がわかる動画を作ってみました。

ブラウザサポートとデバイス

このデモで使われた実際のソースコードは、CodePenを見てください。

ほとんどの方の観覧しているブラウザ上では “AmbientLightEvent is not supported.” というメッセージが出ていて何も起こらないのではないでしょうか。というのも、残念ながら今のところ、このAPIをサポートしているのはFirefox 22+ だけ、しかもデバイス側にも環境光センサーが必要。
ですので、デスクトップから見ている皆さんには、どのブラウザを使っていてもこのデモは作動していないでしょう。私のデモで実際に使ったデバイスはNexus 7ですので、AndroidやFirefoxOSのデバイス持っている方は、ぜひFirefoxで試してみてください。

イベントが返す値も、デバイスによってばらつきがあるようです。私が実験した機種2機ではずいぶん違う結果が出ました。たぶんセンサーの精度にブレがあるのでしょう。

この写真にあるデバイスは、Moto G(Android)と、Keon(FirefoxOS)です。暗めの部屋での照度が、一方が6lux、もう一方が61luxとなっています。

CSS Media Queries Level 4 Luminosity

さて、話題をメディアクエリに戻します。
今現在の仕様では、メディアクエリ・レベル4はまだeditor’s draftの段階なので、ブラウザに実装されるまでにはまだまだ時間がかかりそうです。

将来的に実装された際には、このデモで書かれたコードはCSSのみでこのように書き直すことができるようになります。

@media screen and (luminosity: normal) {
  body {background-color: #ddd; color: #111;}
}
@media screen and (luminosity: dim) {
  body {background-color: #444; color: #fff;}
}
@media screen and (luminosity: washed) {
  body {background-color: #fff; color: #333;}
}

このように、

luminosity

おわりに

近い将来、レスポンシブ・ウェブの定義も、デバイスなどの多様性に合わせて変わってくるのではないでしょうか。このユースケースも実際果たして本当に役に立つのかどうかもまだわかりませんが、発想の転換とブラウザの新しい可能性、という面でこの記事を楽しんでいただけたかと思います。

この記事は元々は私個人のブログ（原文は英語）に掲載したのですが、TwitterやReddit、Hacker Newsで思いのほか話題になりました。やはりディベロッパ、デザイナは国境を問わず、みな新しい可能性に興味津々なのでしょう。

では。

今月より、主にW3CまわりのWeb標準について、前の月に公開された仕様の動向やグループ内での議論を取り上げる連載をスタートします。

もう12月下旬になってしまいましたが、今回は11月中旬にW3CのTPACというイベントが開催されたので、そちらの模様を中心にお届けします。

W3C TPAC開催

11月10日から11月15日まで、中国の深センにてW3Cの総会「TPAC 2013」が開催されました。

• On TPAC 2013 | W3C Blog

TPACでは、W3CがW3C Member（会員）と運営に関する会議を行うほか、W3Cの各WGがFace to Faceミーティングを開催します。

Plenary Day ― デュアルライセンス、プロセス改訂など大きな提案が

TPAC期間の水曜日は、Technical Plenaryという日で、WGなどの壁を超えたコミュニケーションが行われます。今年のPlenary Dayでは、午前中がシングルトラックでのセッション、午後はアンカンファレンスによるセッションという構成で行われました。

Plenary Dayの午前中で面白かったセッションは、HTML WGが策定する仕様のライセンスと、W3Cのプロセス改訂の話でしょうか。

HTML WGの仕様とW3C/CC-BYのデュアルライセンス

HTML5仕様をはじめ、W3Cの仕様はW3C Document Licenseという独自のライセンスのもと提供されています。このライセンスの大きな欠点としては、仕様をフォークできないということです。また、教育目的などであっても仕様の一部を利用するといったことも文言上は禁止されているなど、自由度の低いライセンスとなっていました。

9月にHTML WGの活動憲章が更新され、その際にHTML WGが策定するHTML5, HTML 5.1以外の仕様について、ライセンスをW3C Document LicenseとCreative Commons 3.0 Affiliationライセンスのデュアルライセンスのもと提供できるようになりました。

• A Dual License for the HTML Working Group | W3C Blog
• FAQ Regarding HTML Working Group Charter License Experiment

デュアルライセンスは試験的とされているため、他WGの仕様はデュアルライセンスになりません。また、HTML5仕様、HTML 5.1仕様もこの対象ではありません。まだまだ制限はありますが、使いやすい仕様書への第一歩となったのは間違いありません。

このセッションでは、GPLやCC0など他のライセンスとの比較や、仕様の分断化に対する懸念やPatent Policyとの関連など、幅広い観点から意見が出ていました。

Last CallとCandidate Recommendationが統合？

これまで、W3C勧告プロセスでは、仕様が以下の5つのステップに分かれていました。

1. Working Draft
2. Last Call Working Draft
3. Candidate Recommendation
4. Proposed Recommendation
5. Recommendation

各段階ごとの役割（WG内での仕様策定完了、実装を受け付ける、など）を設け進めていくモデルなのですが、頻繁に仕様が更新されるようになった今、プロセスが手間となるといった問題が出ていました。

検討されている新しいプロセスでは仕様の段階と役割を再検討し、Working Draft、Last Call Candidate Recommendation（仮）、Recommendation（仮）と3つのステップとなっています。加えて、これまで曖昧だった実装に関する言及を明確化するなどの改訂もとられています。また、「Recommendation」を「Standard」に変更するかといった議論も出ているとのこと。

今後は、寄せられたコメントをもとに、最終的なドラフトを1月にW3Cの諮問委員会に提出するとのことです。

アンカンファレンス

午後はアンカンファレンス形式で、10トラック合計26のセッションが開かれました。

• TPAC2013 – W3C Wiki

プロセス改訂の話の続きやW3CのサイトリデザインといったW3Cに関するセッション、Service Workers, Fetch, HTTP/2.0, オフラインWeb技術などの仕様にフォーカスしたセッションなど幅広いトピックが揃ったようです。

アンカンファレンスのセッションは短いため、概要と問題を説明し次のアクションにつなげて終了というものも多いのですが、HTMLのルビに関するセッションでは、拡張仕様として公開されたW3C HTML Ruby Markup Extensionsの大部分ををHTML5仕様に持ってくることが内定するなど、仕様策定に関するところで前進もありました。

Shenzhen F2Fs

水曜日のPlenary Day以外の日は、各WGのF2Fミーティングが行われました。

CSS WG F2F ― Shapes構文変更、ピクセル密度比の標準化

CSS WGのF2Fミーティングは、11月10日から11月12日の3日間にわたり開催されました。

• Minutes TPAC F2F Nov. 2013 Part I
• Minutes TPAC F2F Nov. 2013 Part II
• Minutes TPAC F2F Nov. 2013 Part III

CSS Shapes仕様では、CSSのシェイプとSVGのシェイプ構文や値の扱いが違いうことから構文を変更する話が出ていました。今回のF2Fで、rectangle()をLevel 2へ先送り、circle()の構文をradial-gradient()と類似したものへ変更することが決定しました。近日中にLast Callとなる予定です。

ピクセル密度比（device-pixel-ratio）についても議論がありました。現在広く使われているdevice-pixel-ratio媒体特性やwindow.devicePixelRatioプロパティは、2006年にAppleがWebKitに導入した仕組みです。iPhone 4のRetina Display対応から普及し、他のブラウザも互換性のために実装しましたが、そもそも仕様がないことやブラウザ内蔵のズーム機能・ピンチズーム時の関わりなどが決まっておらず、非互換が生まれています。今回、Appleが新しい機能を検討するという決定がなされました。既存機能の拡張や標準化とならなかったことが残念ですが、一方でピンチズームレベルや、ブラウザのズームレベルなど、取得できなかった値に対する言及もあり、今後の検討が気になります。

その他もフォーカスリングとフィルタとの関連性、他のプラットフォーム仕様のため属性を選択する擬似要素をセレクタ仕様に含めるか否か（CSSでは利用できませんが）など、興味深い議論が数多く行われています。

WebApps WG F2F ― Web Componentsやテストの議論が

WebApps WGのF2Fは、11月11日と11月12日の2日間にわたり開催されました。

• WebApps F2F Meeting @ TPAC 2013 — 11 Nov 2013
• WebApps F2F Meeting @ TPAC 2013 — 12 Nov 2013

Web Componentsの現状や課題については、Shadow DOMやCustom Elementsについてはおおよそ仕様が固まりつつあることがEditorから示されました。HTML Importsについては、クロスオリジンなコンポーネントをインポートすることに関しAppleから意見があり、ES6のモジュールなども含めた大きな議論となりました。

Web Workersにおいては、実装が乏しいShared Workersを削除するアクションが割り振られました。WHATWG HTML仕様では残ると思いますが、W3Cでの今後の動きは現在のところ不明です。

数多くの仕様を有するWebApps WGで急務なのが、仕様のテストです。実装は進んでいるもののテストケースがない、テストケースがレビューされていないといった問題があり、先に進められないという仕様がいくつかあるため、テストのレビューなどについてのセッションも設けられました。

HTML WG F2F ― 粛々とバグ対応＆勧告に向けた作業を

勧告まであと1年のHTML5を有するHTML WGのF2Fは、11月14日と11月15日の2日間にわたり開催されました。

• HTML Weekly Teleconference — 14 Nov 2013

14日には、Media Source Extensions仕様やEncrypted Media Extensions仕様のバグに対する議論が主に行われたようです。

Canvas 2D仕様については、フォーカスリング関連の機能にまだ問題があるとされ、拡張仕様への移動やLevel 2への見送りを含めた議論が行われました。

ルビ周りの要素については、Plenary Dayでの項でもお伝えしたとおりですが、ルビマークアップの拡張仕様をHTML5仕様に取り込むという話についての共有がなされました。

WebPerf WG F2F ― 新しい機能について議論

Web Performance WGのF2Fは11月14日と11月15日の2日間にわたり開催されました。

• Web Performance Working Group Teleconference — 14 Nov 2013

まず興味深かったのがrel=prerenderやrel=dns-prefetchといった、先読み関連の機能です。IE11で幾つか対応したこともあり、標準化という議題に再度あがったのでしょうか。rel=prerenderはHTML5仕様に追加するという話も出て、HTML WGとのジョイントミーティングの場でも共有されています。

リソースの読み込み関連では、lazyload属性などを有するResource Priorities仕様に関する議論も行われました。こちらもHTMLやSVGの要素に属性を追加するものなので、HTML WGやSVG WGとのジョイントミーティングで共有されています。

先日2nd editionが公開されたPage Visibilityですが、現在は取得できない「要素が表示されているか否か」を知る機能について議論が行われました。

その他、Beacon, HAR, Navigation Error Loggingなど検討中の新しい仕様についても議論が行われました。

SVG WG F2F ― SVG DOMの大改定がSVG2に？

SVG WGのF2Fも、11月14日と11月15日の2日間にわたり開催されました。

• SVG Working Group Teleconference — 14 Nov 2013

SVG DOMをHTML DOMに統合していく議論が盛り上がっていました。SVG DOMは現在HTML DOMと異なる名前空間に属していますが、これをHTMLと同じ名前空間にするといった提案が出ました。

• A proposal for improving the SVG DOM

新しいDOMへの移行により懸念されるのが、既存のコンテンツとの後方互換性です。検討中の提案では、graphicsというトップレベルの要素を導入し、そこでパーサの解釈を切り替えるというアイデアが提案されています。

DOMに関する変更はSVG2の後という流れでしたが、先送りすることで更に多くの旧SVG DOMに依存するコンテンツが増える懸念から、SVG2での検討対象とする流れになったようです。

Web Animationsなどのアニメーション関連機能については、宣言的な仕組みとしてAnimation Elementsが提案されました。animate要素など宣言的な仕組みはAppleが以前から求めていたもので、支持も取り付け、SVG WGの公式な仕様として今後策定が進むようです。

11月に公開されたWeb標準

TPACが開催され、忙しかったはずなのですが、数多くの仕様が公開・更新されています。
気になったものを抜き出してみました。

• 11月5日付けで新しいStreams API仕様がWebApps WGより公開されました。DOM Promisesベースになるなど、APIの大きな変更が行われています。
• 11月7日付けでW3C DOM4仕様の草案がHTML WGより公開されました。WHATWG DOM仕様のスナップショットという位置づけは変わらずですが、今回からWebApps WGからHTML WGに移管され、W3C LicenseとCC-BY 3.0のデュアルライセンスのもと公開されています。
• 11月7日付けで、Use Cases and Requirements for Standardizing Responsive ImagesがHTML WGよりW3C WG Noteとして公開されました。Responsive Imagesに関するユースケースをまとめた文書で、Responsive Images Community Groupにて主に作業されていたものです。

（Photo Credit: 仲裕介）

こんにちは。html5jテスト部の部長を務めています矢倉です。
今回は9月14日に行われた「Test the Web Forward Meetup (仮), Tokyo #1」について報告します。

Test the Web Forwardとは

今回のイベントをレポートするにあたり、まずはTest the Web Forward (TestTWF) について説明しないといけませんね。Test the Web Forwardとは、HTMLやCSSなどW3Cが策定している仕様のテストケースを、参加者で一緒に書こうというコミュニティイベントです。

W3Cの仕様が勧告されるには、仕様の実装が必要なのですが、その実装が正しいかを確かめるテストケースも必要です。しかし近年、これまでにないペースで数多くの仕様が公開され、また機能も複雑化していることから、テストが大きな課題となっています。そこで「Webプラットフォームを前進するために、みんなでテストを書いて協力しよう」というイベント、Test the Web Forwardが誕生しました。

• Test The Web Forward | W3C Blog
• Test The Web Forward とは？ ＆ 来られなくても参加できる方法

TestTWFは世界各国で開催されており、今年の6月には東京でも開催されました。東京のイベントでは最終的に700を超えるテストが提出され、大成功を収めました。

• Test the Web Forward Tokyo! | Web Platform Team Blog
• テストを通じて「より良いWebの実現」に貢献～Test the Web Forwardレポート – ＠IT
• Webをより良いものにしよう！ HTML5/CSSの仕様のテストを書くハッカソン「Test The Web Forward Tokyo 2013」レポート｜gihyo.jp … 技術評論社
• Web標準をテストするハッカソン –「Test The Web Forward」がついに東京に上陸 | ADC Plus
• Fumi’s Travelblog: Test the Web Forward を開催しました！ #testtwf

html5jテスト部とTestTWF Meetup (仮)

Test the Web Forward Meetup (仮) は、html5jのテスト部が主催するイベントです。6月のTestTWF後にhtml5jスタッフ内で「1回きりじゃもったいないから、継続開催していこう！」という話が発端となり、テスト部が立ち上がりました。

その際に筆者がテスト部の部長となったのですが、自分はW3CやWeb標準について少し知っているだけで、とくにテストについて明るいわけではありません。また、テスト部のスタッフにもテスト未経験者がいます。「じゃあまず、スタッフでテストの勉強会をしよう」という話になりました。

日程を調整して一段落したとき、TestTWFがW3Cの公式アクティビティとして取り込まれたことを知りました。これまでのコミュニティ活動が標準化団体にも認められたのです。素晴らしいことですね。

ではその流れに乗っかり、スタッフ勉強会をTestTWFにしようという話になり、今回のTestTWF Meetup (仮) の実現に至りました。今回はW3Cが主催するイベントではないので、「Test the Web Forward Meetup (仮)」と名前を変え、開催することに。「Meetup (仮)」とあるのは、W3C内でTestTWF関連イベントのブランディングを考えており、コミュニティで主催イベントの名前案に「TestTWF Meetup」があったので、「(仮)」とつけた上で使わせていただきました。

TestTWF Meetup (仮), Tokyo #1レポート

TestTWFについて簡単に説明するつもりが、だいぶ長くなってしまいました……。ここからようやく「TestTWF Meetup (仮), Tokyo #1」のレポートになります。

今回のイベントは、告知が開催1週間前になるなど急ごしらえ感の否めないものでしたが、20名近くの方に集まっていただきました。

午前中はテストの書き方を勉強

TestTWF Meetup (仮) の説明をする筆者

まず、筆者による挨拶と今回のMeetup (仮) の説明、その後、どのようなフローでテストケースが取り込まれるのかなどを説明しました。

• Test the Web Forward Meetup (仮), Tokyo #1

仕様のテストケースはW3CのGitHubアカウントが管理しており、レポジトリにPull Requestを送ることでテストを提出できます。テストのレビューは、レビュアーがいればその場でしてもらえます。レビュアーがいない場合はPull Requestを投げて、レビューを待ちます。

今回はレビュアーを呼べなかったので、Pull Requestを投げることをゴールとしました。ただしそれではテストが取り込まれませんので「帰ってからもTestTWF」になります。なかなかに厳しいイベントです。

続いてHTML5 Experts.jpコントリビューターの中島直博さんに、CSSのテストケースのひとつ「リファレンステスト（reftest）」について説明していただきました。

テストとリファレンスを見比べ、一致したらPASS！

• リファレンステストの書き方

Reftestは、テストしたい仕様を使って書いたテストケースと、すでに使える仕様（CSS 2.1など）で再現した「リファレンス」、ふたつのHTMLドキュメントを書くというテストの形式です。

CSSのテストは、ほかにも「テストをパスしたらここが緑になるよ」などとHTML中に書くテスト（self-describing test）という仕組みも存在していますが、機械的にも比べられる点からreftestが好まれているようです。

最後に、HTML5 Experts.js編集長の白石さんによる、仕様のテスト用フレームワークtestharness.jsの説明です。

非同期なテストのコード例

• testharness.jsでテストするには

testharness.jsは、HTMLやAPI仕様、CSSOMなど、DOM APIをテストする際に使用する、仕様のテストに特化したフレームワークです。「仕様のテストに特化」と書きましたが、QUnitなどJavaScriptのテストフレームワークに馴染みのある方にはそこまで難しくないと思います。白石さんも、なんと前日夜にスライドやコードを読んで話してくれました！

リンクしたtestharness.jsのスライドは作者本人による紹介スライドの翻訳なのですが、実際の仕様書の記述からテストに落としこむかたちで関数の使い方が説明されており、仕様書の読み方を知るとてもよい資料でもあります。リファレンスとしては、using-testharness.jsという文書が便利です（現在翻訳中です）。

ひと通り説明が終わったところで、お昼の時間に。午後からテストを書くので、CSS、API、HTML5とテストを書きたい対象ごとにグループになってもらい、そのグループでお昼ごはんを食べることになりました。

午後はテスト書き…探すのが難しい！

午後からいよいよテストケースを書きます。CSS、API、HTML5と大きなグループに分かれたので、テストしたい仕様書や機能を選んでテストを書いてもらいます。

しかし…ここからが厄介でした。無印のTest the Web Forwardでは、仕様書のEditorやテストのレビュアーが数多く参加してくれるため、その人達が関わる仕様書のテストを書けばとてもスムーズですが、今回はそうではないので自分たちでテスト対象を決める必要がありました。自分が馴染みのある仕様を選べるという点は自由でよいのですが、すでにテストが書かれている場合もあります。これを調べるには仕様書のテストカバレッジを見ればよいのですが、仕様書のどの箇所に対してテストされているのか記載がなく、テストケースを見るしかありませんでした。

• Test Suite Coverage Analysis ― Webプラットフォーム仕様のテストカバレッジを知るツール
• CSS Test Suite Manager ― CSS WGが利用する、テストスイートマネージャ
• Overview of testing in view of CR exit ― HTML5仕様の目次を取り出し、テストのカバレッジや実装状況を大まかに色分けした上で表示したもの

テストを書く時間もそこそこかかるのですが、今回いちばん難航したのが、このテスト対象を探すことだったように感じています。

書いたらPull Request！テストの解説も

テストを書き始めて3、4時間。いよいよ追い込みです。グループ内で分かる範囲でテストを確認して、コミット、push、そしてPull Requestをしました。今回は計12件のテストがPull Requestで提出されました。

それぞれのグループごとに分かれて作業していたため、最後に参加者のみなさんが書いたテストのコードについて、どういったテストなのかを説明させていただきました。

謎のジェスチャをする筆者（たぶんCSSのテストについて説明していたのでしょう）

おわりに

今回は「一人ひとつはPull Request」という目標を立てていましたが、残念ながら達成できませんでした。カバレッジの調査や仕様の選定についてもう少し力を入れるべきだったと反省しています。次回は仕様を絞ったイベントとする、レビュアーの方に協力してもらうことなどを検討しています。

運営としては反省点が多かったのですが、イベントとしてはとても良いことがありました。6月のTestTWF参加者の方に、今回初参加の方にテストの書き方やPull Requestなどを助けてもらったことです。みんなで作り上げるというコミュニティイベントとして、これほど理想的なかたちはありません。

参加者のみなさん、会議室をお貸しいただいたジープラ株式会社さま、本当にありがとうございました。また、AdobeのRebecca Hauckさんには、TestTWFやテスト全般について多くのことを教えていただきました。ありがとうございました。スタッフの皆さんも、おつかれさまでした。

GitHubでも、Pull Requestがひとつマージされました。まだレビューされていないテストがほとんどですので、これからも動向を追いかけていくつもりです。

今後もTestTWF Meetup (仮) は開催したいと思っていますし、Test the Web Forward自体もまた日本で開催したいという野望があります。ぜひご期待ください！

（Photo Credit: 中島直博）