Webでのコンポーネントアプローチの実装：Webコンポーネントの概要

ユーザーボイスで最も要求されている5つの新しいエッジプラットフォーム機能（シャドウDOM、テンプレート、カスタム要素、HTMLインポート）のうち4つは、Webコンポーネントと呼ばれるAPIファミリに属します。 この記事では、Webコンポーネントとそれらのビュー、いくつかの内部キッチンについて、それらに慣れていない人のために話をしたいと思います。また、これが将来どのように進化するかも推測します。 それはかなり長い話なので、座ってコーヒー（またはカフェインを含まない飲み物）をつかんで読み始めてください。



内容：

• コンポーネントの展開：Webに新しい古い設計プラクティス
• コンポーネントに侵入する方法
• これは初めてではありません：コンポーネント実装への以前のアプローチ
• 最新のWebコンポーネント
• Webコンポーネント：次世代

コンポーネントの展開：Webに新しい古い設計プラクティス

最新のWebアプリケーションは、他のソフトウェアアプリケーションと同じくらい複雑で、最終製品を作成するために力を合わせて何人かが作成することがよくあります。 このような状況では、効率を向上させるために、人とサブシステム間の交差が最小限のセクションに作業を分割する適切な方法を探すのが自然です。 コンポーネントアプローチ（一般的に）の実装は、そのようなタスクが通常どのように解決されるかです。 コンポーネントシステムは、 分離 、または一部のシステムの複雑さを他のシステムから隠す自然の障壁を提供することにより、全体的な複雑さを軽減する必要があります。 また、適切な分離により、サービスパラダイムの再利用と実装が容易になります。



当初、Webアプリケーションの複雑さは、アプリケーションを個別のページに分割することにより、サーバー側で主に規制されていました。このため、ユーザーはブラウザーでページを切り替える必要がありました。 AJAXと関連技術の導入により、開発者はWebアプリケーションの異なるページ間で「遷移」を行う必要性を放棄することができました。 メールやニュースを読むなどの典型的なシナリオでは、ユーザーの期待が変わりました。 たとえば、メールにログインした後、同じアドレス（URL）から「メールアプリケーションを使用」し、このページに1日中滞在することができます（いわゆるシングルページアプリケーション 、SPA）。 このような状況でのクライアントWebアプリケーションのロジックは非常に複雑であり、サーバー側よりも複雑になる場合もあります。 この複雑さに対する可能な解決策は、コンポーネントへのさらなる分離と、単一のページまたはドキュメント内のロジックの分離です。



Webコンポーネントの目標は、HTML、CSS、およびJavaScriptコードの関連グループを分離して、単一ページのコンテキスト内で共通の機能を実行することにより、複雑さを軽減することです。

コンポーネントに侵入する方法は？

WebコンポーネントはHTML、CSS、およびJavaScriptを結合する必要があるため、Webコンポーネントのスクリプトおよび整合性に影響するため、各テクノロジーに固有の既存の分離モデルを考慮する必要があります。 これらの独立した断熱モデルには以下が含まれます。

• CSSスタイルの分離
• JavaScriptとスコープ（クロージャー）
• グローバルオブジェクト分離
• 要素のカプセル化（iframe）

CSSスタイルの分離

今日のプラットフォーム内でCSSをコンポーネントに分解する完璧で自然な方法はありません（ただし、 Sassのようなツールは大いに役立ちます）。 コンポーネントモデルは、ルールが相互に影響しないように、CSSのサブセットを別のサブセットから分離するメカニズムを提供する必要があります。 さらに、コンポーネントのスタイルは、コンポーネントの直接の部分にのみ適用され、それ以外には適用されません。 言うより簡単だ！



スタイルシート内では、セレクタを使用してCSSルールがドキュメントに適用されます。 セレクターは常にドキュメント全体に適用される可能性があると常に考えられているため、その範囲は本質的にグローバルです。 プロジェクトに取り組んでいる複数の人がCSSファイルを一緒に混ぜると、グローバルアプリケーションが実際の競合につながります。 セレクターの交差点と繰り返しを明確な順序（カスケード、特異性、ソース順序など）で処理して競合を解決することは可能ですが、そのようなアクションは開発者が望んでいたものではない可能性が高いです。 この問題には多くの解決策があります。 簡単な解決策は、コンポーネントの形成に関係する要素と関連スタイルをメインドキュメントから別のドキュメント（シャドウドキュメント）に転送して、それらが他のセレクタに「応答」しないようにすることです。 これは、2番目の問題につながります：それらを区切ったので、（コンポーネントの外側を制御するために）何らかのスタイルが境界を越えることができますか？ 明らかに可能な解決策は明示的にJavaScriptを使用することですが、それはちょっとひどいように見えます。JavaScriptを使用して境界線を越えてスタイルを渡すことです。



コンポーネントの境界を越えてスタイルを効果的に転送し、同時にコンポーネントの構造を保護するために（たとえば、スタイルの影響を受けずに構造を自由に変更できるようにするため）、多くの傾向がある2つの一般的なアプローチがあります：擬似要素とカスタムプロパティ （以前はCSS「変数」として知られています）。 しばらくの間、超強力な国境を越えるセレクター '>>>'（ CSS Scopingで定義）も検討されていましたが、今日では、コンポーネントの分離を簡単に破ってしまうため、今日では最も成功したアイデアではないと一般に認識されています。



部分的なスタイル設定により、コンポーネントの作成者はスタイル設定のための独自の疑似要素を作成できるため、内部構造の一部のみが外部の世界に公開されます。 これは、ブラウザがネイティブコントロールの「部分」を公​​開するために使用するモデルに似ています 。 このシナリオの整合性のために、作成者は、疑似要素に適用できる一連のスタイルを制限する方法も必要になります。 擬似要素に基づくこの「部分モデル」の追加の研究は、便利な文体プリミティブの出現につながる可能性がありますが、詳細の精緻化には依然として努力が必要です。 部分モデルのさらなる作業は、ブラウザー （ ネイティブのコントロールが明確に注意が必要な領域） のネイティブコントロールのスタイル設定も合理化する必要があります。



カスタムプロパティを使用すると、作成者はスタイルシートで再利用するスタイルの値を記述できます（プレフィックスとして二重ダッシュを使用してプロパティの適切な名前として定義されます）。 カスタムプロパティはドキュメントサブツリーを通じて継承されるため、セレクタは、他のサブツリーに影響を与えることなく、特定のサブツリーのカスタムプロパティの値をオーバーライドできます。 カスタムプロパティは、コンポーネントの境界を越えて継承することもでき、コンポーネントの内部構造の性質を明らかにすることを回避するエレガントなコンポーネントスタイリングメカニズムを提供します。 カスタムプロパティは、Googleのさまざまなコンポーネントフレームワークの開発中に評価され、レポートによると、スタイリングのニーズのほとんどをカバーできます。



現在検討されているすべての様式化手法のうち、将来の「部分的な」モデルとカスタムプロパティの現在の仕様は、実装の可能性が最も高いようです。 Webコンポーネント仕様ファミリの新しい主要メンバーとして、カスタムプロパティを検討しています。

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

完全を期すために、CSSの可視性と分離は、見た目ほど白黒ではありません。 実際、過去および現在のいくつかのアプローチでは、Webコンポーネントへの適用性を変えながら、範囲と分離を制限するオプションを提供しています。



CSSは、特定のシナリオでセレクターを分離するいくつかの制限された形式を提供します。 たとえば、@ ‍メディアルールは、一連のセレクターをグループ化し、メディアコンテキストに適した条件（たとえば、ビューポートのサイズや解像度、メディアタイプが印刷など）に適用します。 @ページ規則は、印刷コンテキストにのみ適用される特定のスタイルを定義します。 @ ‍supportsルールは、特定のCSS機能のサポートが実装されている場合にのみ使用するためにセレクターを組み合わせます-機能がCSSで利用可能かどうかを判断する新しい形式。 提案された@ ‍ドキュメントルールは、スタイルがロードされているドキュメントが条件を満たす場合にのみ使用するセレクタをグループ化します。



CSS可視性領域 （元々はWebコンポーネントの作業の一部として作成された）は、単一のHTMLドキュメント内のCSSセレクターの適用可能性を制限する方法を提供します。 この仕様では、新しい@ ‍scopeルールが導入されています。これにより、セレクターがスコープのルートを決定でき、さらに@ ‍scopeルール内のすべてのセレクターの適用は、このルートのサブツリーでのみ機能します（ドキュメント全体では機能しません）。 この仕様では、HTMLでリージョンのルートを宣言的に指定できます（たとえば、<style scoped>属性は、Firefoxでのみ実装されていますが、提案されました。この機能は、以前はChromeで実験的でしたが、その後完全に削除されました）。 この機能のいくつかの側面（たとえば、 セレクターL4で定義されたスコープ）は、DOM仕様の新しいクエリAPIでセレクターを相対的に評価するためにも使用できます 。



@ ‍scopeは一方向の境界分離のみを確立することに注意することが重要です：@ ‍scope内に含まれるセレクターはこの領域に制限されますが、他のセレクター（@ ‍scope以外）は@ ‍scope内に静かに浸透できます（ただし、 -スタイルの異なる順序カスケードで）。 @ ‍scopeサブセットにないスタイルから範囲と分離を提供しないため、これはやや失敗したデザインです。他の誰かの@ ‍scopeルール内のスタイリングを避けるために、すべてのCSSが依然として「適合」する必要があります。 Tab @ ‍in-shafow-ofも参照してください。これは、コンポーネント分離保護モデルとの整合性が向上しています。



可視性を制限するためのもう1つの提案は、CSSの制限です。 スコープの抑制は、スタイルとセレクターの分離についてはそれほどではなく、「構成」の分離についてはより多くです。 「contain」プロパティ内では、自然な継承を持ついくつかのCSS機能の動作（ドキュメント内の親から子への適用可能性の意味、たとえばカウンター）はブロックされます。 開発者向けの主な用途は、一部の要素が厳密な「包含」を暗示しているため、この要素とそのサブツリーに適用可能な構成がドキュメントの他の要素の構成に影響を与えないことです。 これらの包含の約束（「contain」プロパティの使用によって示される）により、ブラウザーは構成とレンダリングを最適化できるため、保持されたサブツリーの「新しい」構成は、ドキュメント全体ではなく、そのサブツリーの更新のみを必要とします。



Webコンポーネントのテクノロジー実装がブラウザー間で成熟し、ますます一般的に使用されるようになるにつれて、追加のスタイリングパターンと問題が発生する可能性があります。 Webコンポーネントのスタイリングを改善するためのさまざまなCSS提案へのさらなる投資とさらなる進歩を期待しています。

JavaScriptとスコープ

ページに含まれるすべてのJavaScriptコードは、同じグローバルオブジェクトにアクセスできます。 JavaScriptには、他のプログラミング言語と同様に、関数コードにある程度の「プライバシー」を提供するスコープがあります。 これらの字句スコープは、グローバル環境の残りの部分から変数と関数を分離するために使用されます。 現在人気のあるJavaScriptの「モジュラーテンプレート」（レキシカルスコープを使用）は、複数のJavaScriptフレームワークが単一のグローバル環境で「共存」する必要性から進化しました（ロードの順序に応じて）。



JavaScriptの字句スコープは一方向の境界の分離です：エリア内のコードは内部コンテンツとグローバルまでの親エリアのコンテンツの両方にアクセスできますが、エリア外のコードはそのコンテンツにアクセスできません。 重要な原則は、単方向の分離方法が領域内のコードを優先する、つまり保護することです。 字句ドメイン内のコードには、環境の他の部分からそれ自体を保護/非表示にする機能があります（またはこれを行わない）。



JavaScriptのレキシカルスコープがWebコンポーネントの実装に与える貢献は、そのコンテンツが合理的にプライベートになるようにコンポーネントを「閉じる」方法を持つという要件を満たしています。

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

上記のように、一部のコードがグローバル環境を共有することは望ましくない場合があります。 たとえば、アプリケーション開発者は、重要な価値を提供するものの、一部のJavaScriptコードを信頼しない場合があります。 典型的なケースは、広告と広告フレームワークです。 セキュリティ上の理由から、信頼されていないコードは、独自のグローバルオブジェクトを使用して、独立したクリーンなスクリプト環境で実行する必要があります。 現在、この動作を（ゲームにiframe要素を含めずに）達成するために、開発者はworkerを使用できます。 ただし、このソリューションの欠点は、ワーカーが要素、つまりUIにアクセスできないことです。



グローバルオブジェクトの分離をサポートするコンポーネントを設計する際に考慮すべき考慮事項がいくつかあります-特に分離に安全な境界が含まれる場合（これについては以下で詳しく説明します）。 現在、分離されたコンポーネントは、Webコンポーネント仕様の基本セットが修正されるまで（つまり、「次のバージョンまで遅延」されるまで）完全にアクセスできないと予想されます。 ただし、断熱コンポーネントがどのように見えるかを調査するために時間を費やすと、現在の作業が正しい方向に進む可能性があります。 いくつかの提案は本当に注意を払う価値があります。



グローバルオブジェクトの分離は、Webコンポーネントの重要な未実現シナリオです。 それまでは、実装に取り​​組んでいます。たとえば、今日のWebにコンポーネント性をもたらす最も成功した一般的な方法であるiframe要素に頼ることができます。

要素のカプセル化（iframe）

Iframe要素とその近縁：オブジェクト、フレームセット要素、および命令型windows.open（）API-すでに分離された要素サブツリーで機能する機能を提供します。 ただし、コンポーネントが単一のドキュメント内での作業を伴う場合、iframeにはHTMLドキュメント全体が含まれます。 2つの別個のWebアプリケーションが一緒にホストされているように、一方は他方の内部にあります。 それぞれに一意のドキュメントアドレス、グローバルスクリプト環境、およびCSSスコープがあります。 各ドキュメントは完全に別のものです。



iframeは、これまでで最も成功した（そして唯一の広く実装された）Webコンポーネント化の形式です。 Iframeは、さまざまなWebアプリケーションの相互作用を可能にします。 たとえば、多くのサイトでは、広告からユーザーのログインまで、あらゆる種類のシナリオのコンポーネントの形式としてiframeを使用しています。 ただし、iframeには多くの課題があり、これらの課題に対処する方法がいくつか登場しました。

• 1つのHTMLドキュメント内のJavaScriptコードは、別のドキュメントの分離境界に侵入する可能性があります（たとえば、iframe要素のcontentWindowsプロパティを通じて）。 この境界線を破る可能性は必要な場合がありますが、iframeのコンテンツに私が共有したくない機密情報が含まれている場合、セキュリティ上のリスクももたらします。 現在、不要な違反は共通のソースのポリシーによって規制されています。1つのソースからのURLを持つドキュメントはデフォルトで境界に違反する可能性がありますが、異なるソースからのドキュメントは相互作用する可能性が限られています。
• セキュリティリスクは国境を越えることだけではありません。 <iframe sandbox>属性を使用すると、iframeで使用可能な不要なスクリプト、ポップアップ、ナビゲーションの変更、およびその他の機能からホスト環境を保護するために、他のソースからのiframeにさらに制限が課せられます。
• 外部ドキュメントのCSSスタイルは、内部ドキュメントに適用できません。 このアーキテクチャソリューションは、分離の原則に従います。 ただし、スタイルの分離により、コンポーネントとしてのiframeの統合に大きなギャップが生じます（共通のソース内）。 HTMLは、共通のソースを持つiframeに対して提案された<iframe seamless>属性でこの問題に対処します。 この「シームレス」属性により、フレームコンテンツスタイルの分離がなくなります。 シームレスに含まれるドキュメントは、ホストドキュメントのスタイルのコピーを取り、それらが含まれるiframe要素に制限がないかのように表示されます。

優れたセキュリティポリシーとフレームをシームレスに埋め込む機能により、iframeをコンポーネントのモデルとして使用することは非常に魅力的なソリューションのようです。 ただし、Webコンポーネントモデルで望ましいいくつかのプロパティがまだありません。

• 深い統合。 iframeは、ホストとフレームドキュメント間のモデルの統合と相互作用を制限します（基本的に完全に無効にします）。 たとえば、ホストに関して、フォーカスと割り当てのモデルは独立しており、イベントの送信は1つまたは別のドキュメントによって分離されます。 より緊密な統合が必要なコンポーネントの場合、ホストドキュメントに「エージェント」を導入しない限り、この動作をサポートすることはできません。これにより、国境を越えて情報が転送されます。
• グローバルオブジェクトの複製。 ページで作成された各iframeエンティティには、一意のグローバルオブジェクトがあります。 グローバルオブジェクトとそれに関連する完全な型システムは、作成するのに安価ではなく、大量のメモリ消費と過度のブラウザ負荷につながる可能性があります。 同じページで使用される同じコンポーネントの複数のコピーを互いに分離する必要はありません。実際には、一般的な状態を維持する必要がある場合は特に、共通のグローバルオブジェクトの存在が望ましい場合があります。
• ホストコンテンツを使用するためのモデル。 Iframeでは、フレームドキュメント内でホスト要素コンテンツモデルを再利用できません。 （簡単にするために、要素のコンテンツモデルは、サポートされている要素とテキストのサブツリーです。）たとえば、選択要素には、オプション要素を含むコンテンツモデルがあります。 コンポーネントとして実装されたSelect要素は、何らかの方法で子要素と対話する必要があります。
• 選択的なスタイリング。 シームレスiframeは、さまざまなソースのドキュメントでは機能しません。 これが許可された場合、明確なセキュリティリスクがあります。 主な問題は、「シームレス」がフレームドキュメントではなくホストによって制御されることです（厚いフレームドキュメントは攻撃の犠牲者です）。 コンポーネントの場合、「シームレス」を有効にする2桁の機能（高価かどうか）は高すぎる可能性があります。 むしろ、すべてのスタイルを自動的に継承するのではなく、ホストのどのスタイルをコンテンツに適用するかをコンポーネントが選択的に決定したいのです。つまり、これがシームレス性の仕組みです。 一般に、何をスタイルするかという問題は、コンポーネント自体で解決する必要があります 。
• APIを設定します。 Webコンポーネントの多くのシナリオには、独自のAPIセット、表示セマンティクス、およびライフサイクル管理を備えた本格的なカスタム要素の作成が含まれます。 iframeを使用すると、開発者はすべての機能を備えたiframe APIのフレームワーク内での作業に制限されます。 たとえば、iframe自体のパラメーターとそのライフサイクルに影響を与えることはできません。

これは初めてではありません。

過去に、HTMLおよび関連するカプセル化機能のiframe作業を改善する試みで、いくつかの技術がすでに提案され、導入されていることにも注意してください。 ただし、現代のWebでそれらのどれも大部分が根付いていない：

• HTML Components （1998）は、IE5.5（IE10で非推奨）以降、Microsoftによって提案および実装されました。 ホスト要素にイベントとAPIを追加し（分離を考慮）、「ビューリンク」（「シャドウDOM」など）のコンポーネントを解析するために宣言型モデルを使用することになっています。 2つのタイプのコンポーネント動作が利用可能です。1つは一時的に要素にアタッチされ、もう1つはCSSの「動作」プロパティを介して動的にバインドされました。
• XBL （2001）とその後継のXBL2 （2007）は、インターフェースを記述するためのXUL言語を補完するものとしてMozillaによって提案されました。 これは2つのバインディングオプション（MicrosoftのHTMLコンポーネントに類似）を備えた宣言型言語であり、XBLはホストコンテンツモデルにアクセスしてコンテンツを生成するための追加機能もサポートしていました。

最新のWebコンポーネント

最初の2回の試行が失敗した後、コンポーネントで再びゲームを開始しようとする時が来ました。今回はGoogleがビジネスに取りかかりました。 XBLで説明されている概念を出発点として使用して、モノリシックコンポーネントシステムはコンポーネントのビルディングブロックのコレクションに分割されました。 これらのビルディングブロックにより、Web開発者は、Webコンポーネントの全体的なビジョンが完全に定義される前に、個々の有用な機能を試すことができました。 アプローチ自体のコンポーネントと個々の有用な機能の開発により、成功に近づくことができました。 ほとんどすべての人が、アプリケーションのWebコンポーネントで何か役立つものを見つけることができます！



Webコンポーネントのこの新しい波は、既存の埋め込み要素が今日のWebプラットフォーム内でどのように機能するかを説明する一連のケーススタディにつながりました。 理論的には、Webコンポーネントを使用すると、開発者はネイティブ要素と同じ精度と機能で新しいタイプのHTML要素のプロトタイプを作成できます（実際、HTMLでアクセシビリティを実現することは今日特に困難です）。



Webコンポーネントを使用するためのすべてのシナリオをカバーするために必要なすべてのテクノロジーの完全なセットが、ブラウザーにすぐには実装されないことは明らかです。 ブラウザ開発者は協力して、追加のシナリオに進む前に一貫して実装できる基本的なテクノロジセットについて合意します。



Webコンポーネントの第1世代には以下が含まれます。

• カスタム要素。 カスタム要素はHTMLパーサーの拡張ポイントを定義して、新しい「カスタム要素」の名前を認識し、自動的に必要なJavaScriptオブジェクトモデルを提供できるようにします。 カスタム要素はコンポーネントの境界を作成しませんが、ブラウザーがAPIおよびビヘイビアーを作成者要素に添付する方法を提供します。 カスタム要素をサポートしていないブラウザは、イベントを使用してオブザーバーを変更し、プロトタイプを調整して、ある程度の精度で（親友を介して）それらをシミュレートできます。 結果の適切な計画と理解は、今後の会議の重要な要素です。
• • 属性「is」 。 カスタム要素の仕様内に隠されていますが、重要な機能を提供します-インライン要素がカスタム要素の名前と新しいAPIを受け取る必要があることを示す機能。 通常、カスタム要素は一般的な要素に基づいています。 「is」を使用すると、ネイティブ要素を基礎として使用できます（たとえば、<input is =” custom-input”>）。 この機能は、組み込みのレンダリング、アクセシビリティ、解析などの利点を継承するのに最適な方法ですが、この機能の構文はハックである可能性が高く、ネイティブ要素のアクセシビリティとスタイル設定のプリミティブが長期的にはより適切であるという意見があります標準化の方法を計画します。
• シャドウDOM （シャドウDOM）。 ホスト要素に（一度だけ）接続できる個別の要素ツリーを作成するための命令型APIを提供します。 このような「影」の子孫は、ドキュメントを表示するときに「実際の」子孫を置き換えます。 また、シャドウDOMは、新しいスロット要素（最近提案された）を使用してホスト要素コンテンツモデルを使用するメカニズムを提供し、イベントのターゲット要素でタスクを解決し、オープン/クローズ操作モードを追加します（最近追加されました）。 この比較的些細なアイデアには、フォーカスと選択モデルから構成と配布（シャドウDOM内のシャドウDOM）に至るまで、驚くほど多数の副作用があります。
• • CSS スコープは、ホスト、::コンテンツ（間もなく、おそらく::スロットになる）、および公式に否認された以前の「>>>」（ピアスシャドウDOMコンビネーター）を含む、シャドウDOMの関連スタイリング、さまざまな擬似要素を定義します。
• テンプレート要素 。 図を完成させるために含まれています。この機能は以前はWebコンポーネントの一部でしたが、現在はHTML5勧告の一部です。 テンプレート要素は慣性の概念を導入します（テンプレートの子要素はリソースをロードしない、ユーザー入力に応答しないなど）。 これは、HTMLで無関係な要素サブツリーを宣言的に作成する方法です。 テンプレートは、実際のサンプルテンプレートやデータバインディングからシャドウDOMのコンテンツの提供まで、さまざまなタスクに使用できます。
• HTMLインポート HTMLをドキュメントに「インポート」（要求、ロード、または解析）するための宣言構文を定義します。 インポートリクエスト（rel =” import”でlink要素を使用）は、ホストページのコンテキストでインポートされたドキュメントのスクリプトを実行します（したがって、同じグローバルオブジェクトと状態にアクセスできます）。 WebコンポーネントのHTML、JavaScript、およびCSSパーツは、それぞれ1回のインポートでロードできます。
• カスタムプロパティ 。 上記で詳細に説明したように、コンポーネントの外部で説明され、コンポーネント内で使用可能なカスタムプロパティは、今日のコンポーネントのスタイル設定のためのシンプルで便利なモデルです。 これを念頭に置いて、Webコンポーネントの第1世代のテクノロジーにカスタム機能を含めました。

Webコンポーネント：次世代

この記事の冒頭で述べたように、フル機能のWebコンポーネントを構築するのは素晴らしい冒険です。 現在の世代の機会のギャップを開発して埋めるためのいくつかのアイデアは、すでに開発者の間で広まり始めています（これは完全なリストではありません！）。

• 宣言型シャドウDOM コンポーネントをシリアル形式で転送する方法を考えると重要になります。 宣言的なフォームがないと、innerHTMLやXMLSerializerなどの手法では、シャドウコンテンツを含むDOMの文字列表現を構築できません。 言い換えると、現在のシャドウDOMは、スクリプトの助けなしでは文字列に変換できず、その逆もできません。 Mozillaのアンは 、議論のためのトピックとして<shadowdom>要素を提案しました 。 同様に、テンプレート要素はすでに「シャドウ」マークアップを構築する宣言的な方法であり、ブラウザのシリアル化メソッドはこの可能性を考慮して適切にテンプレートの「シャドウ」コンテンツをシリアル化するように既に調整されています。
• 完全に分離されたコンポーネント 。 この分野では、3 つのブラウザメーカーが3つの異なるオファーを提供しました。 これらの提案はすでに十分に合意されており、コンセンサスの観点からは朗報です。 前述したように、分離されたコンポーネントは新しいグローバルオブジェクトを使用し、他のソースからインポートできます。 また、APIと関連する動作を分離境界を越えて公開するための合理的なモデルも用意されています。
• アクセシビリティプリミティブ 。 多くのアクセシビリティコミュニティは、JavaScript開発者が常に利用できるわけではないアクセシビリティメカニズムを既に含んでいるため、既存のネイティブ要素を拡張する方法として「カスタム要素からの」という考えに共感します。 理想的には、従来のWebコンポーネント（「is」を使用しない）には、フォームの送信やフォーカス機能など、ネイティブ要素とほぼ同じ方法でアクセシビリティの側面を含めることができます。 このような拡張ポイントは今日では不可能ですが、解決して定義する必要があります。
• ネイティブコントロールの統一されたスタイル 。 ブラウザー間のコントロールの一貫したスタイリングモデルの可用性のギャップは相互運用性の問題であり、たとえば、「テーマを変更する」ための単純な拡張機能の普及を妨げます。 これにより、開発者は多くの場合、シャドウDOMを代替ソリューションと見なします（ただし、シャドウDOMでネイティブ要素の動作と同様の動作でマークアップを作成するのは簡単ではありません）。コントロールのスタイリングに関するいくつかのアイデアは、CSSコミュニティを歩き回っていますが、多くの要求がなければ、適切な速度で作業することはできません。
• 部分的なCSSスタイル。カスタムCSSプロパティはWebコンポーネントのスタイル設定に幅広いオプションを提供できますが、コンポーネント内に配線された一部のブロックをスタイル設定する設定がより直接的で適切である追加シナリオがあります。これは、既存のブラウザがネイティブコントロールの部分的なスタイル設定を公開するために使用するアプローチを合理化する場合にも特に便利です。
• . , . -.

, -, iframe . , iframe – -, , . «» iframe. , <iframe seamless> .



- – . . @msedgedev .