シャドウ DOM とは？

コンポーネントの境界が重要な理由

シャドウ DOM は、ブラウザが状態をどのように公開し、コンテンツをレンダリングし、自動化されたアクションが安全であるかを判断するかに影響します。正確な定義は、チームが狭い信号を普遍的な回答として扱うのを防ぎます。また、期待されるブラウザの振る舞いが文書化されたライフサイクル、API、またはシステム境界に結びついているため、テスト失敗が診断しやすくなります。

ウェブ自動化では、実際の質問は常に「ページは準備ができていますか？」や「ブラウザは本物に見えますか？」よりも狭いです。次のステップでは、1つのコントロールを有効にする必要があったり、1つのフレームがナビゲーションを完了するのを待ったり、1つのコンポーネントが内部ツリーを接続するのを待ったり、1つのレンダリングサーフェスを一貫性を保つ必要があるかもしれません。以下のセクションでは、この概念をフォークロアに頼るのではなく、観察可能なチェックに変えます。

シャドウ DOM 定義済み

シャドウ DOM は、要素がスコープされたスタイリングとカプセル化された実装の詳細を持つ別の DOM ツリーをホストできるウェブプラットフォームメカニズムです。ホストは、一般的にライト DOMと呼ばれるドキュメントの普通のツリーに留まります。添付されたツリーは ShadowRoot で始まり、コンポーネントの内部要素を含みます。

その MDN シャドウ DOM ガイド は、ホスト、シャドウツリー、シャドウ境界、シャドウルートを説明します。ブラウザはメディア要素などのコントロールに内部ツリーを長い間使用してきました。ウェブコンポーネント API は、サイト作成者が利用できる関連するカプセル化モデルを提供します。

シャドウは見えないという意味ではありません。内部ノードはスクリーンにレンダリングされ、イベントを受信し、アクセス可能なテキストを含み、レイアウトに参加します。境界は、選択子、スタイルルール、イベントパス、および DOM アクセスの動作を変更します。それはエンジニアリングの境界であり、情報が秘密であることを保証するものではありません。

ホスト、ルート、ツリー

シャドウホストは、シャドウルートが添付されている通常の要素です。シャドウルートは、内部ツリーを固定するドキュメントフラグメントです。コンポーネントは、ホストの shadowRoot プロパティによって返されるオープンルートを作成することも、外部コードに対して null を返すクローズドルートを作成することもできます。

オープンとクローズドは、API アクセスの選択であり、セキュリティの境界ではありません。クローズドルートを作成したコードは、自身の参照を保持でき、ブラウザのデバッグツールは内部構造を開示する可能性があります。敏感なデータは、クローズドモードが機密であると考えてコンポーネントに配置すべきではありません。

その WHATWG DOM 標準シャドウツリーモデル は、ツリーのルート、ホスト関係、イベントパス、リターゲティング動作を定義します。これらのルールは、内部ボタンで発生したイベントが、ターゲットがホストにリターゲティングされてコンポーネントの外で観察できる理由を説明します。

スタイルカプセル化

ドキュメントからの通常の選択子は、シャドウ内部に到達しません。コンポーネントは、関係のないページクラスと衝突することなく、内部クラス名を定義できます。内部スタイルルールもシャドウツリーにスコープされており、再利用可能なコンポーネントが周囲のドキュメントを無意識に再スタイリングするのを防ぎます。

境界は絶対的な隔離ではありません。色やフォントなどの継承プロパティは、ホストから流れることがあります。コンポーネントは、カスタムプロパティやパーツを介して意図的なスタイルフックを公開できます。擬似クラスや擬似要素は、コンポーネントの作成者と消費者に、すべての内部セレクタを公開することなくスタイルを調整するための制御された方法を提供します。

このモデルは保守性を向上させますが、テストコードを驚かせることがあります。コンポーネント移行前に機能していたセレクタは、コントロールがシャドウルートの背後に移動したために、同じ可視コントロールを見つけられなくなるかもしれません。修正はホストを選択し、サポートされているシャドウツリーに入ってから内部コントロールを探すか、明示的にシャドウ横断をサポートする自動化ロケータを使用することです。

スロットと構成ツリー

スロットは、コンポーネントのレンダリングされた構造内にライト DOM 子要素が表示されるべき場所を示します。供給されたノードは、ライト DOM のホストの子であり続けます。スロット割り当ては、ライトツリーとシャドウツリーが結合された後にユーザーが知覚する構造である構成レンダリングツリー内での位置を変更します。

名前付きスロットにより、コンポーネントは見出し、アイコン、アクションエリアなどの異なるカテゴリのコンテンツを配置できます。デフォルトスロットは、マッチするスロット名がないノードを受け取ります。コンポーネントは、ノードが割り当てられないときに表示されるフォールバックコンテンツを提供できます。

自動化は視覚的配置から所有権を区別する必要があります。スロットされたボタンは、コンポーネント内に表示されるにもかかわらず、ライト DOM 子として見つけられる場合があります。内部シャドウボタンはシャドウの横断が必要です。ライブ DOM とスロットの割り当てを検査することで、不必要なディープセレクタを防ぎます。

シャドウ DOM とカスタム要素

カスタム要素とシャドウ DOM は相補的ですが、独立しています。 HTML カスタム要素仕様 は、作成者が新しい要素名とライフサイクルコールバックを登録する方法を定義します。カスタム要素は、シャドウルートを追加したり、ライト DOM のみをレンダリングしたり、両方のアプローチを組み合わせることができます。

ライフサイクルのタイミングは重要です。ホストは、そのカスタム要素の定義が読み込まれる前、またはそのシャドウツリーが接続される前に、解析されたドキュメント内に存在することがあります。内部コンテンツを即座に検索する自動化は、早すぎるタイミングで実行される可能性があります。コンポーネントが定義されるのを待ち、シャドウルートが存在するのを待ち、内部のターゲット状態を待ってください。

宣言的シャドウDOMは、対応ブラウザがクライアントサイドの構築を待たずにテンプレートをシャドウルートに解析できるようにします。サーバーレンダリングされたコンポーネント内部をサポートし、初回レンダリングを改善することができます。テストコードは、ルートが宣言的に作成されたのか命令的に作成されたのかを仮定するのではなく、最終コンポーネント契約をターゲットにするべきです。

信頼性の高い自動化を影の境界を越えて

役割、ラベル、名前、コンポーネントレベルの契約を選好し、内的クラスの脆弱な連鎖を避けましょう。多くの自動化ライブラリは、サポートされているロケーター戦略のためにシャドウルートを突き破ることができますが、動作は異なります。セレクタがシャドウの境界を越えるかどうかを文書化し、単純なCSSセレクタが再帰的にグローバルであると仮定することを避けてください。

閉じたルートには異なる戦略が必要です。公開コンポーネントインターフェース、アクセス可能なセマンティクス、ライトDOMコントロール、またはアプリケーションチームとの協力を使用してください。すべてのルートを強制的に開くためにパッチを注入すると、テスト対象のアプリケーションが変更され、実際の統合問題が隠される可能性があります。テストにそれらを検査する明示的な診断理由がない限り、閉じた内部は実装の詳細として扱いましょう。

デバッグのために、ホストセレクタ、ルートモード、コンポーネント定義の状態、関連スロット、およびターゲットのアクセシブル名をキャプチャします。イベントが境界でリターゲットされているかどうかを確認します。クリックが失敗した場合、単に深いセレクタを追加するのではなく、可視性、ヒットテスト、オーバーレイ、およびコンポーネントの状態を確認します。

安定したコンポーネント契約の選択

最小限の条件または構成から始めて、タスクが進行できることを証明します。標準に適合したブラウザの動作を維持し、その後、ワークフローがそれらを必要とする場合のみプロファイルコントロールを追加します。ブラウザのビルドと関連する状態を記録して、後での違いを説明できるようにします。繰り返し可能な観察は、「ページ」「フレーム」「ディスプレイ」、またはフィンガープリントが単に「完了」または「安全」とされるという広範な主張よりも有用です。

• 次のアクションを定義します。 待機または設定ステップの後に、スクリプトまたはユーザーが何をすべきかを正確に記述してください。
• 観察可能な信号を選択してください。 ブラウザのプロパティ、ライフサイクル状態、要素の条件、またはそのアクションを直接サポートするレンダリング結果を選択してください。
• 規則： 1. 翻訳されたテキストのみを出力する — 説明や追加の囲みコードは不要です。 2. Markdown/HTML構造（見出し、リスト、リンク、表）を正確に保持します。 3. プレースホルダートークンのような@@CODEBLOCK_0@@や@@INLINECODE_0@@はそのまま正確に保持します；決して翻訳したり、順序を変更したり、統合したり、再フォーマットしたりしないでください。 4. ``` コードフェンスを追加したり削除したりしないでください。また、通常のテキストをコードブロックに囲むことはしないでください。 関連する値を一貫性を持たせてください。 ブラウザ、オペレーティングシステム、画面、ロケール、グラフィックス、セッション設定は、一つのもっともらしい環境を説明する必要があります。
• 通常のアプリケーションの動作を検証します。 プライバシーまたは自動化の介入は、変更されるAPIまたはコンポーネントを静かに壊してはいけません。
• 診断証拠をキャプチャする。 関連するURL、状態、コンソールメッセージ、およびチェックが失敗したときの設定名を保存します。

結論

Shadow DOMは、コンポーネントにスコープされた内部ツリーを提供し、より大きなドキュメントとアクセシビリティモデル内での位置を維持します。ホスト、ルート、スロット、スタイルのスコープ、イベントの再ターゲティングは、基本的なメンタルモデルを形成します。自動化は、境界を明示的に処理し、パブリックコンポーネントのセマンティクスを優先し、ドキュメント全体のCSSセレクターに依存する代わりにコンポーネントの定義と状態を待つときに成功します。

指定されたテキストは見つかりませんでした。別のテキストを提供してください。 Scrapeless Scraping Browser のドキュメント マネージドブラウザーセッションがどのように構成されるかを説明しますが、 スクレイピングブラウザ製品概要 ブラウザ自動化の表面を説明しています。これらのリソースは、承認されたワークフローでこの概念を適用するための製品コンテキストを提供します。

参照

• Scrapeless Scraping Browser のはじめにドキュメント
• Scrapeless Scraping Browser 製品概要
• スクレイプレスブラウザ自動化統合ガイド
• GitHub上のスクレイピングなしのオープンソースプロジェクト