Microsoft Edge Japan

Microsoft Edge と Internet Explorer に関する情報をお届けします。

コンポーネント化: Web のために生まれ変わった従来の設計プラクティス

前回に引き続き、マイクロソフト米国本社の Edge 開発チームのブログから、Edge の技術的ロードマップに関する記事をピックアップし翻訳したものをお送りします。

公開される順番は、より情報量が多いものからとさせていただきますので、時系列順ではありませんのでご了承くださいませ。

この記事はマイクロソフト米国本社の Edge 開発チームのブログ Microsoft Edge Dev blog の記事、「Bringing componentization to the web: An overview of Web Components」 (2015/7/14) の記事の抄訳です。

 

コンポーネント化を Web の世界に: Web Components の概要

Editor’s note:これは Microsoft Edge エンジニアの Travis Leithead (英語) と Arron Eicholz (英語) による、2 部構成の記事の第 1 回目です。第 2 回目は、明日、7 月 15 日を予定しています。

UserVoice (フィードバック用サイト) において最も要望が多かった 5 つのプラットフォーム機能のうち 4 つ (Shadow DOM、Template、Custom Elements、HTML Imports) は、Web Components と呼ばれる機能群に属しています。この投稿では、Web Components について説明します。Microsoft の見解や、Web Components を詳しくご存じでない方のために多少の背景を示し、将来 Web Components はどのように発展すると予想できるかについて少し推測したいと思います。この目的を十分に果たすには、長い記事にならざるを得ません。椅子に深く腰掛け、コーヒー (またはカフェインなしのドリンク) を用意して、続きをお読みください。第 2 回目 (明日公開予定) は、Microsoft のロードマップと実装の計画についての質問にお答えします。

目次:

コンポーネント化: Web のために生まれ変わった従来の設計プラクティス

他のソフトウェア アプリケーションと同様に、Web アプリケーションは複雑になり、今ではリリース製品の開発に大勢が協力して取り組むことは珍しくなくなりました。少しでも効率化を図るには、関係者やシステム間の重複が最小限になるように開発作業を分割する正しい方法を見つけることが重要です。(概して) コンポーネント化は、そのための方法です。コンポーネント システムは分離、つまり、あるシステムの複雑さを他のシステムから隠す自然な境界を提供することで、全体的な複雑さを軽減します。適切に分離できると、再利用性と保守性も確保しやすくなります。

従来、一般的には、サーバー側でアプリケーションを複数のページに分離し、ユーザーがブラウザーでページ間をナビゲートすることで、Web アプリケーションの複雑さに対応していました。それが、AJAX と関連機能が登場したことで、Web アプリケーションの各ページ間を “ナビゲート” する必要がなくなりました。メールやニュースを読むなど、一部の一般的なシナリオでは、期待される行動が変化しています。たとえば、メールにログインしたら、特定の URL から “メール アプリケーションを実行” し、終日そのページから移動しない可能性があります (シングルページ アプリケーション (英語))。クライアント側の Web アプリケーション ロジックの方がはるかに複雑で、サーバー側アプリケーションのロジックに匹敵する場合さえあるかもしれません。この複雑さを解消するためのソリューションとして考えられるのが、コンポーネント化を進めて、単一の Web ページまたは Web ドキュメント内にロジックを分離することです。

Web Components の目標は、HTML、CSS、JavaScript の関連グループを分離し、単一ページのコンテキスト “内” で共通関数を実行することで、複雑さを軽減することです。

コンポーネント化の方法

Web Components は、HTML、CSS、JavaScript を併せて描画する必要があるため、Web Components を 1つのまとまりとして維持することが重要なシナリオで、HTML、CSS、JavaScript のそれぞれがサポートする既存の分離モデルを利用できる必要があります。これらの独立した分離モデルは、次のとおりです (これ以降の段落で詳しく説明します)。

 

CSS スタイルの分離

現在、プラットフォームにはネイティブに CSS をコンポーネント化できる優れた方法はありません (ただし、Sass (英語) などのツールはたしかに役に立ちます)。コンポーネントモデルは、ある CSS に定義されているルールが別の CSS に干渉しないように、特定の CSS を分離する方法をサポートする必要があります。また、コンポーネントスタイルは、コンポーネントの必要な部分にのみ適用され、他には影響しないようにする必要があります。これは、「言うは易く行うは難し」です。

スタイル シート内で、セレクターを使って CSS スタイルをドキュメントに適用します。セレクターの範囲は、常にドキュメント全体に適用される可能性が考慮されるため、基本的にグローバルになります。適用範囲がグローバルなため、同一プロジェクトに携わっている多数の開発者の CSS ファイルをプールすると、現実的に競合が発生します。重複や複製のあるセレクターには、競合を解決するための確立された手順 (カスケード、特定性、ソース順など) がありますが、緊急対応で実行される動作は開発者が意図したものであるとは限りません。この問題の解決に使用できそうな方法は多数あります。簡単な解決策は、プライマリドキュメントから任意のコンポーネントに含まれる要素と関連スタイルを別のドキュメント (シャドウ ドキュメント) に移動し、セレクターの照合対象から外します。この方法は、また別の問題を生みます。境界が確立されたので、今度はこの境界をまたいでスタイルを適用する方法を考えなくてはなりません。これは JavaScript を使って命令的に行うことはできそうですが、境界をまたいでスタイルを調節する目的で JavaScript を利用して、CSS の不備と思える問題に対応するのは、奇妙に思えます。

効果的にコンポーネントの境界をまたいでスタイルを適用しつつ、コンポーネントの構造も保護する (スタイルを壊さずに構造的な変更を可能にする) には、2 種類の汎用的な、ある程度のコンセンサスが得られているアプローチがあります。それは、カスタムの疑似要素を使用するか、カスタム プロパティ (旧称: CSS “変数”) を使用して、”部分的” にスタイルを設定する方法です。一時は、非常に強力な、境界をまたいだセレクター連結子の “>>>” も検討されていましたが (CSS のスコープ (英語) の仕様)、現在では、これはあまりに簡単にコンポーネントの分離を無効化するため、概して不適切な方法だと考えられています。

部分的なスタイル設定を使うと、コンポーネントの作成者がスタイル設定用にカスタムの疑似要素を作成し、内部構造の一部のみを外部に公開できます。これは、ブラウザーがネイティブ コントロールの “パーツ” の公開に使うモデルに似ています。シナリオを完了するには、疑似要素に適用できるスタイルセットを制限する何かしらの方法が必要になるでしょう。疑似要素ベースの “パーツ モデル” を突き詰めると、便利なスタイル プリミティブを最終的に用意できる可能性がありますが、詳細を固める必要があります。パーツモデルの作業を進めていくと、(ぜひとも注目すべき機能の) ブラウザーに組み込まれているネイティブ コントロールのスタイル設定 (英語) の理由付けもできるでしょう。

カスタム プロパティ (英語) を使うと、スタイルシートで再利用したいスタイルの値を記述できます (2つのダッシュを先頭に付けたカスタム プロパティ名として定義します)。カスタム プロパティはドキュメントのサブツリーによって継承されるので、セレクターは特定のサブツリーのカスタムプロパティの値を、他のサブツリーに影響を及ぼすことなく、上書きできます。カスタム プロパティ名はコンポーネントの境界をまたいで継承することもできるので、コンポーネントの構造的な性質を表に出すことなく、コンポーネントのエレガントなスタイル設定メカニズムを実現できます。カスタムプロパティは Google のさまざまなコンポーネント フレームワークによって評価されており、ほとんどのスタイル設定ニーズに対応できると報告されています。

これまでに検討されているスタイル設定のすべてのアプローチの中では、将来の “パーツ” モデルと現在のカスタムプロパティの仕様が、最も有望なようです。筆者は、カスタム プロパティを Web Components 仕様群の新しい必須のメンバーだと考えています。

その他の CSS スタイルの分離のアプローチ

これまでの話からおわかりかもしれませんが、念のため捕捉しておくと、CSS のスコープ設定と分離は、それほど白黒がはっきりしていません。実際、いくつかの過去と現在のプロポーザルは、スコープ設定と分離のメリットとして、Web コンポーネントに多様な形で適用できることを挙げています。

CSS は、特定のシナリオにおいて、ある程度のセレクターの分離を実現できます。たとえば、@media ルールは一連のセレクターをグループ化し、メディアの条件 (たとえば、ビューポートのサイズとディメンションや、印刷などメディアの種類) が一致した場合に条件付きで適用します。@page ルールでは、印刷の条件 (ページメディア) のみが該当するいくつかのスタイルを定義します。@supports ルール (英語) は、コレクターをまとめて、実装が特定の CSS 機能をサポートする場合にのみ適用します (新しい形の CSS 機能検出)。@document (英語) のプロポーザルでは、セレクターをまとめて、スタイル シートが読み込まれた文書がルールに一致する場合にのみ、適用します。

CSS のスコープ (英語) 機能 (もともとは Web Components の取り組みの一環で策定されました) は、単一の HTML ドキュメント内での CSS セレクターの適用性を制限するためのプロポーザルです。このプロポーザルは、新しいルールの @scope を定義しています。@scope は、セレクターによってスコープのルートを指定し、@scope ルールに含まれるすべてのセレクターを評価して、指定したルートのサブツリーにのみ適用されるようにします (ドキュメント全体には適用されません)。この CSS スコープ設定の仕様は、HTML を使って宣言的にスコープ設定のルートの定義を可能にします (例: 提案されている <style scoped> 属性は現在 Firefox のみが実装しています。この機能は以前、Chrome で実験的なオプトイン機能として提供されていましたが、完全に削除されています)。この機能のアスペクト (つまり、Selectors L4 (英語) で定義されている :scope) も、DOM 仕様の新しい API (英語) の “相対セレクター” の評価に使用することを意図しています。

@scope では一方向の分離境界しか確立されないことに注意してください。@scope内のセレクターは指定されたスコープ内に制限されますが、それ以外の (@scope 外の) セレクターは、自由に @scope 内での選択を実行できます (ただし、カスケードによる順序とは異なる可能性があります)。これは、@scope サブセット内にないセレクターについてはスコープ設定も分離も行われないため、残念な設計です。すべての CSS は別の @scope ルール内で誤ったスタイル設定がされないように、”適切に動作” する必要があります。Tab さんの @in-shadow-of コード (英語) を参照してください。こちらの方が、コンポーネントの分離を保護するモデルに即しています。

他に、CSS Containment (英語) もスコープ設定機能として提案されています。コンテインメントによるスコープ設定は、スタイルやセレクターの分離というよりは、”レイアウト” の分離に関係しています。”contain” プロパティを使うと、(counters など、ドキュメント内の親から子要素への適用性という意味で) 自然に継承される特定の CSS 機能の動作がブロックされます。主にこれは、特定の要素に厳格なコンテインメントの約束事が設定されていることを示すために開発者が使用します。特定の要素と要素のサブツリーに適用できるレイアウトは、ドキュメントの他の部分のレイアウトには決して影響しない、などです。このようなコンテインメントの約束事 (“contain” プロパティを使って強制) を使うと、ブラウザーによりレイアウトやレンダリングを最適化でき、コンテインメント対象のサブツリーのレイアウトが “ダーティ” な場合に、ドキュメント全体ではなく、そのサブツリーのレイアウトのみ更新を必要とします。

ブラウザー ベンダーの間での Web コンポーネント テクノロジの実装が成熟し、ますます一般に使用されるようになるに従い、その他のスタイル設定のパターンや問題が出てくる可能性があります。さらに投資が行われ、さまざまな CSS プロポーザルが進展した結果、Web コンポーネントのスタイル設定機能が向上することを期待しましょう。

JavaScript とスコープ

同一の Web ページに読み込まれるすべての JavaScript は、同じ共有グローバル オブジェクトにアクセスできます。他のプログラミング言語と同様に、JavaScript にも特定の機能のコードの “プライバシー” の度合いを示すスコープがあります。この構文スコープは、グローバル環境の他の部分から変数と関数を分離するために使用されます。(構文スコープを使う) 現在流行りの JavaScript “モジュール パターン” は、複数の JavaScript フレームワークが単一のグローバル環境内で、(読み込みの順序に応じて) 互いを “踏み付け” 合わずに “共存” する必要性から生まれました。

JavaScript の構文スコープは、一方向の分離境界です。スコープ内のコードは、スコープのコンテンツだけでなく、先祖スコープやグローバルスコープにまでアクセスできますが、スコープ外のコードは、スコープのコンテンツにはアクセスできません。重要な原則は、この一方向の分離では、スコープ内のコードが優先され、保護されるということです。構文スコープ内のコードは、環境の他の部分から、自らのコードを保護や隠蔽するかどうかを選択できます。

JavaScript の構文スコープが Web コンポーネントにもたらすメリットは、コンポーネントを “隔離” して、コンポーネントのコンテンツを適度にプライベートにする手段を用意しなければならないという要件をクリアできることです。

グローバル オブジェクトの分離

コードによっては、前述のようなグローバル環境へのアクセスを共有したくない場合があります。たとえば、JavaScript コードの中には、非常に重要な価値があっても、アプリケーション開発者が信頼しないものがあります。広告や広告フレームワークが、その例です。JavaScript のセキュリティを確保するには、信頼しないコードは分離されたクリーンなスクリプト環境 (固有のグローバル オブジェクトがある環境) で実行する必要があります。また、開発者は、他のスクリプトを気にせずにコーディングできる新しいグローバル環境を必要とすることも考えられます。現在、(iframe 要素を使わずに) そのようなコーディングをするには、Worker (英語) を使用できます。Worker のマイナス点は、要素、ひいては UI へのアクセスを提供しないことです。

グローバル オブジェクトの分離をサポートするコンポーネントを設計する際には、特に、その分離によってセキュリティ境界 (詳細はすぐに後述) を実現する場合、さまざまな考慮事項があります。分離コンポーネントは、Web Components 仕様の初期セットが確定するまで完全には開発されないと思われます (つまり “v2 に持ち越し” されます)。しかし、分離コンポーネントがどのようなものになるかを現時点で確認しておくのは、現在進行中の作業についての情報提供に役立つでしょう。いくつかのプロポーザルが提案されていて、これらは目を通す価値があります。

グローバル オブジェクトの分離は、Web コンポーネントに関して現在実現されていない重要なシナリオに対応できます。当面は、現時点で最も有効で、現在の Web で最も広く利用されているコンポーネント化手法である iframe 要素を使う必要があります。

要素のカプセル化 (iframe)

iframe とその仲間の object 要素、フレームセット、命令型の window.open() API は、既に分離要素サブツリーをホストする機能を実現しています。単一のドキュメント内での実行を意図したコンポーネントと異なり、iframe は HTML ドキュメント全体を連結して、2 つの Web アプリケーションの一方がもう一方を囲い込んでいるような形になります。それぞれのアプリケーションには一意のドキュメント URL、グローバル スクリプト環境、CSS スコープがあります。ドキュメントは互いに完全に分離されています。

iframe は、現在の Web で最も有効な (また、唯一普及している) コンポーネント化手法です。iframe は、複数の Web アプリケーションの連携を可能にします。たとえば、多くの Web サイトでは、広告からフェデレーション ID のログインまで、さまざまな機能を実現するために、iframe を 1 種のコンポーネントとして利用しています。iframe には一連の課題があります。以下に、その対策と併せて紹介します。

  • 1 つの HTML ドキュメント内の JavaScript コードが、別のドキュメントの分離境界を超える可能性があります (iframe の contentWindow プロパティを介してなど)。この iframe の分離境界を超える機能は、必要な機能である可能性はありますが、iframe のコンテンツに共有を想定していない機密情報が含まれる場合、セキュリティ リスクにもなります。現在、同一生成元ポリシーが不要な越境対策として利用されています。これは、生成元が同じドキュメント URL は既定で越境を許可し、クロス オリジンの (生成元が異なる) ドキュメント同士は、限られたやりとりしかできないとする考え方です。
  • セキュリティ リスクは越境だけではありません。<iframe sandbox> 属性 (英語) を使うと、クロス オリジンの iframe をさらに制限でき、保護なしではフレーム内で利用できていた不要なスクリプト、ポップアップ、ナビゲーションなどの機能からホストを保護できます。
  • フレーム化されたドキュメント外の CSS スタイルは、ドキュメント内に適用できません。この設計は、分離の原則を守ります。ただし、スタイルの分離は、iframe をコンポーネントとして使用する場合、iframe を統合するとかなりの境界線ができます。HTML では、同一生成元の iframe に提案されている <iframe seamless> 属性 (英語) を使うという方法で、この問題に対応しています。seamless 属性を使用すると、フレーム化されたコンテンツへのスタイルの分離が無効化されます。シームレスなフレーム化ドキュメントには、ホスト ドキュメントのスタイルのコピーが適用され、ホストされたフレーム要素の境界は存在しないかのようにレンダリングされます。

優れたセキュリティ ポリシーとシームレスなフレーム機能があれば、iframe をコンポーネント モデルとして使用することは、かなり魅力的なソリューションに思えますが、Web コンポーネント モデルに望ましい、次のようないくつかの特徴がありません。

  • 深い統合。iframe は、ホストとフレーム化ドキュメント間の統合とやりとりを制限 (ほとんどの場合完全に阻止) します。たとえば、ホストに対して、フォーカスおよび選択モデルは独立しています。また、イベント伝達は相手のドキュメントから分離されます。より緊密な統合が必要なコンポーネントでは、ホストのドキュメント内に境界を超えるための “エージェント” を作成しないと、これらの動作をサポートできません。
  • グローバル オブジェクトの増殖。ページ上で作成される iframe インスタンスごとに、一意のグローバル オブジェクトも必ず作成されます。グローバル オブジェクトとそれに関連付けられている完全な型システムの生成は負荷が高く、大量のメモリが消費され、ブラウザーに余分な負担がかかる可能性があります。同じコンポーネントの複数のコピーが同一ページ上で使用される場合、コピー同士が完全に分離される必要はない可能性があります。実際には、1 つのグローバル オブジェクトを共有する方が、特に共通の共有状態が必要な場合は、適しています。
  • ホスト コンテンツ モデルの配布。iframe は現在、フレーム化ドキュメント内での、ホスト要素のコンテンツ モデルの再利用を認めていません。(簡単に説明すると、要素の “コンテンツ モデル” が、要素とテキストのサブツリーとしてサポートされます。)たとえば、select 要素には option 要素を含むコンテンツ モデルがあります。Web コンポーネントとして実装された select 要素は、同種の子要素を同じ方法で処理しようとします。
  • 選択的なスタイル設定。シームレスな iframe は、クロス オリジンのドキュメントには使用できません。この動作を許可すると、軽微なセキュリティ リスクが発生します。最大の問題は、”シームレス″ の状態がフレーム化ドキュメントではなく、ホストによって制御されることです (関連する攻撃においてはフレーム化ドキュメントが被害を受けることが多い)。コンポーネントに対しては、バイナリの “シームレス” 機能は過剰である可能性があります。 (シームレスの処理など、すべてのスタイルを自動的に継承するのではなく) ホストからどのスタイルをコンポーネントのコンテンツに適用するかを、コンポーネント側で選択することが必要な場合があります。概して、スタイル設定の問題は、コンポーネントで制御される必要があります。
  • API の公開。Web コンポーネントの多くのシナリオでは、完全な新しい “custom” 要素とその要素で公開される独自の API サーフェスの作成、セマンティックのレンダリング、ライフサイクル管理を行います。iframe を使うと、上記のすべての処理を実行することを前提に、開発者がベースラインとして操作できる対象が iframe の API サーフェスに制限されます。たとえば、要素の ID とそのライフサイクル セマンティックは変更できません。

 

過去の試み

これまで、HTML の iframe と関連するカプセル化機能の改善を図り、いくつかのテクノロジが提案および実装されてきたことは、注目すべき事実です。そのうち、現在も公衆 Web で何かしら意味のある形で使用されているものはありません。

  • HTML コンポーネント (英語) (1998) は、Microsoft によって提案され、IE5.5 から実装されていました (IE10 で使用されなくなりました)。HTML コンポーネントでは、イベントや API のホスト要素へのアタッチに (分離を念頭に) 宣言型モデルを使用し、コンポーネントを解析して “ViewLink” (“Shadow DOM” の 1 種) を生成していました。永続的に要素にアタッチするコンポーネントと、CSS の “behavior” プロパティによって動的にバインドするコンポーネントの 2 種類を扱うことができました。
  • XBL (英語) (2001) とその後継の XBL2 (英語) (2007) は、Mozilla の XUL ユーザー インターフェイス言語を補完する言語として Mozilla により提案されました。(Microsoft の HTML コンポーネントと同様に) 2 種類のバインドが可能な宣言型のバインド言語 である XBL は、追加機能としてホスト コンテンツ モデルの配布とコンテンツ生成をサポートしていました。

 

Web Components の現状

以前の 2 つのテクノロジが失敗に終わってから、今回は Google 主導で、再びコンポーネントのプロポーザルが検討されています。XBL で記述されていた概念をたたき台に、モノリシックなコンポーネント システムを細分化してコンポーネントの構成要素のコレクションにしています。Web 開発者はこれらの構成要素を使うことで、Web コンポーネントのビジョン全体が完全に実現される前に、一部の有用な独立した機能を実験できます。このコンポーネント化と、独立した有用な機能の開発が、Google の成功に寄与しています。ほぼ例外なく、開発するアプリケーションに有用な Web コンポーネントの構成要素を見つけることができます。

この新種の Web コンポーネントは、一連の定義済みユース ケース (英語) に対応することを目指しています。これは、現在、既存の組み込みの要素の Web プラットフォームでの動作を説明することで実現します。理論的には、開発者は Web コンポーネントを使って、ネイティブ要素と同じ忠実さと特徴を持った新しい種類の HTML 要素のプロトタイプを作成できます (現実的には、現時点では、HTML のアセンブリの動作を対応付けることは非常に困難です)。

Web コンポーネントのすべてのユース ケースのサポートに必要なテクノロジ一式が、初めからブラウザーに揃っていないことは明らかです。実装者は、追加のユースケースの策定に移る前に、一貫性を保って詳細を実装できるコアのテクノロジ セットを確立すべく合意形成に取り組んでいます。

“第 1 世代” の Web コンポーネント テクノロジは、次のとおりです。

  • Custom Elements: Custom Elements (カスタム要素) は、HTML パーサーの拡張ポイントを定義し、新しい “カスタム要素” 名を認識して、その要素に JavaScript を基盤とするオブジェクト モデルを自動的に提供します。• Custom Elements はコンポーネント境界を実装せず、ブラウザーが API と動作を作成者が定義した要素にアタッチする手段を提供します。未対応のブラウザーは、変更オブザーバー/イベントとプロトタイプ調整を使って、さまざまな精度に合わせて Custom Elements のポリフィルを行うことができます。タイミングを図り、影響を理解することが、現在予定されている会合の議題の 1 つになっています。
    • “is” 属性: Custom Elements の仕様には、また別の重要な機能が隠れています。それは、組み込みの要素にカスタム要素の名前と API 機能を渡す必要があることを示す機能です。通常、カスタム要素は、初めは汎用要素として用意でき、”is” を使ってネイティブ要素で代用できます (例: <input is=”custom-input”> )。この機能は、既定のレンダリング、アクセシビリティ、解析など、特定の HTML 要素に組み込まれている便利な機能をすべて継承できるすぐれた方法ですが、構文がハッキングであると見なせるところがあり、アクセシビリティ プリミティブとネイティブ コントロールのスタイル設定を使用した方が、長期的な標準化の道筋として適しているのではないかという意見もあります。
  • Shadow DOM: ホスト要素に (1 度だけ) 接続できる要素のツリーを別途作成するための命令型 API を提供します。ドキュメントのレンダリング時に、これらの “シャドウ” の子要素が “リアル” の子要素に代わって使用されます。Shadow DOM は、(最近提案された) 新しい slot 要素、イベント モデル fixup、(同じく新たに採用された) 操作の closed/open モードを使って、ホスト要素のコンテンツ モデルの再利用も可能にします。この比較的平凡なアイデアには、フォーカス モデルと選択から合成、配布 (Shadow DOM 内の Shadow DOM の場合) まで、あらゆるものに対して驚くほど多くの副作用があります。
    • CSS のスコープ: Shadow DOM のスタイル設定に関連する各種擬似要素を定義します。これには、:host、::content (近々 ::slot に置き換え??)、以前の “>>>” (shadow DOM のpiercing 結合子) が含まれます。”>>>” は、現在正式に却下されています。
  • template 要素: 念のためこの要素についても取り上げます。template 要素は初期の Web コンポーネント機能の 1 つで、現在 HTML5 勧告 (英語) に含まれています。template 要素は、不活性の概念 (テンプレートの子による、ダウンロードのトリガーやユーザー入力への反応などを抑止します) を導入しました。また、HTML で宣言的に独立した要素のサブツリーを作成する初めての方法でした。template は、テンプレート スタンピングとデータ バインディングから、Shadow DOM のコンテンツの伝達まで、さまざまなことに使用できます。
  • HTML Imports: HTML をドキュメントに “インポート” (要求、ダウンロード、解析) する宣言構文を定義します。Imports (link 要素の rel=”import” を使用) は、インポートしたドキュメントのスクリプトをホスト ページのコンテキストで実行します (したがって、ホストと同じグローバル オブジェクトと状態にアクセスできます)。Web コンポーネントの HTML、JavaScript、CSS パーツは、1 つの import だけで便利に展開できます。
  • カスタム プロパティ: 上記で詳しく説明したとおり、コンポーネント内で使用できるコンポーネントの外部で記述されたカスタム プロパティは、現在、コンポーネントにスタイルを設定する簡単で便利なモデルになっています。それを踏まえて、カスタム プロパティを Web Components テクノロジの第 1 世代の一部として含めました。

 

Web Components: 次世代の展望

この記事の冒頭で触れたように、Web Components の機能の構築は旅であると言えます。機能を拡充し、現世代の機能のギャップを埋めるためのさまざまなアイデアが、既に出されています (以下は、その一部です)。

  • 宣言型 Shadow DOM。宣言型 Shadow DOM は、シリアル化された形でコンポーネントを提供し直す方法を考えるときに重要になります。宣言型の方法がなければ、innerHTML や XMLSerializer などの手法ではシャドウ コンテンツ を含む DOM の文字列表現を作成できません。したがって、Shadow DOM は、スクリプトの助けなしではラウンド トリップができません。プロポーザルの試案として、Mozilla の Anne さんは <shadowdom> 要素を提案 (英語) しています。同様に、template 要素は既に一種の shadow マークアップを作成する宣言型のアプローチになっています。ブラウザーのシリアル化機能は、既にこれに対応するよう調整されていて、template の “shadow” コンテンツを宣言に従ってシリアル化できます。
  • 完全に分離されたコンポーネント。これについては、3 社のブラウザー ベンダー (英語) が 3 社 3 様のプロポーザルを提出しています。この 3 種類のプロポーザルは既に大方の整合が取れており、これはコンセンサス形成の観点からすると好材料です。前述のとおり、分離コンポーネントは新しいグローバル オブジェクトを使用し、クロス オリジンからインポートされる可能性があります。また、分離境界を超えて API と関連する動作を公開するための妥当なモデルも用意されるでしょう。
  • アクセシビリティのプリミティブ。アクセシビリティのコミュニティでは、既存のネイティブ要素を拡張する手段として、(Custom Elements の) “is” の考え方が高く評価されています。というのも、ネイティブ要素には、JavaScript 開発者が通常利用できない、アクセシビリティの動作が用意されているからです。理想は、汎用 Web コンポーネント (“is” 不使用) が、特にフォームの送信やフォーカス機能など、アクセシビリティに関してネイティブ要素と同じくらい緊密に統合できることです。これらの拡張ポイントは、現在では実用化されていませんが、調査および定義されるべき事項です。
  • 統合ネイティブ コントロールのスタイル設定。ブラウザー間で一貫したコントロールのスタイル設定がないことは、かねてから相互運用性の問題の 1 つになっています。この問題は、シンプルな “テーマ指向” の拡張機能の普及を妨げています。そのため、開発者はしばしば、Shadow DOM を代替ソリューションとして検討します (ただし、ネイティブ コントロールと同じ動作の忠実さで、Shadow DOM を作成することは非常に困難な可能性があります)。しばらく前から、CSS でいくつかコントロールのスタイル設定のアイデアが出されていますが、盛り上がりに欠け、これらのアイデアの開発ペースはゆるやかです。
  • CSS パーツのスタイル設定。CSS のカスタム プロパティは、現在、Web コンポーネントに幅広いスタイル設定オプションを提供していますが、コンポーネントのカプセル化されているスタイル設定機能の一部を公開する方が、より直接的または適切であるシナリオもあります。これは、ネイティブ コントロールのパーツ スタイル設定機能の公開に既存のブラウザーが使用する (英語) アプローチも合理化する場合に、特に便利です。
  • パーサーのカスタマイズ。Custom Elements と使用する場合、標準の open/close タグしか、カスタム要素の解析に使用されない可能性があります。Web コンポーネント用のパーサーで追加のカスタマイズを許可 (英語) し、利用できるようにすることが望ましい可能性があります。

 

最後に、正式に検討されている Web Components 機能ではありませんが、従来の iframe は無視されるべきではありません。説明したとおり、iframe は現在でも、コンポーネントのようなものを作成するための、非常に便利な Web プラットフォーム機能です。iframe の “コンポーネント” ストーリーを理解し、場合によって改善することは、有益です。たとえば、手始めに <iframe seamless> の未解決の問題を理解し、対応するのはよい考えだと思います。

Web Components は、Web への布石になります。この旅を引き続きサポートし、貢献したいと意気込んでいます。明日は、Microsoft のロードマップと実装の計画に関する情報をお伝えします。また、ぜひフィードバックを Twitter (@MSEdgeDev) または下のコメント欄からお寄せください。

– Microsoft Edge、プログラム マネージャー、Travis Leithead
– Microsoft Edge、プログラム マネージャー、Arron Eicholz