ホームページ > ウェブフロントエンド > htmlチュートリアル > Houdini: CSS_html/css_WEB-ITnose の最もエキサイティングなイノベーション

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

WBOY
リリース: 2016-06-24 11:17:35
オリジナル
947 人が閲覧しました

元のリンク: 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 ツリーを自分で解析して