[翻訳] Houdini: まだ聞いていません!これは CSS_html/css_WEB-ITnose で次に面白いことかもしれません

翻訳者: 実際...これがおそらく私を最も興奮させる機能だと思います...しかし、頭痛も怖いです...元のリンクを添付します

新しい CSS 機能を使用したいと思ったが、ブラウザがこの機能を完全にサポートしていないため、最終的には断念したことはありませんか?さらに悪いことに、ブラウザはすでにそれをサポートしていますが、問題がたくさんあります。皆さんもこういった状況に遭遇したことがあるのではないでしょうか。上記の状況に遭遇したことがある場合は、Houdini について心配する必要があります。

Houdini は、w3c の新しいタスク チームです。彼らの最終目標は、上記の問題を解決し、ブラウザーが新しい CSS 機能をより迅速にサポートできるようにすることです。このプロジェクトは、一連の新しい API を提供し、開発者が CSS 自体の機能を拡張できるようにすることを初めて試みています。フックを通じて、ブラウザーのレンダリング プロセスを操作できます。

フック 簡単に説明すると、フックとは英語でフックと訳され、プログラムの特定の位置に予約されたプログラムコードを埋め込んで、対応する他のプログラムコードを呼び出すことを指します。これは、特定のクリップ内の位置を空けることと大まかに考えることができます。後でこの位置にアクションを配置することもできますが、それは問題ではありません。

しかし、これは具体的に何を意味するのでしょうか?これは本当に良いアイデアでしょうか?そして、これは私たちの開発プロセスにどのような助けとなるでしょうか。

この記事では、これらの質問に答えていきます。しかしその前に、まず今日私たちがどのような問題に直面しているのか、そしてなぜこれらの変更を加える必要があるのか​​を理解する必要があります。次に、Houdini とは何か、そして Houdini がこれらの問題をどのように解決するかについてさらに詳しく説明し、現在開発中の興味深い機能のいくつかをリストします。最後に、より具体的な例をいくつか図解で示します。

Houdini はどのような問題を解決しようとしていますか?

新しい CSS 機能を紹介する記事を書くたびに、誰かが「これはすごい！」とコメントしますが、これを理解できるようになるにはあと 10 年かかるかもしれません。非建設的なメッセージ... 過去の歴史から判断すると、機能の提案から広く採用されるまでには確かに数年かかります。最も重要な理由は、CSS に新しい機能を追加する唯一の方法が、次の標準プロセスを介することであるということです。

ブラウザ自体が関与しすぎているため、このような処理には異論はありません。もちろん、これには長い時間がかかることも承知しています。たとえば、フレックスボックスは 2009 年に初めて提案されましたが、サポートされているブラウザが不十分であることに開発者が不満を抱いているのを今でも見かけます。ほとんどすべてのブラウザが自動的に更新されるため、この問題は徐々に解決されていますが、モダン ブラウザであっても、機能の提案から実際に機能が使用されるまでにはまだ長い時間がかかります。

興味深いのは、Web 分野のすべてがこの状況にあるわけではないということです。最近の Javascript と、なぜ Javascript がこれほど急速に開発できるのかを見てみましょう。

より。上の写真 このプロセスでは、提案を概念化して実際に製品に使用するまでに数日しかかからない場合もあります。例: 製品ですでに非同期/待機機能を使用しています。この機能はブラウザでもまだサポートされていません。

また、JavaScript コミュニティでは更新速度が速すぎるという不満の声が聞こえ始めていますが、CSS コミュニティでは主に多くの不満が見られます。あまりにも多くのことを学んでも無駄であり、それを使用するには時間がかかると不平を言う人。

では、なぜ CSS ポリフィルを使用できないのでしょうか?

JavaScript のプロセスを読んだ後、最初に直感的に思ったのは、CSS にも Polyfill を提供する必要があるということです。Polyfill があれば、CSS も Javascript と同じくらい早く進化できるのではないか、ということです。残念ながら、これは想像するほど簡単ではありません。古いテクノロジーを使用して CSS に新しい関数や API を実装することは非常に困難であり、ほとんどの場合、パフォーマンスが完全に犠牲になります。

JavaScript は動的言語です。つまり、JavaScript を使用して Javascript をポリフィルに置き換えるのは比較的簡単です。 CSS については、ポリフィルに CSS を使用することはほとんどありません。一般に、トランスレーターは、PostCSS などの CSS を生成するために使用されます。ポリフィルを DOM 構造または要素のレイアウトと位置に直接追加する場合は、対応するロジック プログラムをクライアントで実行する必要があります。

残念ながら、ブラウザにはこれを行う簡単な方法がありません。

下の図は、HTML ファイルを受信して​​画面に表示するまでのブラウザのプロセスを簡単にまとめたものです。青いブロックは、JavaScript が結果を制御できるキーポイントです

上の図では、開発者として、ブラウザーが HTML と CSS を解析して DOM と CSSOM に変換するプロセス、特にブラウザーのレイアウトと要素のレンダリングをほとんど制御できないことがわかります。このプロセスで制御できるのは DOM へのアクセスだけです。代わりに CSSOM を開く時期が来ましたか?しかし、最初に、Houdini Web サイトで言及されている改善された CSSOM 部分について触れておきます。これは、一貫性のないブラウザ間の動作と主要な機能の欠如を確認するものです。

主要な機能の欠如に関しては、たとえば、ブラウザーの CSSOM はクロスサイト アクセスのスタイル ルールを表示せず、理解できないスタイルを直接無視します。これは、次のような場合にも同様です。ブラウザーでサポートされていない機能を追加する場合は、CSSOM を使用できません。代わりに、DOM を使用して c9ccee2e6ea535a969eb3f532ad9fe89 と c9e517d0a46daf2dde2353185acb8aeb を見つけ、CSS を自分で取得し、解析して DOM に戻す必要があります。もちろん、DOM を更新するということは、通常、ブラウザがプロセス全体を再実行する必要があることを意味します。

プロセス全体の再レンダリングは、それほど重大なパフォーマンスの問題を引き起こすようには見えませんし、これは一般的な状況である可能性さえありますが、スコール ウィンドウなどに対処する必要がある場合は、マウスのサイズを変更する キーボード イベントの場合、多数の更新により明らかに速度が低下する可能性があります。さらに悪いことに、ほとんどの CSS ポリフィルには独自の解析メソッドとアプリケーション ロジックがあり、解析と適用は非常に複雑なものであるため、これらのポリフィルは通常、非常に太るか、エラーが発生しやすいものになります。

上で述べたことを要約すると、この段階でブラウザーにレンダリング時に異なる動作をさせたい場合は、DOM を利用して調整する必要があります。

しかし、なぜブラウザ内のレンダリング エンジンを変更する必要があるのでしょうか?

私にとって、これは間違いなくこの記事全体の答えとなる最も重要な質問です。これを見た人は、この部分をよく読んでください。

これを見て、「これはまったく必要ありません」と思う人もいると思います。私は通常の Web ページを構築しているだけです。ブラウザの内部には手を加えたくないのです。そう思われる場合は、一度立ち止まって、これまで開発に使用してきたテクニックを検討してみることを強くお勧めします。ブラウザのスタイル設定プロセスへのアクセス権とフックを取得することは、素晴らしい Firepower ディスプレイを作成するためだけではありません。主に、開発者とフレームワーク作成者に、次の 2 つのことを完了するためのより多くのソリューションと機能を提供することです。 🎜>

クロスブラウザー スタイルのさまざまな動作を統一します

• 新しい機能を開発するか、互換性の問題を解決します - これらの新しいテクノロジをすぐに使用できるように、新しい機能にポリフィルを追加します

• jQuery などのライブラリを使用したことがある場合は、すでにこの機能の恩恵を受けているでしょう。実際、これは今日のほとんどのフロントエンド フレームワークやライブラリの主なセールス ポイントでもあります。 Github で人気のある 5 つの Javascript プロジェクト (AngularJS、D3、jQuery、React、Ember) はすべて、さまざまなブラウザー間の動作に関する多くの問題に対処しています。

しかし、これは Javascript の部分です。次に、CSS とすべてのクロスブラウザーの問題について考えてみましょう。 Bootstrap や Foundation などの最も人気のある CSS フレームワークでさえ、ブラウザ間の互換性の問題に完全には対処しておらず、問題を回避しているだけであると述べています。クロスブラウザーの CSS バグは過去に存在しただけでなく、現在でも flexbox` のような問題が存在します。

CSS スタイル ルールによってどのブラウザでも一貫した動作が保証されたら、私たちの開発生活はどれほど素晴らしいものになるだろうか、想像してみてください。さらに一歩進んで、CSS グリッド、CSS Sanp ポイント、スティッキー ポジショニングなど、ブログ、カンファレンス、ミートアップの新機能をご存知の場合は、Github からコードをダウンロードするだけで、今すぐ使用を開始できます。

これが Houdini の理想です。その未来こそがワーキンググループが達成しようとしているものです。これらのポリフィルをまったく書きたくないと言っても問題はありませんが、おそらく使用したいと思うでしょう。 ?結局のところ、誰かがポリフィルを書いている限り、私たちは彼らから助けを得ることができます。

では、現在 Houdini ではどのような機能が開発されているのでしょうか?

上で述べたように、この段階では、開発者はブラウザのレンダリング プロセスに対してアクセス制御を行う機会があまりありません。DOM から始めることしかできません。

この問題を解決するために、Houdini チームは、開発者がレンダリング プロセスの他の部分を制御できるようにするための新しい仕様を推進する予定です。以下の図は、開発者が作業できる新しい仕様の部分を示しています。仕様内の灰色の部分は計画されていますが、まだ仕様には書き込まれていないことに注意してください。

以下では、それぞれの新しい仕様を紹介し、その機能について説明します。完全なリストについては、Houdini ドラフトをチェックしてください。

CSS パーサー API

CSS パーサー API はまだ仕様に書き込まれていないため、ここで言及されているものは変更される可能性があります。しかし、基本的にそのコンセプトは、開発者が CSS パーサーを拡張し、新しいメディア構文、新しい疑似クラスなどの新しい構文構造を提供できるようにすることです。

パーサーが新しい構造を認識すると、それを CSSOM に正しく適用できます。

CSS Properties and Values API

CSS にはすでにカスタム プロパティの機能があり、前の記事で説明したように、私はそれについて非常に興奮していました。 CSS プロパティと値 API はさらに一歩進んで、カスタム プロパティに加えて入力可能になります。

タイプを追加することには多くの利点がありますが、一般的に言えば、最大のセールス ポイントは、開発者がトランジションとアニメーションをカスタマイズできることです。これは今日では不可能です。分からない！ ?次の例を見てください。

body {  --primary-theme-color: tomato;  transition: --primary-theme-color 1s ease-in-out;}body.night-theme {  --primary-theme-color: darkred;}

上の例では、night-theme クラスが 6c04bd5ca3fcae76e30b72ad730ca86d 要素に追加されている場合、--primary-theme-color 属性の値はトマトからダークレッドに変換するページで参照されます。次の例

p {  color: var(--primary-theme-color);}

この段階でこの関数を完了するには、各要素のトランジションを記述する必要があります。これは、トランジション効果が属性ではなく要素に従うためです。もう 1 つの興味深い機能は登録フックです。これは開発者にカスタム プロパティの最終値を変更する方法を提供します。これはポリフィルで使用すると非常に実用的です。

CSS Typed OM

CSS Typed OM は、おそらく CSSOM の現在の 2 番目のバージョンの概念です。目的は現在の CSS モデルの問題を解決することであり、CSS パーサー API と CSS プロパティと値 API に追加された新機能も含まれます。

Typed OM のもう 1 つの主要な目標は、パフォーマンスを向上させることです。 CSSOM で現在使用されている文字列値を意味のある型に変更すると、JavaScript 操作のパフォーマンスが大幅に向上します。

CSS レイアウト API

CSS レイアウト API を使用すると、開発者は独自のレイアウト モジュールを作成できます。レイアウト モジュール経由とは、あらゆるものを表示プロパティに渡すことができることを意味します。開発者が、display: flex や display: table などのさまざまなモジュールを使用してネイティブにレイアウトを変更する方法を実現するのはこれが初めてです。

たとえば、Masonry Layout や Waterfall レイアウトなどの複雑なレイアウト手法は、今日では CSS だけで完成させることは不可能です。結果は素晴らしいものですが、残念なことに、特にローエンドのデバイスでは、パフォーマンス関連の問題が頻繁に発生します。

CSS レイアウト API を使用すると、開発者は registerLayout メソッドを通じてレイアウト名を登録し、JavaScript クラスを使用してロジックを編成できます。以下は簡単な例です。

registerLayout('masonry', class {  static get inputProperties() {    return ['width', 'height']  }  static get childrenInputProperties() {    return ['x', 'y', 'position']  }  layout(children, constraintSpace, styleMap, breakToken) {    // Layout logic goes here.  }}

上記の例の意味が分からなくても、心配しないでください。最も重要なことは、他の人が書いた masonry.js を見つけて CSS で使用するだけで、以下の例のように使用できることです。

body {  display: layout('masonry');}

CSS Paint API

CSS Paint API は Layout API によく似ていますが、 registerPaint メソッドを提供します。開発者は、CSS のPaint() 関数を使用して、名前を渡すことで CSS 画像を生成できます。これは色付きの円を描画する簡単な例です

registerPaint('circle', class {  static get inputProperties() { return ['--circle-color']; }  paint(ctx, geom, properties) {    // Change the fill color.    const color = properties.get('--circle-color');    ctx.fillStyle = color;    // Determine the center point and radius.    const x = geom.width / 2;    const y = geom.height / 2;    const radius = Math.min(x, y);    // Draw the circle \o/    ctx.beginPath();    ctx.arc(x, y, radius, 0, 2 * Math.PI, false);    ctx.fill();  }});

CSS の使用法は次のとおりです

.bubble {  --circle-color: blue;  background-image: paint('circle');}

ここで .bubble 要素を適用すると、青い円の背景画像が生成されます。円は要素と同じサイズで中央に配置されます。

ワークレット

上記の仕様といくつかの例に関して、それらをどこに配置するか疑問に思われるかもしれません。答えはワークレット スクリプトです。ワークレットは Web ワーカーに似ており、スクリプト ファイルをインポートし、さまざまな段階で Javascript コードを実行できます。また、メインの実行スレッドに依存しません。パフォーマンスを確保するため、ワークレットスクリプトは操作できる種類を厳しく制限します。

スクロール効果とアニメーション

スクロール効果 (スクロール) とアニメーションに関する公式仕様はありませんが、これは Houdini で最も期待されている機能の 1 つです。最終的な API により、開発者はメイン スレッドではなく、実行の組織化を担当するワークレットにプログラム ロジックを配置できるようになります。これは、いくつかの DOM プロパティの変更をサポートします。こうすることで、すべてのプロパティを再レンダリングするのではなく、特定のプロパティのみを更新できます。

このようにして、開発者は、スティッキー スクロール ヘッダーや並行スクロールの視差効果など、高性能のスクロールおよびアニメーション アプリケーションを簡単に作成できます。これらの API が解決しようとしている問題については、ユースケースで学ぶことができます。

正式な公式仕様はありませんが、Chrome では実験的な開発がすでに進行中です。実際、Chrome チームは現在、これらの主要な API を使用して CSS スナップ ポイントとスティッキー配置を実装しています。これは、Houdini API が Chrome の新しい機能に採用されるほど強力であることを意味するため、驚くべきことです。

Houdini のパフォーマンスの問題がまだ心配な場合は、次のビデオとソース コードを参照してください。

今何ができるでしょうか?

上で述べたように、すべての Web サイト開発者は Houdini に注目する必要があると思います。これは私たちの開発生活をより良いものにする未来です。 Houdini 仕様で定義されたものを直接使用しない場合でも、ほとんどの場合、その上に構築された多くのものを使用することになります。この未来はまだ到来していませんが、私たちが思っているよりも早く到来するかもしれません。

すべての主要なブラウザ メーカーは 2016 年初めにシドニーで対面会議を開き、Houdini の構築と開発についてはあまり反対しませんでした。 Houdini が次のメジャーになるかどうかはもはや問題ではなく、いつインポートするかが問題であると言えます。

もちろん、ブラウザ ベンダーにはこれらの新機能を構築するための独自の優先順位があり、通常はユーザーが緊急に必要とする機能を優先します。したがって、このスタイルとレイアウトの拡張に関心があり、ブラウザー開発者が長い開発プロセスを経るのを待たずに CSS の新機能を使用できるようにしたい場合は、関連する開発メンバーにこの機能が必要であることを伝えてください。

一方、実現したい機能であるが、今日のテクノロジーでは実装が非常に難しい、現実世界のユースケースをいくつか提供することができます。この Github プロジェクトには、すでにいくつかの例がリストされています。プル リクエストを送信することでコラボレーションに参加できます。

Houdini 開発チームは、Web 開発者から実際のニーズや質問を集めて、これらの機能をより完全で思慮深いものにしたいと考えています。なぜなら、仕様開発に携わるエンジニアは通常、ブラウザのみに注目しており、アプリケーション開発者の悩みの種を知らないからです。彼らにそれを伝えるかどうかは私たち次第です。

参考リソース

• CSS-TAG Houdini Editor ドラフト - W3C 最新ドラフト

• CSS-TAG Houdini タスクフォース仕様 -公式 Github プロジェクト

• Houdini サンプル - 実験例

• オリジナルソース