2015/03/13: CSS Houdini と Extensible Web

Sep 11, 2017 #salvation

WebKit contributors meeting の Wiki を見ていたら "CSS Houdini" という単語が出てきて、なんだそりゃと思ってちょっと調べてみる。

と CSS とレイアウトやレンダリングに imperative な API をつけようというウェブ標準話らしい。こんなのやってんだな。WebKit で話がでるくらいだから Google だけでなく MS, Mozilla, Apple も巻き込めており、出だしは順調げ。まあ問題が超絶手強いので先は長そうだけど、がんばってほしいもんです。

こうやって話が進むのを見ると、Extensible Web Manifest は結構良い宣言だったのではと思う。Alex Russel の一味はいい仕事をした。Web Components の仕事は色々辛かったけれど、こういう発展の萌芽となったと思えばまあ、報われないでもない。

Alex Russel が Web Components (当時はコードネームで呼ばれており、この名前がついたのはちょっとあと)とか言い出したのは 2011 年。ある朝ミーティングに呼び出されて VC 越しで話を聞き、入社して日が浅かった自分は「次はこれをやれってことなんだな」と理解して何となく Shadow DOM まわりの実装を手伝い始めた。今思えばあれは単なる売り込みであって、別に手伝わなくても良かったのだが。(基本的にそういうトップダウンの任命はない。実際、同席した同僚はスルーしていた。）

Web Components は当初それほど extensibility を強調してはおらず、むしろ「俺はこうやって JS ライブラリを書きたいのにかけないのはおかしい」というやや中二っぽいフラストレーションに導かれていた（ように見えた）。クールに書きたいその気持ちを突き詰めた結果、APIのレイヤリングが狂ってるのがおかしいからそれをなんとかすべきという主張に辿り着き、Extensible Web のアイデアが生まれたのだろう。そして、高レベルな APIから作ると失敗した場合にダメージがでかい（ウェブ標準は引き返せない）ことだし低レベルなAPIから揃えていきましょうという合意が生まれ、Service Workers が生まれ、Web Animations のドラフトからは当初含まれていた SMIL みたいなマークアップ定義が消えた。CSS Houdini も「実装を晒しすぎない程度に低レベルな API を定義しよう」というメガネでみると自然に見えると思う。

こうした学びの代償として Web Components には「クールに書きたい」の残滓があり、それらはチームを苦しめた/苦しめている。Shadow DOM の特別なセレクタ、宣言的な “Distribution” のコンセプト、あとは HTML Imports まるごと。こいつらは強力な機能なのだが、特にブラウザの低レベルな API を公開してはいない。だから仕様の議論も終わらない(好みが入り込みやすいから)し、実装も複雑になったりする。最初から Extensible Web のアイデアがはっきりしていたのなら、また違ったものができたに違いない。とはいえ the sail has shipped なのだった。

Extensible Web の視点に経つと Polymer の役割にも功罪ある。API の実用性をドッグフードして弱点を暴き出すのを手伝った一方、API の使い勝手に重心を動かしもした。先送るはずだった「クールさ」を再びプロジェクトに持ち込んだ。結果としてチームは API からクールさを殺すことが出来なかった。

もっともこれは Polymer が悪いというより、ユーザの要求をプラットホームの視点で解釈しなおすことができなかった開発者（自分とか）の責任という方が筋が通っている。そこはごめんなさいというしかない。ごめんなさいね。ほんとに。僕は疲れ果てて撤退しちゃったけど、まだやってる人たちは後始末のために色々考えてると思います。