Web 技術の調査方法

Chrome Platform Status

まず最初に、現状を把握する意味では Chrome Platform Status のページがある。元々は名前の通り Chrome だけの Status だったが、ここは Web の Status として今後も他のブラウザ実装も含めて整備される流れのようだ。

• https://www.chromestatus.com/feature/5669293909868544

これが現状だけを示す意味で最もスッキリまとまっている。

しかし、もう少し議論も含めて把握するために、筆者は Intents からたどることが多い。

(なお、最近の Intents は Chrome Platform Status から生成されるらしい)

blink-dev

WebCodecs の場合は、Google が提案/実装を主導しているため、blink-dev で進捗がわかる。

• blink-dev | Google Group

この ML は、主に Chrome のエンジンである blink の開発に関するアナウンスが行われている。

大抵の新しい API は Chrome が何かしら作業をしている場合が多いので、まず blink-dev から当たると何かしら取っ掛かりが得られる。

ちなみに、筆者はブラウザのカスタム検索エンジンとして blink-dev を登録しているので、ブラウザに "blink-dev" と打つだけで検索できるようにしている。

ここで WebCodecs を検索すると関連しそうなスレッドがいくつか見つかる。

まず、これらスレッドのタイトルについている "Intent to ~" という部分が、マイルストーンを示しており、だいたい以下の順で投稿される。

• Intent to Prototype/Implement
  • この機能について実装に着手する
  • 関連するドキュメントや議論に関するリンクがまとめられている。
  • Canary などでは作り途中のものが試せる場合がある。
  • 以前は Implement だったが最近 Prototype に名前を変えたのでまだ名残がある。
• Intent to Experiment
  • 実装がある程度形になったのでトライアルを開始する
  • Chrome Dev/Beta でフラグ付きで有効にできる
  • Origin Trials が開始される
• Intent to Extend Origin Trials
  • Origin Trials を延長する
  • Origin Trials は期限を決めて開始されるが、十分なトライアルが済んでない場合など
• Intent to Ship
  • トライアルで十分にフィードバックが集まり実装も固まったので、リリースする
  • コンセンサス、具体的には他の開発者から LGTM が 3 つが得られれば良いというルール
  • その後 Chrome Stable リリースに入る
• Intent to Deprecate
  • なんらかの機能を非推奨/無効にする
• Intent to Remove
  • Deprecate が完了したためコードを消す

(あくまで Intent なので、例えば Intent to Ship が出たら「Ship された」ではなく、「Ship しようと思う」という意味であることに注意)

もし該当の機能で何かしらヒットすれば、そこから調査を始めるのがわかりやすいだろう。

WebCodecs の場合は、Intent to Experiment まで出ているので、実装は進みトライアルが始まろうとしていることがわかる。

• Intent to Experiment: WebCodecs

また、その中で以下のような情報が入っている。

• Explainer: https://github.com/WICG/web-codecs/blob/master/explainer.md
• Design docs: https://docs.google.com/document/d/1fw3_aMB0-q9hOMuz_lxE8kEd-Z7vjA0wtklpx77m4yw/edit
• TAG review: https://github.com/w3ctag/design-reviews/issues/433
• Draft Spec: https://wicg.github.io/web-codecs/

これが調べていく起点となり、Intents が見つからなかった場合は、仕様のリポジトリなどを探すことになる。

中身を順に解説していく。

Mozilla Standard Position

Mozilla の Position についてまとまったダッシュボードがある。

• https://mozilla.github.io/standards-positions/

元々は、Chrome が進めている仕様に対して明確な No(Harmful) を示すために作られた印象があるが、今では様々な仕様のポジションがわかって便利だ。

ポジションのリクエストは誰にでもできるので、まだリストにないもので、Mozilla がどう考えているかを知りたい場合は、Issue を立てるところから始めることができる。

• https://mozilla.github.io/standards-positions/#web-codecs

逆に Issue を探してログを読めば、Mozilla のスタンスがより細かく把握できる。

Webkit Position

Safari の場合は特にページがあるわけではなく、主に webkit-dev の ML で、Chrome 開発者が "Request for Position" というタイトルの投稿をして聞いているというのが現状だ。

なので、基本的に Chrome 開発者が必要に応じて投げており、網羅性はそこまでない。解答も付いたり付かなかったり、付いても Apple の人間ではないっぽい人のコメントだったりと、気をつけるべき点が多い。

• https://lists.webkit.org/pipermail/webkit-dev/2020-May/031191.html

筆者は、キーマンとして "Ryosuke Niwa" さんの返事に注目している。

Developer Position

よく Developer: Positive と書かれている Intents を見るが、誰がどこで賛同したのか不明なものが多い。

RFC

例えば WebSocket の場合で見てみよう。WebSocket は既に RFC になっており RFC 6455 がそれにあたる。

• https://tools.ietf.org/html/rfc6455

RFC が出ていればそれを読めば良い。が、読み始める前にかならず確認すべきヘッダが 3 つある。

• Errata Exist
  • GitHub でいう Issue ページ、RFC が出た後に見つかった誤字脱字や仕様のバグなどが報告されている。
  • RFC 自体は一度出たら修正されないので、ここに Errata が溜まったら、別の RFC として更新版が出るが、なかなか出ないものが多い。
  • 特にこれから実装しようとか、仕様の細部を確認するような場合はかならず確認するべき。仕様が常に正しいとは限らない。
  • 逆に仕様で間違っていたり誤字脱字を見つけたらここから報告する。
• Obsolete by
  • このリンクがある場合は、この仕様の改訂版があり、それによりこの仕様が古くなったことを意味する。
  • 基本は最新版を見ればよい。
• Updated by
  • Obsolete ではないが、部分的に改定したものや、拡張の RFC があることを示す。
  • RFC 6455 WebSocket の場合は、RFC 8443 Bootstrapping WebSockets with HTTP/2 などが Update している。
  • 必ずしも Update 先を見るとは限らない。

また、ヘッダ部分 [draft-...] のリンクをクリックすると過去のドラフトを見ることができる。新しい技術を調査するのであれば、まだ RFC は出ていないと思われるため、ドラフトの見方も確認しておこう。

WG Draft

RFC 6455 の 1 つ前のドラフトは以下だ。

• https://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-17

これは、WebSocket を策定する Working Group である Hybi (hypertext bidirectional) で議論された RFC になる前のドラフトだ、バージョンが 00 ~ 17 まであり、18 相当が RFC になったことがわかる。

URL を見ると、IETF の hybi が策定している the websocket protocol の v17 であることが読み取れるだろう。

ドラフトを見たときにまず最初にやるべきことは、そのドラフトが最新かどうかだ。古いドラフトには新しいドラフトの数字リンクがない場合がある。しかし、ドラフトの URL は最後が必ずバージョン番号で、ここ(-17)を省略すると自動で最新にリダイレクトされる仕組みになっている。読んでたのが古かったということがたまにあるので、筆者はとりあえず最初にそれをやる癖をつけている。

個人 Draft

そのヘッダ部分には、更に古いドラフトへのリンクがある。

• https://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-76

これは、Hybi WG で議論する前に WebSocket の最初のデザインを書いた Hixie (Ian Hickson) 個人のドラフトだ。

このようにドラフトは最初個人が書き始め、議論を重ねた結果 WG で扱うべき(みんなで広く議論すべき)となったら、WG のアイテムとして採用される。

ドラフトの状態

ここまでのことがわかると、例えば以下のようなドラフトを見たときに読み取れる情報はこうなる。

• https://tools.ietf.org/html/draft-ietf-quic-http-32

• QUIC WG で議論されている
• HTTP3 のドラフトで v32 まで更新されている
• 元々は Google の R Shade が書いていたが、今は Akamai の M Bishop が Author

特に WG の把握は、後述する議論の場所や IETF のまとめを探す際などに重要だ。

議論の場所

ヘッダ上部にある [WG] というリンクから QUIC WG の作業全体が把握でき、そこにある [List Archive] というリンクが ML になる。

IETF は基本的には ML で議論行われ、ここを遡るとどんな議論があるのかわかる。全部見るのが大変な場合は、ドラフトに関わるキーマンを見つけ、その人の返信を見るだけでも役に立つ。

• https://mailarchive.ietf.org/arch/browse/quic/

また QUIC のドラフトには、ドラフト内に GitHub へのリンクがあるように、最近は GitHub で管理されることも増えた。

• https://github.com/quicwg/base-drafts

GitHub の運用はドラフトによってまちまちで、Issue / PR を受け付けるものや、単なるホスティングで議論は ML でやるように促すものもあるので、README をよく読んでから行動したい。

IETF MTG

IETF は、年に 3 回みんなで集まって議論する総会を開催している。参加料さえ払えば誰でも出られるが、少し追うくらいなら、WG のミーティングのログを追う方法を押さえておくとよいだろう。

ちょうど今 IETF109 がオンライン開催されており、IETF のページからそこに飛ぶ。

• https://www.ietf.org/how/meetings/109/

そこに Agenda (HTML) というリンクがあるので、ここでスケジュールがわかる。WG によっては IETF でミーティングを開催しないこともあるので、必ずあるとは限らない点には注意したい。

QUIC であれば以下のようにアレンジされていることがわかる。

• https://datatracker.ietf.org/meeting/109/materials/agenda-109-quic-00

開催方法も WG によってさまざまだが、基本は開催前に Agenda(予定表) と開催後に Minutes(議事録)が出るのは大体共通している。Minutes には使われたスライドのリンクなども載るので、とにかく Minutes を探せば直近までの議論のまとめがわかるだろう。

Draft

W3C の Draft には段階があるが、解説すると長くなるので、良くわからなければとりあえず最新を見ておけば良い。(逆に中途半端に古いものを見ても良いことはあまりない)

ドラフトを見るとき、まず最初にするのはヘッダ部分の確認だ。

例えば CSP で言うと、検索すると以下の様にいくつかの URL が見つかるかもしれない。

• https://www.w3.org/TR/2016/WD-CSP3-20160913/
• https://www.w3.org/TR/CSP3/
• https://w3c.github.io/webappsec-csp/

w3c には仕様にスナップショットを打つプロセスがあるが、とにかく最新を見たい場合は、ヘッダにある [Editor's Draft] というリンクの URL を見ると良いだろう(上のリストだと最後のもの)。これが、著者が作業している Working Copy となる。

また、ここで GitHub のリポジトリも確認できることが多い。

WG

CSP の場合は Feedback のところに public-webappsec と書かれていたが、これが W3C における Working Group になる。

• https://www.w3.org/2011/webappsec/

ここにいくと、他のドラフトや ML のリンクが探せるだろう。

Working Group のリストは以下にある。

• https://www.w3.org/groups/wg/

名前からだいたい何をやってそうかわかるだろう。

WICG

前述の WG にまだ属してないもの、もっと早い段階のものは、個人が提案として書いて、その後に WICG という Incubation のグループで議論されることもある。

例えば WebCodecs はまだ WG が無いため WICG で管理されている。

• https://wicg.github.io/web-codecs/

WICG のリポジトリは全部 GitHub にあるため、ここは比較的新しい仕様が集まっていることになる。(Portal, Display Locking, WebUSB etc)

• https://github.com/wicg/

WICG でもう 1 つ知っておきたいのが Discourse だ。

• https://discourse.wicg.io/

ここは、質問や提案をわりと自由にできるフォーラムになっており、例えば「こういう仕様が欲しい」とか「これについて聞きたいけどどこで聞けばいいかわからない」といった場合に、とりあえずここに投げてみると良いだろう。

TPAC

TPAC は一年に一度開かれる W3C の総会だ。W3C は会員じゃないと入れないため、自分の所属する会社が会員だったりしない限り参加は難しい。しかし Minutes や Slide は基本的に公開されるため、議論を追うことは可能だ。

TPAC のスケジュールのページを見つけると良い。

• https://www.w3.org/2020/10/TPAC/breakout-schedule.html#calendar

あとは見たいトピックの会議の Minutes を見つければ、スライドのリンクなどもあるだろう。

Proposals

機能の提案は以下のリポジトリで管理されている。

• https://github.com/tc39/proposals

Stage が 0 ~ 4 まであり、以下のようになっている。

• https://tc39.es/process-document/

特に Stage 4 になる条件として、最低 2 つの実装が必要なので、例えば v8 だけで動いても 4 にはならない。他のベンダに実装の意図が無ければそこから先に進まないこともありえる。

策定が進まなければ Inactive として終わっていくので、Stage に載ってるものが(たとえ Stage 3 でも)そのまま ECMAScript の仕様に入るとは限らないため、記事やブログを書くときは注意したい。

ECMAScript

Stage 4 を卒業すると、ECMA262 の仕様に取り込まれる。現在は年 1 回更新され、例えば今年なら ES2020 といて公開された。

この時点では少なくとも 2 つの実装では動いているはずだが、全てのブラウザで動くといった保証があるわけではない。

TC39 Meeting

TC39 のミーティングは、以前は奇数月に開催されていたが、作業が増えたため人を増やし開催が増えている。

いつ開催するかは、Agenda のリポジトリを見るとわかる。

• https://github.com/tc39/agendas

ここで、議題などが把握できる。

終わったら、Minutes が以下に公開される。リポジトリが別なこととちょっとラグがあることには注意だ。

• https://github.com/tc39/notes

ミーティングで作業が進めば、Stage の変更がある。そのあたりも note から確認できる。