Houdini: CSS_html/css_WEB-ITnose の最もエキサイティングなイノベーション

元のリンク: Houdini: might The Most Exciting Development In CSS You've Never Heard Of

特定の CSS 機能を使用したいのに、ブラウザーの互換性の問題で使用できない場合は、さらに悪いことに、すべてのブラウザがこの機能をサポートしていますが、場合によっては、バグ、サポートの一貫性の欠如、または完全な非互換性が存在します。上記のような状況に遭遇したことがある場合は (きっと経験していると思います)、Houdini に注意を払う必要があります。

Houdini は W3C に新しく設立されたタスクフォースであり、その最終目標は CSS 属性の完全な互換性を達成することです。 Houdini は前例のないアイデアを提案しました。CSS API を開発者に公開することで、開発者はこの一連のインターフェイスを通じて CSS を自分で拡張でき、対応するツールを提供して、開発者がブラウザ レンダリング エンジンのスタイルとレイアウトのプロセスに介入できるようにします。 しかし...これはどういう意味ですか?この計画は信頼できますか?現在でも将来でも、Houdini は開発者による Wanzhan の開発をどのように支援できるでしょうか?

次の記事では、上記の 3 つの質問に全力で答えていきます。しかし、答えを始める前に、何が問題なのか、なぜ Houdini のようなソリューションが存在するのかを理解しましょう。問題が何であるかを理解したら、Houdini がそれらをどのように解決するか、そして現時点での状況を説明します。最後に、開発者の皆さん、Houdini をできるだけ早く実装するために何ができるかを学ぶこともできます。

Houdini はどのような問題を解決できますか?

記事を書いているときでも、デモを作成しているときでも、新しい CSS のトリックを披露したいと思うたびに、誰かがいつもこう言います。少なくとも10年は。」

そのようなコメントはいつも迷惑で非建設的だと思いますが、それでも皆さんの懸念には十分な根拠があることを認めます。 CSS の歴史を通じて、機能ドラフトが広く採用されるまでには何年もかかりました。 「何年も」という理由は、新しい機能を CSS 標準に書き込むには一連の標準設定プロセスが必要ですが、まだ何年も経っていないからです...

きっと基準設定のプロセスに異論はありませんが、すべてのプロセスを経ると花は枯れるということは認めざるを得ません。

flexbox はおそらく 2009 年に初めて flexbox のドラフトが提案されましたが、開発者は今日に至るまでこのプロパティのブラウザ互換性の問題について不満を抱いています。しかしありがたいことに、最新のブラウザの自動更新メカニズムにより、この問題はいつか解決されるでしょう。ただし、現在の新しいプロパティのリリース プロセスによれば、最新のブラウザと新しいプロパティの提案の間には依然としてタイムラグが発生します。

しかし、Web の世界でも、今日では JavaScript は問題ではないようです:

上記のフローチャートでは、新しい JS 機能の考案から実稼働環境での適用まで、おそらくそれが行われていることがわかります。数日しかかかりません。正直に言うと、私はすでに async と await を使用していますが、現在これら 2 つのメソッドをネイティブにサポートしているブラウザはありません。

ここまでで、おそらく CSS コミュニティと JS コミュニティのスタイルの違いを感じられたと思います。JS コミュニティでは、毎日同じだという人々の不満の声が常に聞こえます - 速く走りすぎ、追いかけすぎて疲れています; および CSS コミュニティでは、人々は新しいことを学ぶためにエネルギーを費やすことがどれほど感謝されていないかを嘆いていますが、新しいことがいつ使えるようになるかは神のみぞ知るです。

この場合、なぜ CSS Polyfill を使用できないのでしょうか?

CSS ポリフィルが十分に強力である限り、CSS が JavaScript よりも速く開発されることも夢ではないと思います。

しかし、CSS にパッチを適用することがどれほど難しいか想像するのは難しく、パッチを適用するとほとんどの場合、パフォーマンスに影響が出ます。

JavaScript は動的言語であるため、驚くべきスケーラビリティを備えており、JavaScript に JavaScript をパッチすることは簡単に実装できますが、CSS は動的ではありません。場合によっては、ビルド プロセス中に CSS の 1 つの形式を別の形式に変換できます (PostCSS が典型的な例です)。パッチが DOM 構造、特定の要素のレイアウト、またはその位置に依存している場合は、パッチをローカルで実行する必要があります。

残念ながら、このソリューションをブラウザに実装するのは困難です。

HTML ドキュメントがブラウザーで受信されてから画面に表示されるまでのプロセス全体を見てみましょう。下の図の青でマークされた部分に JavaScript が関与します。

開発者として。読者の皆さん、この写真を見ると、私たちはブラウザが HTML と CSS を解析するプロセスを制御することができず、ブラウザが DOM と CSS オブジェクト モデル (CSSOM) を生成するのを見ることしかできません。カスケード (カスケード) を制御する方法はなく、ブラウザーが要素をレイアウトする方法 (レイアウト) を制御する方法もなく、画面上に表示される要素のプロセス (ペイント) や最終的な構成 (コンポジット) を制御する方法もありません。 。

プロセス全体において、開発者が完全に制御できる唯一のリンクは DOM であり、CSSOM も部分的に制御できます。それでも、Houdini の Web サイトの言葉を借りれば、このレベルの露出は「互換性が一貫性がなく、主要な機能がサポートされていないため、不確実です」。

たとえば、ブラウザの CSSOM は、クロスオリジン スタイル シートをどのように処理するかを示しません。また、ブラウザが解析できない CSS ステートメントは解析しません。つまり、CSS ポリフィルを使用して次のことを行いたい場合ブラウザがまだサポートしていない属性をサポートする場合は、DOM ツリーを自分で解析して

DOM ツリーが更新されたため、ページをレンダリングする手順を再度実行します。

(上の図の括弧内のテキスト: JavaScript ポリフィルは DOM と CSSOM のみを変更できます。これらの操作のほとんどはページの再レンダリングを引き起こします。)

まあ、多分あなたはそう言うでしょう。この方法は選択の余地がありません。パフォーマンスに大きな悪影響を与えることはありません (一部の Web サイトではそうです)。しかし、ポリフィルがページ上のすべてのインタラクションを処理する必要がある場合はどうなるかを考えてください。スクロール イベント、ウィンドウのズーム、マウスの移動、キーボード入力...いつでもトリガーできる再レンダリングにより、ページのドラッグが信じられないほど遅くなり、ユーザーは間違いなくそれに気づきます。

さらに悪いことに...ほとんどの CSS ポリフィルには独自のパーサーと階層ロジックがあり、「パーサー」と「階層ロジック」は 2 つの非常に複雑なものであるため、これらのポリフィルのサイズはそれほど大きくありませんバグが多すぎます。

上記を簡単に要約すると、ブラウザに実行できないこと (スタイルを実装できるかどうかに関係なく、指定したスタイルを解析させるなど) をブラウザに実行させたい場合、干渉することはできません。他の処理はレンダリング プロセスのステップに含まれるため、DOM の更新と変更は手動でのみ行うことができます。

ブラウザ内のレンダリング エンジンを変更したい場合はどうすればよいですか?

この問題がこの記事の鍵だと思います。前の記事を読み飛ばした場合は、必ずここで終了してください。この部分を注意深く見てください。

上記のセクションを読んだ後、息が詰まってこう思った人もいると思います。「これは必要ありません。通常の方法でページを書きたいだけで、ブラウザのコアに侵入したくないのです」そして、いくつかの特に前衛的な効果を達成します。」

そう思うなら、ページ効果を実現するために長年にわたって使用してきたテクニックを検討してみることを強くお勧めします。ブラウザーの解析スタイルに「干渉」する目的は、私たちのスキルを誇示するだけでなく、フレームワークの作成者と開発者が次の 2 つのことを実行できるようにすることでもあります:

• ブラウザー間の差異を正規化する、
• クロスブラウザーを統一する
• 新しい機能を発明したりポリフィルして、人々がすぐに使えるようにするため
• 新しい機能を開発したり、新しい機能にパッチを当てたりして、人々がすぐに使えるようにします。

jQuery などの JS ライブラリを使用したことがある場合は、すでにその恩恵を受けているでしょう。実際、優れた互換性は、ほとんどのフロントエンド ライブラリとフレームワークのセールス ポイントの 1 つです。 Github で最も人気のある JavaScript および DOM リポジトリの上位 5 つは、AngularJS、D3、jQuery、React、Ember です。ただし、これらの API の使用方法を理解していれば、目的の目標を達成できます。その背後で、さまざまなブラウザとの互換性にどれだけの努力が費やされているかは、ユーザーがほとんど考慮したことがないことです。

次に、CSS に関するクロスブラウザーの問題について考えてみましょう。優れた互換性を主張する Bootstrap や Foundation などの CSS フレームワークでさえ、ブラウザのバグを標準化しているわけではなく、バグを回避しようとしているだけです。 CSS の互換性の問題が単なる古い問題であるとは考えないでください。フレックスボックスを例に挙げると、私たちは依然としてさまざまなブラウザ間の互換性の問題に直面しています。 (翻訳者注: フレックスボックスの互換性の問題は、主流のモバイル ページ開発で緩和されました。翻訳者はかつてモバイル HTML 5 ページのフレックスボックス効果の要点をまとめました。修正に使用することは歓迎されます)

想像してみてください。必要な CSS プロパティをすべて使用でき、ページはどのブラウザーでも想像どおりに表示されます (このキャリアを積めるのは何と嬉しいことでしょう。目に見える素晴らしいものです) グリッドなどのすべてのクールなプロパティは、パフォーマンスを保証せずに使用できますレイアウト (CSS グリッド)、配置 (CSS スナップ ポイント)、スティッキー配置...これらすべてを実現するには、Github からコードをダウンロードするだけです。ダウンロードするだけです

さて、上記は Houdini チームによる Houdini のブループリントです。この夢を実現したいと思っています

もしかしたら、CSS ポリフィルを書いたり、実験的な機能を開発したりすることを考えたこともないかもしれませんが、他の人がこれらのことを実行できることを願っています。結局のところ、これらのツールが利用可能になれば、すべての開発者が恩恵を受けることになります

。

Houdini の現在の進歩

先ほど、DOM と CSSOM の 2 つのリンクを除いて、開発者がブラウザのレンダリング プロセスに干渉するのは難しいと述べました。

Houdini チームは、この問題を解決するためにいくつかの新しい標準を導入し、開発者に他のいくつかのレンダリング リンクに介入する許可を初めて与えました。下の図は、各リンクに対応する新しい標準を示しており、開発者はこれらの標準を使用して対応するリンクを制御できます。 (注: 灰色のブロックはまだ実装中の標準であり、現在は利用できません。)

次のいくつかのセクションでは、それぞれの新しい仕様とその機能について簡単に紹介します。詳細については説明しません。他の仕様については、こちらをご覧ください。

CSS 解析 API

CSS パーサー API はまだ仕様に書き込まれていないため、以下で述べる内容はいつでも変更される可能性がありますが、その基本的な考え方は変わりません。開発者が CSS 字句解析ツールを自由に拡張できるようにすることで、新しいメディア ルール、新しい疑似クラス、ネスト、@extends、@apply などの新しい構成を導入します。

新しいレクサーがこれらの新しい構造を解析する方法を知っている限り、CSSOM はそれらを直接無視せず、これらの構造を正しい場所に配置します。

CSS のプロパティと値 API

CSS にはすでにカスタム プロパティがあると述べましたが、これは CSS によってどれほど多くの新しいスキルが解放されるか非常に興味深いものです。 CSS プロパティと値 API の登場により、カスタム プロパティがさらに促進され、さまざまなタイプのカスタム プロパティを追加できるようになり、カスタム プロパティの機能が大幅に強化されました。

カスタム属性にさまざまなタイプを追加するのは素晴らしいことですが、この API の最大のセールス ポイントは、開発者がカスタム属性に対してそれを実行できることです。動く！絵画！そして、現在のテクノロジーだけでは、それを行うことはできません...

次の例を見てみましょう:

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

night-theme クラスが

要素に追加されると、すべてのページには - -primary -theme-color の要素属性値は、トマトからダークにゆっくりと変化します。今すぐページでこの効果を実現したい場合は、要素にトランジション アニメーションを 1 つずつ追加するという労力が必要になります。

翻訳者注: パフォーマンスのことしか考えられないのはなぜですか? 結局のところ、body 要素の色が変更されているため、ページ全体を再描画する必要があるようです。しかし、繰り返しになりますが、テーマは変更されており、リフローも自然です

この API のもう 1 つのセールス ポイントは、「適用フック」を登録することです。つまり、開発者は、フックの最後にあるフックを介して変更を加えることができます。カスケード ステップ 要素のカスタム属性値。この機能はポリフィル開発にとって非常に意味があります。

CSS 型付き OM

CSS 型付き OM は CSSOM 2.0 として考えることができます。その目的は、現在のモデルのいくつかの問題を解決し、CSS 解析 API および CSS プロパティと値 API に関連する機能を実装することです。

パフォーマンスの向上は、Typed OM のもう 1 つの重要なタスクです。現在の CSSOM 文字列値を意味のある JS 式に変換すると、パフォーマンスを効果的に向上させることができます。

CSS Layout API

開発者は、CSS Layout API を通じて独自のレイアウト モジュール (レイアウト モジュール) を実装できます。ここでの「レイアウト モジュール」とは、表示の属性値を指します。つまり、この API の実装後、開発者は初めて CSS ネイティブ コード (display:flex、display:table など) のようなレイアウト機能を利用できるようになります。

Masonry レイアウト ライブラリでは、開発者がさまざまな複雑なレイアウトをどのように実装したいかがわかりますが、その中には CSS だけでは実現できないものもあります。これらのレイアウトは新鮮で印象的ですが、ページのパフォーマンスが低いことが多く、一部のローエンド デバイスではパフォーマンスの問題が依然として明らかです。

CSS レイアウト API は、開発者に registerLayout メソッドを公開します。このメソッドは、後で CSS で使用されるプロパティ値としてレイアウト名を受け取り、レイアウト ロジックを含む 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 と非常によく似ています。これは、 registerLayout メソッドと非常によく似た動作をする registerPaint メソッドを提供します。 CSS イメージを構築する場合、開発者はいつでもPaint() 関数を呼び出すか、登録したばかりの名前を使用することができます。

次のコードは、色付きの円を描画する方法を示しています:

registerPaint('circle', class {  static get inputProperties() { return ['--circle-color']; }  paint(ctx, geom, properties) {    // 改变填充颜色    const color = properties.get('--circle-color');    ctx.fillStyle = color;    // 确定圆心和半径    const x = geom.width / 2;    const y = geom.height / 2;    const radius = Math.min(x, y);    // 画圆    ctx.beginPath();    ctx.arc(x, y, radius, 0, 2 * Math.PI, false);    ctx.fill();  }});

CSS で次のように使用できます:

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

ページ要素の背景として青い円が表示されます。そのクラスは です。バブルの場合、この円形の背景は常に .bubble 要素を占めます。

ワークレット

仕様に関連するいくつかのコード (registerLayout や registerPaint など) を見てきましたが、ここで知りたいのは、これらのコードをどこに配置するかということだと思います。答えは、ワークレット スクリプト (ワークフロー スクリプト ファイル) です。

ワークレットの概念は Web ワーカーに似ています。ワークレットを使用すると、スクリプト ファイルを導入して特定の JS コードを実行できます。1 つ目は、レンダリング プロセスで呼び出すことができること、2 つ目は、レンダリング プロセスから独立していることです。メインスレッド。

ワークレット スクリプトは、開発者が実行できる操作の種類を厳密に制御し、パフォーマンスを保証します。

複合スクロールとアニメーション

複合スクロールとアニメーションに関する公式仕様はありませんが、これは Houdini プロジェクトのよく知られ、非常に期待されている機能の 1 つと見なすことができます。この API を使用すると、開発者は (メイン スレッドではなく) コンポジターのワークレットでプログラムを実行し、DOM 要素の属性を変更できるようになりますが、レンダリング エンジンがレイアウトやスタイルを再計算することはありません。変換、不透明度、スクロール オフセットなどのプロパティ。

開発者は、この API を使用して、スクロール ヘッド効果や視差効果などの高性能スクロールおよび入力アニメーションを作成できます。この API が達成しようとしていることの詳細については、Github で確認できます。

正式な仕様はまだ最終決定されていませんが、Chrome には実験的なツールが含まれています。実際、Chrome エンジニアは、これらの API が最終的に公開する言語プリミティブを使用して CSS スナップ ポイントとスティッキー ポジショニングを実装しています。これは何を示していますか? Houdini API のパフォーマンスは、Chrome がその上に新機能を実装することを納得させるのに十分です。これだけでも、パフォーマンスの問題に悩んでいた人なら納得できるはずだ。

Surma は、Twitter アプリケーションのヘッドスクロール効果をシミュレートするデモを YouTube でリリースしました。ソースコードはここでご覧いただけます。

それで、私たちは今何ができるでしょうか？

最初に言いましたが、すべての Web 開発者は Houdini に注目すべきだと思います。このプロジェクトは私たちの未来を大きく改善するでしょう。 Houdini 仕様に直接触れたことはなくても、多くの機能が Houdini 仕様に基づいて構築されるため、間接的にその利便性を享受できることになります。

ここで述べられている素晴らしい未来はまだ到来していませんが、それはあなたが思っているほど遠くありません。今年の初めに、すべての主要なブラウザ メーカーがシドニーで開催された Houdini のオフライン カンファレンスに代表者を派遣しました。その会議では、メーカーは Houdini の方向性と進捗について基本的に合意に達しました。

私の話から、Houdini の登場は時間の問題であり、間違いなく正式な仕様になると信じていただけると思います。

もちろん、すべての機能を一度に追加することは不可能です。機能の重要性の分類が必要です。この分割方法は、多くの場合、特定の機能に対するユーザーの要求に依存します。

したがって、ブラウザー上のスタイルとレイアウトのスケーラビリティを本当に重視している場合、および新しい CSS 機能がリリースされるとすぐにプロジェクトで直接使用できる世界に住みたい場合は、ブラウザ 開発者チームに連絡して、Houdini が本当に必要であることを伝えてください。

参加するもう 1 つの方法は、今は達成するのが簡単ではない、または不可能であるが、いつか CSS を使用できるようになりたいと考えている効果をリストすることです。W3C がユースケース ドキュメントを提供しているので、そのリポジトリに PR を送信できます。一部のブラウザでそのようなドキュメントが提供されていない場合は、ブラウザ用にドキュメントを作成することもできます。

Houdini プロジェクト チーム (そしておそらく W3C のすべてのメンバー) は、世界中の Web 開発者の声を聞きたいと考えています。実際、ブラウザを開発する多くの人自身はプロの Web 開発者ではありません。C++ プログラマが Web 開発者の悩みの種を理解するのは非常に困難です。

彼らは私たちを必要としています!

元のリファレンス

• CSS-TAG Houdini Editor ドラフト 、W3C

  CSS-TAG Houdini Editor ドラフト、W3C すべての Houdini ドラフトの最新公開バージョン

• CSS-TAG Houdini Task Force の仕様 、

  CSS -TAG Houdini Task Force の仕様 、GitHub 仕様の更新と開発が行われる公式 Github リポジトリ

• Houdini サンプル 、GitHub

  Houdini サンプル 、可能な API を紹介および実験する GitHub コード サンプル

• Houdini メーリング リスト 、W3 C

  Houdini メーリング リスト、W3C 一般的な質問をする場所

この記事をレビューしてくれた Houdini チーム メンバーの Ian Kilpatrick と Shane Stephens に特別に感謝します。

外国人ジャーナリスト「シリコンバレーに行かなくても、プログラマーとして再起を目指して戦いましょう〜」