デザイン システムとコンポーネント ライブラリでカスタム プロパティを使用するメリット
Nordhealth でシニア フロントエンド デベロッパーを務める Dave です。私は、コンポーネント ライブラリの Web コンポーネントの構築など、デザイン システム Nord の設計と開発に携わっています。今回は、CSS カスタム プロパティを使用して Web Components のスタイル設定に関する問題を解決した方法と、デザインシステムやコンポーネント ライブラリでカスタム プロパティを使用するメリットについて説明します。
ウェブ コンポーネントの構築方法
Google のウェブ コンポーネントの構築には Lit を使用しています。Lit は、状態、スコープ設定、スタイルなどの多くのボイラープレート コードを提供するライブラリです。Lit は軽量であるだけでなく、ネイティブの JavaScript API を基に構築されています。つまり、ブラウザの既存の機能を活用した、無駄のないコードバンドルを提供できます。
しかし、Web Components の最も魅力的な点は、既存の JavaScript フレームワークのほとんど、あるいはまったくフレームワークなしで機能する点です。メインの JavaScript パッケージがページで参照されると、ウェブ コンポーネントの使用はネイティブ HTML 要素を使用する場合とよく似ています。ネイティブ HTML 要素ではないことを示す唯一の証拠は、タグ内に一貫したハイフンを使用することです。これは、これがウェブ コンポーネントであることをブラウザに示すための標準です。
Shadow DOM スタイルのカプセル化
ネイティブ HTML 要素とウェブ コンポーネントでは、Shadow DOM とほぼ同じです。Shadow DOM は、要素内のノードの非表示のツリーです。これを視覚化するには、ウェブ インスペクタを開いて、[Shadow DOM ツリーを表示] オプションをオンにします。それが終わったら、インスペクタでネイティブ入力要素を確認してみましょう。その入力を開くと、その入力に含まれるすべての要素を確認できるようになります。Google のウェブ コンポーネントで試すこともできます。カスタム入力コンポーネントを調べて、Shadow DOM を確認してみてください。
Shadow DOM の利点(見通しによっては欠点)の一つに、スタイルのカプセル化があります。ウェブ コンポーネント内に CSS を記述した場合、それらのスタイルが漏れたり、メインページや他の要素に影響を及ぼしたりすることはありません。スタイルはコンポーネント内に完全に含まれています。また、メインページまたは親のウェブ コンポーネント用に記述された CSS が、ウェブ コンポーネントに漏洩することはありません。
このスタイルのカプセル化は、コンポーネント ライブラリの利点です。これにより、いずれかのコンポーネントを使用すると、親ページに適用されているスタイルに関係なく、意図したとおりに表示されることが保証されます。さらに、すべてのウェブ コンポーネントのルート(ホスト)に all: unset;
を追加します。
ただし、Web コンポーネントを使用しているユーザーが特定のスタイルを変更する正当な理由がある場合はどうすればよいでしょうか。文脈上コントラストを強くする必要があるテキスト行がある場合や、枠線を太くする必要がある場合があります。コンポーネントにスタイルを適用できない場合、それらのスタイル設定オプションを利用するにはどうすればよいですか。
このような場合に役立つのが CSS カスタム プロパティです。
CSS カスタム プロパティ
カスタム プロパティの名前は非常に適切です。これは、名前を自由に付け、必要な値を適用できる CSS プロパティです。ただし、接頭辞に 2 つのハイフンを追加する必要があります。カスタム プロパティを宣言したら、var()
関数を使って CSS で値を使用できます。
継承に関しては、すべてのカスタム プロパティが継承されます。これは、通常の CSS プロパティと値の一般的な動作に従います。親要素または要素自体に適用されたカスタム プロパティは、他のプロパティの値として使用できます。Google では、デザイン トークンにカスタム プロパティを多用し、CSS フレームワークを介してルート要素に適用しています。これにより、ウェブ コンポーネント、CSS ヘルパークラス、トークンのリストから値を取得するデベロッパーなど、ページ上のすべての要素でこれらのトークン値を使用できます。
var()
関数を使用してカスタム プロパティを継承する機能は、ウェブ コンポーネントの Shadow DOM を突き破り、開発者がコンポーネントのスタイル設定時により詳細に制御できるようにする手段です。
Nord Web コンポーネントのカスタムプロパティ
デザイン システムのコンポーネントを開発するときは常に、その CSS に対して慎重なアプローチを取ります。無駄がなく、保守性に優れたコードを目指しています。デザイン トークンは、ルート要素のメイン CSS フレームワーク内のカスタム プロパティとして定義されています。
これらのトークン値はコンポーネント内で参照されます。場合によっては、値を CSS プロパティに直接適用することもありますが、それ以外は、コンテキストに応じた新しいカスタム プロパティを実際に定義し、値を適用することもあります。
また、コンポーネントに固有の値であってもトークンには含まれない値を抽象化し、コンテキスト カスタム プロパティに変換します。コンポーネントに関連するカスタム プロパティには、主に 2 つのメリットがあります。まず、その値をコンポーネント内の複数のプロパティに適用できるため、CSS をより「ドライ」にできます。
2 つ目のメリットは、コンポーネントの状態やバリエーションを変更する際に、カスタム プロパティのみを変更すれば、すべてのプロパティを更新できることです。たとえば、ホバー状態やアクティブ状態、またはこの場合はバリエーションをスタイル設定する場合に、変更が必要なのはカスタム プロパティのみです。
最も大きなメリットは、コンポーネントでこれらのコンテキスト カスタム プロパティを定義すると、コンポーネントごとに一種のカスタム CSS API が作成され、そのコンポーネントのユーザーが利用できることです。
上の例は、セレクタによって変更されたコンテキスト カスタム プロパティを持つウェブ コンポーネントの例です。このアプローチ全体の結果として、実際のスタイルのほとんどを管理しながら、ユーザーに十分なスタイルの柔軟性を提供できるコンポーネントが実現します。さらに、コンポーネント デベロッパーは、ユーザーが適用したスタイルをインターセプトすることもできます。これらのプロパティのいずれかを調整または拡張する場合、ユーザーがコードを変更することなく実行できます。
このアプローチは、デザインシステム コンポーネントの作成者である Google にとってだけでなく、Google のプロダクトでこれらのコンポーネントを使用する開発チームにとっても非常に強力です。
カスタム プロパティをさらに活用する
執筆時点では、これらのコンテキスト カスタム プロパティはドキュメントに記載されていませんが、開発チーム全体がこれらのプロパティを理解して活用できるように、記載する予定です。コンポーネントは npm でマニフェスト ファイルとともにパッケージ化されています。このファイルには、コンポーネントに関するすべての情報が含まれています。ドキュメント サイトがデプロイされると、マニフェスト ファイルがデータとして使用されます。これは、Eleventy とそのグローバル データ機能を使用して行われます。これらのコンテキスト カスタム プロパティは、このマニフェスト データファイルに含める予定です。
改善したい点のもう 1 つは、これらのコンテキスト カスタム プロパティが値を継承する方法です。たとえば、現在、2 つの分割コンポーネントの色を調整するには、セレクタで両方のコンポーネントを明示的にターゲットにするか、スタイル属性を使用して要素にカスタム プロパティを直接適用する必要があります。問題ないように思えるかもしれませんが、デベロッパーがこれらのスタイルを、含まれる要素またはルートレベルで定義できれば、さらに便利です。
カスタム プロパティの値をコンポーネントに直接設定する必要があるのは、コンポーネント ホスト セレクタを使用して同じ要素で定義するためです。コンポーネントで直接使用するグローバル デザイン トークンは、この問題の影響を受けることなくそのまま渡され、親要素でインターセプトすることもできます。両方の長所を活かすにはどうすればよいですか?
非公開と公開のカスタム プロパティ
非公開カスタム プロパティは Lea Verou によって作成されたものです。コンポーネント自体のコンテキストに存在する「非公開」カスタム プロパティですが、フォールバックを使用して「公開」カスタム プロパティに設定されます。
このようにコンテキストに応じたカスタム プロパティを定義することで、グローバル トークン値の継承や、コンポーネント コード全体での値の再利用など、これまで行っていたすべてのことを行うことができます。さらに、コンポーネントは、それ自体または任意の親要素で、そのプロパティの新しい定義を適切に継承します。
この方法は厳密には「非公開」ではないと主張されるかもしれませんが、懸念していた問題に対するエレガントな解決策であると考えております。機会があれば、コンポーネントでこの課題に取り組む予定です。これにより、開発チームはコンポーネントの使用をより細かく管理しながら、Google が設けているガードレールのメリットも享受できます。
Google が CSS カスタム プロパティで Web Components を使用する方法に関するこの分析がお役に立てば幸いです。ご意見、ご感想をぜひお聞かせください。また、これらの手法をご自身の仕事で利用する場合は、Twitter(@DavidDarnes)までお知らせください。Nordhealth の Twitter アカウント(@NordhealthHQ)や、このデザイン システムの統合と、この記事で説明した機能の実装に尽力したチームメンバー(@Viljamis、@WickyNilliams、@eric_habich)もフォローしてください。
ヒーロー画像: Dan Cristian Pădureț