<body>要素のシャドウDOMは悪い考えですか？

ユースケース：呼び出され、モーダルダイアログボックス、100％のH/Wと他のすべての体の祖先のDOM要素の機能を取る必要があります。ページ/ Webアプリケーションごとに1つしかありません.Javascriptモジュールが到着したときにうまく実行されることがあります。<body>要素のシャドウDOMは悪い考えですか？

web-authorには、私のWebコンポーネントであるGoogle Mapsに<DIV></DIV>のようなものを簡単に提供することができますが、document.bodyにShadow DOMを付けることで本質的に悪いことはありますか？ Chromeでは間違いなくエラーフリーです。

関連の問題は、私は要素の影のDOMポストレンダリング置き換えることができますか？私はShadow DOM 1.0が要素ごとに1つのシャドーDOMしか許さないことを知っていますが、私の使用例は、実行時に、所与の時間的環境/雰囲気を満たすためにヒューリスティックに適切なテンプレートを組み立てる必要があります。私が考える一つの方法は、それによって、私はUIが所定の位置にあることが必要なものを知っているときは、レンダリングから任意の<SLOT>候補を防ぐ負荷時に空の影DOMを添付した、スワップ/クローン/でプレースホルダシャドウDOMを置き換えます本格的なリッジディジュテンプレートコンテンツ。だから、

： - 1）はOK HOSTとしてBODYですか？ 2）Shadow DOMを置き換えるためのベストプラクティスは何ですか？

出典

2017-05-18 McMurphy

。適切なホストを指定するようにWeb作成者に依頼することは、「より良く」、より柔軟に見えます。 – McMurphy

1）はOK HOSTとしてBODYですか？

はい

2）シャドウDOMを交換するためのベストプラクティスは何ですか？

次のいずれかを使用します

body.shadowRoot.innerHTML = [new template innerHTML]

か：

body.shadowRoot.replaceChild(newNodes, oldNode)

か：template.contentで

body.shadowRoot.innerHTML = '' 
body.shadowRoot.appendChild(newNodes)

それはいくつかに速くなることができるようにあなたが直接、すでに解析されたDocumentFragmentを取得状況は、template.innerHTMLtemplate literalsの利益を得て、いくつかの変数の値を含めることができます。潜在的に競合する異なるコンポーネントを強制的に、または少なくとも特異リソースに対して、座標によってカプセル化および単離の願望に反することになるdocument.bodyに付着素子あたり1つのシャドウDOMの限界と第2思考、上

出典

2017-05-18 13:42:35 Supersharp

とにかくbody要素を使わずに完全なW/Hモーダルダイアログを追加することができます。 – Supersharp

もう一度お返事ありがとうございます。まだ私はtemplate.innerHTMLよりもtemplate.contentの付加価値のニュアンスを理解していませんが、私は読んでいます。私は解析された要素とテキストを推測します。良いニュースは、シャドーDOMが閉じ込められていてもまだまだ閉めることができるということです。 INCLUDEに同意していないのは残念ですが、Webコンポーネントは確実に本物になっています！ – McMurphy

私の回答が更新されました – Supersharp

<body>要素のシャドウDOMは悪い考えですか？

答えて

関連する問題