以下は、私が準備して github repoにプッシュした簡単な例でこの問題を示しています。
ライト DOM のスタイル設定ルールを使用して、カスタム要素 "x-menu" (/x-menu.html 内) を作成しました。実際には、そうするための私の使用例は、CSS 変数とミックスインを使用して、ドキュメントとカスタム要素で使用される色、フォント スタックなどを定義することです。
Polymer 1.0 開発ガイドの関連部分で説明されているように、(/demo/index.html に) ドキュメント スタイルを定義するカスタム要素があり、ページのタイポグラフィ ルールが定義されています。
これは、Chrome のネイティブの Shadow DOM で問題なく動作します。
ただし、Shady DOM を使用すると、ドキュメントのスタイル設定は、x-menu 要素のスタイル設定よりも特異性の高いスタイル定義に解決されます。これは、Chrome の開発者ツールのスタイル スタックに表示されるようになりました。
ul:not([style-scope]):not(.style-scope), p:not([style-scope]):not(.style-scope) {
font-size: 12px;
color: red;
}
.container.x-menu ul, .container.x-menu p {
font-size: 30px;
color: green;
}
Shady DOM と Shadow DOM ポリフィルにはいくつかの制限があることを理解しています (webcomponents.org では、既知の制限は「CSS カプセル化が制限されている」と単純に述べています)。
考えられる回避策は 2 つありますが、どちらもあまり実用的ではありません。
- すべてのライト DOM ノードに CSS クラスを追加します (デモ ページで確認できます)。
- カスタム要素のユーザーはこれを覚えておく必要があり、CSS カプセル化の目標を無効にするため、これは実用的ではありません。
- CSS ミックスインをローカル スタイル定義に適用します。Shady DOM で処理すると、CSS はドキュメント レベルで「カスタム スタイル」よりも特異性が高くなります。
- これはより面倒になり、CSS の開発、保守、および処理に不要なオーバーヘッドが追加されます。
この問題に対する適切な回避策のアイデアを探しています。最悪の場合、要素のユーザーではなく、要素の開発者に責任を負わせたいと考えています。