夢のある話だな〜ということでHoudiniが気になっています。
ので、Philip Walton氏の承諾を得て『Houdini: Maybe The Most Exciting Development In CSS You’ve Never Heard Of 』By Philip Walton(2016/03) の日本語訳をしました。
「この訳ちげぇよ！」という部分ありましたら豊かな顔文字で優しく教えてもらえると喜びます( ´ ω ` )
Houdini:CSSにおいて初めて聞くであろう、おそらく一番ワクワクする進化だよ
とあるCSSの機能を使いたいけど、ブラウザでサポートされてないから使えない、という経験はないだろうか？あるいはサポートはされているけどバグが多く、一貫性も互換性もないため使い物にならない...なんていうことは？
もしそういう経験があるなら（きっとあるはず）、Houdiniについて関心を持ってみてほしい。
HoudiniはW3Cの新しいタスクフォースで、上述のような問題をなくすことを最終的な目標だ。開発者がCSS自体を拡張できる初めてとなるAPIと、ブラウザのレンダリングエンジンのスタイリングとレイアウトのプロセスに接続するツールを提供することによって実現しようとしている。
でもそれってつまりはどういうことだろうか？すごく良いアイデアなのか？我々開発者にとって、現在とこれからのWEB開発にどのように役立つのだろう？
この記事ではそのような疑問に応えようと思う。しかしまずその前に、現在何が問題で、何を変える必要があるのかを明らかにしたい。
それから、Houdiniがどのように問題を解決するのか、そしてHoudiniが持つWEB開発において画期的な特徴を何個か紹介しよう。
そして最後に、Houdiniを現実のものとするために、我々WEB開発者が今できる具体的なものを示そうと思う。
Houdiniは何を解決しようとしているのか？
CSSの新しい機能について紹介する記事を書いたりデモを作って見せると、誰かが*"すごい！でも実用できるのは10年先かな...。"*というコメントやtwitterで言ってるのをいつも目にする。
コメントにあるような苛立ちや建設的じゃない感情を私も理解している。昔から、ある機能が広く採用されるまで非常〜に長い時間がかかっていた。なぜなら今までのWEBの歴史の中で、CSSの新しい機能が採用されるには標準化過程を踏むしかなかったからだ。
でも標準化過程に反感を持っているわけではないし、時間が長くかかることを否定する気はないよ。
例えばflexboxは2009年に提案されたけど、開発者は未だにブラウザサポートが十分じゃないから使えないと嘆いている。
モダンブラウザのほとんどが自動アップデートをするから、この問題は緩やかに解決していることは認めよう。しかしモダンブラウザでさえも、新機能の提案から実用可能になるまでの間にタイムラグがある。
面白いのは、これはWEBのすべての領域で起こっているわけではないということだ。JavaScriptではどうなっているか見てみよう。
このシナリオだと、アイデアを実際に使えるようにするまでに数日しかかからないときだってある。まだどのブラウザでも実施されていないのに、我々はすでにasync/awaitを使ってるだろう？そういうこと。
２つのコミュニティ間では、感情もまったく違う。
JavaScriptのコミュニティでは「流れが早すぎる...。」と文句を言っている記事を見ることだろう。一方CSSでは、新しい機能が実際に使えるようになるのに多大な時間がかかるため、新しいことを学ぶことの不毛さを嘆く声が聞こえるはずだ。
じゃあなんでCSSのポリフィルを書かないの？
もっとCSSのポリフィルを書けばいい、と最初は思うだろう。良いポリフィルがあれば、CSSはJavaScriptと同じくらい早く進化することができるはず、だよね？
しかし悲しいかな、事はそんなに単純じゃない。CSSをポリフィルするのは信じられないくらい難しいし、だいたいの場合、パフォーマンスを犠牲にせずには不可能だ。
JavaScriptは動的な言語だ、それはつまりJavaScriptをポリフィルするためにJavaScriptを使うことができるということ。そして動的だからこそ、JavaScriptはとても拡張しやすい。
一方、CSSをポリフィルするためにCSSが使われることはめったにない。場合によっては、（PostCSSがやってるように）ビルドするときにCSSをCSSにトランスパイルすることはできるけどね。しかし、もしDOM構造や要素のレイアウト・ポジションに依存するものをポリフィルしたいなら、クライアントサイドでポリフィルロジックを走らせないといけない。
残念なことに、ブラウザはこれを簡単にやらせてはくれない。
下の図は、ブラウザがHTMLを受け取ってスクリーンに表示するまでの基本的な流れをを示している。
青く塗られているステップは、JavaScriptが結果をコントロールする力を持つ場所を示している。
この図は非常に希望がない。なぜなら、どうやってブラウザがHTMLとCSSをパースしてDOMとCSSOMを形成するかを、開発者はコントロールできないってことだからだ。
君はカスケードをコントロールできない。ブラウザがDOMの要素をどうレイアウトするか選ぶことも、どうやってその要素をスクリーンにペイントするかもコントロールできない。コンポジターが何をするかもコントロールできないんだ。
この中で君がアクセスできるプロセスはDOMに対してのみだけだ。
CSSOMはいくらかアクセス可能だが、Houdiniのサイトを引用するなら、それは*"仕様が曖昧で、ブラウザ間での一貫性がなく、重要な特徴が欠損している"*。
例えば、現在のブラウザのCSSOMはクロスオリジンスタイルシート(?)のルールを見せてくれないし、理解できないCSSルールや宣言は単純に捨てるだけだ。それはつまり、もし君がブラウザでサポートされていない機能をポリフィルしたいなら、CSSOMは使えないということを意味する。
その代わりに、DOMを通して<style>とか<link rel="stylesheet">を探し、自分でCSSを手に入れてパースし、リライトし、DOMに戻してあげないといけない。
もちろんDOMを更新するということは、すべてのカスケードを読み込み、レイアウトし、ペイントし、コンポジットするというすべてのステップをブラウザが再び行うということを意味する。
ページを完璧に再レンダリングすることは（あるサイトにとっては）パフォーマンスにそんなに大きな影響は及ぼさないように感じるかもしれない、しかしどれだけの頻度でこれが起こる可能性があるか考えて欲しい。
もし、スクロールイベント、ウィンドウリサイズ、マウスムーブメント、キーボードイベント - とにかく変更があるときすべて - に反応してポリフィルロジックが走るなら、それらの影響は大きく、壊滅的に遅くなることもあるだろう。
現在世にあるCSSポリフィルのほとんどが独自のCSSパーサーと独自のカスケードロジックを含んでいることに気づくと、より一層事態は悪くなる。なぜならパースとカスケードは実際とても複雑で、一般的にこれらのポリフィルは大きすぎるかバグが多すぎるかのどちらかだからだ。
私の言いたいことを端的にまとめるとこうだ： もしブラウザに普段の解釈と違うこと（自分が書いたCSSの内容）をして欲しいなら、自分自身でDOMを更新し変更を加えることによってブラウザをごまかす方法を見つけなければいけない。君は他のレンダリング経路にアクセスできないのだから。
しかし、一体全体なぜブラウザ内部のレンダリングエンジンに手を加えたいのか？
この質問は私にとって、この記事全体を通して答えたい一番重要な問いだ。もし今までのところをざっと目を通すぐらいだったのであれば、このパートはゆっくり、注意を払って読んで欲しい。
このセクションを読んだあとに君は*"別にこんなの必要ないわ〜！普通のWEBページを作っているだけだし。ブラウザ内部をハックしたり、何かすごく豪華で実験的な、最先端のものを作る予定もないし。"*と考えることだろう。
もし君がそう思うなら、ちょっと問題からすこし離れて、WEBサイトを開発するのに長年使っている技術を調査することを強くお勧めする。ブラウザのスタイリングプロセスにアクセスしようとすることは、単純に高機能なデモを作って見せびらかすためではない。開発者とフレームワーク制作者に、まずこの２つをするための力を与えようとしているんだ。
- ブラウザ間の差異の標準化
- 今日、すぐに使えるような新しい機能を開発あるいはポリフィルする
jQueryのようなJavaScriptライブラリを使ったことがあるのなら、その機能の恩恵を受けたことがあるだろう！実際、昨今のフロントエンドライブラリやフレームワークの大きな売りのひとつだ。GitHubで人気の5つのJavaScriptとDOMリポジトリ - AngularJS、D3、jQuery、ReactそしてEmber - は、開発者がそんなことを気にしなくてもいいようにブラウザ間の差異を標準化するために多くのことをなしている。それぞれは単一のAPIを提供し、問題なく機能している。
ここで、CSSとCSSにまつわるクロスブラウザ問題のもろもろを考えてみよう。ブラウザ間での互換性を主張するBootstrapやFoundationのような有名なCSSフレームワークであっても、実際にはブラウザ間のバグを標準化できていない。彼らはただそれを回避しているだけだ。CSSでのブラウザ間のバグは過去のことではない。今日でさえ、flexboxのように新しいレイアウトモジュールで我々はブラウザ間の互換性のなさに直面する。
最終的な結論は、もしどんなCSSプロパティも使えて、それがどのブラウザでも全く同じ挙動で動くことがわかっていたとしたら、どんなに素敵な開発者人生になるか想像して欲しい、ということだ。そしてCSS gridsやCSS snap points、そしてsticky positioningのような、ブログやカンファレンス、ミートアップで見聞きする新しい機能についても考えてみて欲しい。もしそれらの機能が今日、ネイティヴCSSの機能と同じ効率で使えたらどうだろうか。君はGitHubからコードを持ってくるだけでいい。
これがHoudiniの夢であり、このタスクフォースが実現しようとしている未来なんだ。
たとえ君自身がCSSポリフィルを書いたり実験的な機能を使う予定がないとしても、他の誰かにやっておいて欲しいはず。だって一度ポリフィルができてしまえば、誰もがそれらの恩恵を受けられるからね。
後半鋭意翻訳中です。