CSSスコーピングモジュール レベル1

概要

この仕様書は、スコープ付きスタイルや@scope規則、Shadow DOMセレクタ、ページ／領域ベースのスタイリングなど、CSSの様々なスコーピング／カプセル化メカニズムを定義します。 CSSは、構造化文書（HTMLやXMLなど）のレンダリングを画面、紙、音声などで記述するための言語です。

この文書のステータス

目次

1 はじめに

...

2 スコープ付きスタイル

スコープ付きスタイル規則は、ドキュメント全体ではなく、ドキュメントの部分木内のみに適用されます。 スコーピングには主に2つの効果があります:

• スコープ付きスタイル規則のセレクタは、スコープ内の要素のみにマッチするよう制限されます。 詳細はスコープ付きセレクタを[SELECTORS4]で参照してください。
• カスケードは、どんな詳細度であってもスコープ付き規則を非スコープ規則より優先します。 詳細はスコープによるカスケードを[CSS3CASCADE]で参照してください。

2.1 スコーピングメカニズム

スタイル規則は、ドキュメント言語で定義された構造や、CSSの@scope規則を使ってスコープ化できます。

2.1.1 スコーピングのためのドキュメントマークアップ

ドキュメント言語は、スタイルシートをドキュメント内の特定要素にスコープする仕組みを定義できる場合があります。 例えばHTMLでは、style要素にscoped属性を付けることで、そのスタイルシートをstyle要素の親要素にスコープします。 [HTML]

2.1.2 CSSのスコーピング構文：@scope規則

@scopeアットルールは、著者がCSS構文でスコープ付きスタイル規則を作成できるようにします。 @scope規則の構文は次のとおりです:

@scope <selector> {
  <stylesheet>
}

ここで<selector>でマッチした要素がスコーピングルートとなり、<stylesheet>内のスタイル規則に対して適用されます。また、@scopeでスコープされたスタイル規則のセレクタは、自身のスコーピングルートにスコープ制限されます。

この規則により、著者がスコープ付きスタイルシートを非常に簡単に作成できるため、スコープ付きスタイルの実装における最適化戦略へ影響する可能性があります。

複数の要素が<selector>にマッチした場合、<stylesheet>はそれぞれ独立して複製され、個別にスコープされます。 著者は、あまりにも一般的なセレクタの利用を避けるべきです。なぜならカスケードとの相互作用で混乱が生じる可能性があるためです。

@scope div {
  span {
    color: blue;
  }
}
@scope section {
  span {
    color: orange;
  }
}

<div>
  <section>
    <div>
      <span>text</span>
    </div>
  </section>
</div>

@scope規則はネストできます。 この場合、ネストしたスタイル規則と同様に、外側の@scopeのセレクタが、内側のものをスコープで包含します。

@scope規則内のセレクタの詳細度（specificity）はローカルに計算されます。スコーピング要素を指定するセレクタは無視されます。ただし、スコープ付きスタイルは非スコープ付きスタイルよりも優先されるため、@scope内のスタイル規則は外側の規則を上書きします。

  @scope aside {
    p { color: green; }
  }
  aside#sidebar p { color: red; }

複数の@scope規則が要素に適用された場合、それらは詳細度でカスケードされるべきでしょうか？

2.2 スコーピングコンテキストのクエリ

2.2.1 スコーピングルートの選択：:scope疑似クラス

スコープ付きスタイルシート内では、:scope疑似クラス（[SELECTORS4]で定義）は、スコーピングルートにマッチします。

2.2.2 スコープ外の選択：:scope-context()疑似クラス

:scope-context(<selector>) div {...}
scope(<selector>) div {...}
\scope <selector>\ div {...}
<selector> \scope\ div {...}

3 シャドウカプセル化

Shadow DOM仕様は、DOMにいくつかの新しい概念を追加しており、そのうちいくつかはCSSと関連します。

シャドウツリーは、DOM内のどんな要素にもアタッチできるドキュメントフラグメントです。 シャドウツリーのルートはシャドウルートであり、これはシャドウホストに関連付けられる非要素ノードです。 1つの要素は任意の数のシャドウツリーを持つことができ、それらは作成順に並びます。 ある要素の直近で作成されたシャドウツリーが、その要素にとってのアクティブシャドウツリーです。

シャドウツリーを持つ要素はシャドウホストです。 それは自身のシャドウツリーに対してのホスト要素となります。

シャドウホストの子孫は、フォーマットツリーでボックスを生成してはなりません。 代わりに、アクティブシャドウツリーの内容が、その要素の内容であるかのようにボックスを生成します。

シャドウDOM内では、要素が要素の親を持たない場合があり（その代わり親がシャドウルートなどの場合があります）、親を持たない、または親が要素でない要素はトップレベル要素と呼ばれます。

シャドウホストの子は通常ボックスを生成しませんが、明示的にシャドウツリーへ引き込んで通常通りレンダリングさせることができます。 これは要素を配布リストに割り当てることで行います。 配布リストを持つ要素は挿入ポイントとなります。

この仕様では、要素を配布リストへ割り当てる方法は定義せず、それはShadow DOM仕様に委ねています。 この仕様の執筆時点では、content要素だけが、シャドウツリー内で配布リストを持つことができます。

挿入ポイント自身はボックスを生成してはなりません。 代わりに、その配布リスト内の要素が通常通りボックスを生成し、すべての要素が挿入ポイントの位置に置き換えられるかのように振る舞います。 （これはdisplay-box: contentsの動作に似ています。）

3.1 シャドウDOMの選択モデル

要素ツリー内の要素は、さらに0個以上のシャドウツリーおよび0個または1個の配布リストを持ちます。

注: 要素の「子孫」は、その要素の子を基準にしています。シャドウツリーや配布リストは含みません。

セレクタがシャドウツリーに対してマッチングされるとき、初期セレクタマッチリストは、シャドウホスト、続いてシャドウツリーのすべてのトップレベル要素とその子孫（先行順で並ぶ）となります。

3.1.1 シャドウツリー内でのホスト要素

シャドウホストは、自身がホストするシャドウツリーの外部にありますが、時にはシャドウツリーの文脈からそれをスタイルしたい場合があります。

セレクタの観点では、ホスト要素もまた、それぞれのシャドウツリー内に現れ、そのシャドウツリーの内容が子として扱われます。 要素が複数のシャドウツリーを持つ場合、それぞれのシャドウツリーの文脈で独立して現れます。 各シャドウツリーは自身の内容だけをホスト要素のものとして扱い、他のシャドウツリーは見えません。

ホスト要素は、あらゆる手段でも選択できず、例外は:hostと:host-context()疑似クラスのみです。 つまり、この文脈でシャドウホストはタグ名、ID、クラス、属性を持たず、追加情報は:host疑似クラスが一致することだけです。 特に、ホスト要素は*セレクタでもマッチしません。

3.2 シャドウDOM用セレクタ

Shadow DOMは、Shadow DOMに関係した要素を便利に選択できる新しいセレクタをいくつか定義しています。

このセクションはまだ議論中です。 以下の機能の直感的な構文について、フィードバックや提案を歓迎します。

3.2.1 ライト側の選択：:host、:host()、:host-context()疑似クラス

:host疑似クラスは、シャドウツリーの文脈で評価された場合、そのシャドウツリーのホスト要素にマッチします。 他の文脈では何にもマッチしません。

:host()関数疑似クラスの構文は次の通りです:

:host( <compound-selector> )

シャドウツリーの文脈で評価された場合、シャドウツリーのホスト要素が、通常の文脈でセレクタ引数にマッチした場合に一致します。 それ以外の文脈では、何にもマッチしません。

  <x-foo class="foo">
    <"shadow tree">
      <div class="foo">...</div>
    </>
  </x-foo>

通常、シャドウツリー内のセレクタは、シャドウツリー外の要素を参照できません。 しかし、時にはシャドウツリーの外側で上位にある祖先要素を選択できると便利な場合があります。

:host-context()関数疑似クラスは、シャドウツリー外に条件を満たす祖先が存在するかどうかを判定します。 構文は次の通りです:

:host-context( <compound-selector> )

シャドウツリーの文脈で評価された場合、:host-context()疑似クラスは、ホスト要素またはその祖先のいずれかが指定された<compound-selector>にマッチすれば、ホスト要素にマッチします。 この疑似クラスにおける「祖先」は次の通りです:

要素が配布リストに配布されている場合

要素が最終的に配布されるcontent要素。

要素がシャドウツリー内の最上位要素である場合

ホスト要素

それ以外の場合

要素の親（存在すれば）。

注: これは、セレクタが引数にマッチする要素を探しながらシャドウ境界を貫通して上へたどり、ドキュメントルートに到達するまで繰り返すことを意味します。

3.2.2 闇への選択：::shadow 疑似要素

要素が1つでもシャドウツリーを持つ場合、::shadow疑似要素はシャドウルート自体にマッチします。 HTMLにおいて、シャドウルートはShadowRootオブジェクトによって表現されます。

::shadow疑似要素は、他の仕様で特に指定されていない限り、ボックスを生成してはなりません。 ただし、セレクタの観点では、::shadow疑似要素はシャドウツリーのルートと見なされ、シャドウツリー内のトップレベル要素が::shadow疑似要素の直接の子となります。

  <x-foo>
    <"shadow tree">
      <div>
        <span id="not-top">...</span>
      </div>
      <span id="top">...</span>
    </>
  </x-foo>

3.2.3 シャドウ投影コンテンツの選択：::content 疑似要素

::content疑似要素は、配布リストを持つ要素において、その配布リスト自体にマッチします。

::contentは、シャドウツリーの投影コンテンツ専用であるにもかかわらず、やや一般的過ぎる名前です。

::content疑似要素は、他の仕様で特に指定されていない限り、ボックスを生成してはなりません。 ただし、セレクタの観点では、::content疑似要素は、配布リスト内の要素たちの親と見なされます。

  <x-foo>
    <div id="one" class="foo">...</div>
    <div id="two">...</div>
    <div id="three" class="foo">
      <div id="four">...</div>
    </div>
    <"shadow tree">
      <div id="five">...</div>
      <div id="six">...</div>
      <content select=".foo"></content>
    </"shadow tree">
  </x-foo>

3.2.4 シャドウ越しの選択：/deep/結合子

セレクタ内で/deep/結合子が現れた場合、 セレクタマッチリスト内のすべての要素を 元の要素から子リストやシャドウツリーを任意回数たどって到達可能なすべての要素で置き換えます。

  <x-foo>
    <"shadow tree">
      <div>
        <span id="not-top">...</span>
      </div>
      <span id="top">...</span>
      <x-bar>
        <"shadow tree">
          <span id="nested">...</span>
        </>
      </x-bar>
    </>
  </x-foo>

これは基本的にスーパー子孫結合子です。 子孫結合子に本当の記号があれば、それを単純に2つ重ねるのも面白いかもしれません。 子孫結合子に>>の別名をつけてもいいかもしれませんが、これはスーパー子結合子なのでしょうか？ すると/deep/は>>>と書けるかもしれません。

3.3 シャドウのカスケードと継承

3.3.1 カスケーディング

シャドウルート内要素を対象とする規則の期待されるカスケード動作に対応するため、本仕様はカスケード仕様で定義されたカスケード順序を拡張します。[CSS3CASCADE]

オリジンとスコープの間に「シャドウツリー」という追加のカスケード基準を挿入する必要があります。

• 2つの宣言を比較する場合、 片方がシャドウツリー内にあり、もう片方がそのシャドウツリーを含むドキュメント内にあるとき、 通常の規則では外部ドキュメント側の宣言が優先され、 important規則ではシャドウツリー側の宣言が優先されます。

  注：これはスコープ付きスタイルの挙動とは逆です。

• 2つの宣言が、同じホスト要素を持つシャドウツリー内にある場合、 通常の規則では、より新しく作成されたシャドウツリー側の宣言が優先され、 important規則では、より古く作成されたシャドウツリー側の宣言が優先されます。

出現順の計算時には、Shadow DOM仕様で定義されたツリー構造を使って順序を決定します。

3.3.2 継承

シャドウツリーのトップレベル要素は、自身のホスト要素から継承します。

配布リスト内の要素は、最終的に配布されるcontent要素の親から継承し、通常の親からは継承しません。

4 フラグメントスタイリング

フラグメント化されたコンテンツは、その出現する行・列・ページ・領域などに応じて異なるスタイルを適用できます。 これは、適切なフラグメント疑似要素を使うことで実現でき、要素全体ではなく個々のフラグメントをターゲットできます。

例として、デザイナーは #region1 に流し込まれたテキストをダークブルーかつ太字にしたいと考えています。 このデザインは以下のように記述できます。

#region1::region p {
  color: #0C3D5F;
  font-weight: bold;
}

この例では、::region疑似要素の後にpの相対セレクタが来ています。 color および font-weight の宣言は、#region1内に表示される段落のフラグメントすべてに適用されます。 次の図は、#region1専用のスタイルを適用した場合のレンダリングの違いを示しています。 font-weightがnormalではなくboldになったことで、 このボックスに入るテキスト量が減ったことに注目してください。

注：この機能は::first-lineスタイリングの拡張です。

4.1 領域ベースのスタイリング：::region 疑似要素

::region 疑似要素は、CSS Regionにマッチするセレクタと、特定の名前付きフロー内のコンテンツのフラグメントにマッチする相対セレクタとの関係を表します。 これにより、特定の領域に流れ込む名前付きフローのフラグメントに対してスタイル宣言を適用できます。

<region selector>::region <content selector>  {
    ... CSS styling declarations ...
}

::region 疑似要素が1つ以上のCSS Regionsにマッチする セレクタに付加されると、 これは「フローフラグメント」セレクタを作成します。 フローフラグメントセレクタは、相対セレクタがマッチできるフロー内の要素の範囲を指定します。 相対セレクタは、選択された領域に部分的または完全に表示される名前付きフローの範囲内の要素にマッチできます（詳細は[DOM]を参照）。

フローフラグメント範囲に部分的または完全に含まれる要素は、相対セレクタにマッチする可能性があります。 ただし、スタイル宣言は対応する領域に表示されるその要素のフラグメントにのみ適用されます。

::region 疑似要素に適用されるプロパティは限定されたリストのみです：

このリストは機能的に継承可能なすべてのプロパティ、あるいはすべてのプロパティであるべきです。 なぜボックスプロパティを含むような、任意に見える部分集合なのか？

1. フォントプロパティ
2. color プロパティ
3. opacity プロパティ
4. background プロパティ
5. word-spacing
6. letter-spacing
7. text-decoration
8. text-transform
9. line-height
10. 整列および整形プロパティ
11. border プロパティ
12. 角丸プロパティ
13. border-image プロパティ
14. margin プロパティ
15. padding プロパティ
16. text-shadow
17. box-shadow
18. box-decoration-break
19. width

次の例では、名前付きフロー “article-flow” が “region-1” と “region-2” に流れ込みます。

<style>
  #div-1 {
    flow-into: article-flow;
  }

  #region-1, #region-2 {
    flow-from: article-flow;
  }

  /* region styling */
  #region-1::region p  {
    margin-right: 5em;
  }
</style>

<body>
  <div id="div-1">
      <p id="p-1">...</p>
      <p id="p-2">...</p>
  </div>
  <div id="region-1"></div>
  <div id="region-2"></div>
</body>

• div div-1
• paragraph p-1
• paragraph p-2
• region-1 に収まるフローの範囲
• region-2 に収まるフローの範囲

領域スタイリングは、region-1 に収まるフローコンテンツに適用されます。 相対セレクタは、これらの段落が region-1 に流れ込むため、 p-1 と p-2 にマッチします。 p-2 のうち region-1 に流れ込むフラグメントだけが疑似要素によってスタイルされます。

::region 疑似要素内のすべてのセレクタはその特異性に寄与します。 したがって、上の例の ::region 疑似要素の特異性は、id セレクタの特異性と型セレクタの特異性を組み合わせた、101 になります。

特定の要素または要素フラグメントにマッチするセレクタ（上記の説明に従う）は、 CSS カスケーディング順序（[CSS21]で定義）に従って扱われます。

特定の領域におけるフラグメントのスタイルを照会する方法が必要になります。 getComputedStyle() だけでは不十分です。 なぜなら要素は複数の領域に存在し得て、それぞれのフラグメントが異なるスタイルを受ける可能性があるからです。

適合性

文書の記法

適合要件は、記述的な主張と RFC 2119 用語の組み合わせで表現されます。規範部分におけるキーワード "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY"、および "OPTIONAL" は RFC 2119 に従って解釈されます。 ただし、可読性のために本仕様ではこれらの語をすべて大文字で表記していない場合があります。

この仕様の本文は、明示的に非規範とマークされた節、例、およびノートを除き、すべて規範的です。[RFC2119]

本仕様の例は "for example" という語で導入されるか、または規範テキストから class="example" で区別されます。次のように:

情報的なノートは "Note" という語で始まり、class="note" で規範テキストと区別されます。

注：これは情報的なノートです。

適合クラス

本仕様への適合性は3つの適合クラスで定義されます：

style sheet

CSS style sheet。

renderer

スタイルシートの意味を解釈し、文書をレンダリングする UA。

authoring tool

スタイルシートを書く UA。

スタイルシートは、本モジュールで定義された構文を使用するすべての記述が、汎用の CSS 文法および各機能の個別文法に従って有効である場合、本仕様に適合します。

レンダラーは、適切な仕様によって定義された通りにスタイルシートを解釈することに加えて、本仕様で定義されたすべての機能を解析して正しくレンダリングすることで、本仕様に適合します。ただし、機器の制限により文書を正しくレンダリングできないことは、UA を非適合にしません（例えば、モノクロモニタで色をレンダリングする必要はありません）。

オーサリングツールは、本モジュール内の各機能の汎用 CSS 文法および個別文法に従って構文的に正しいスタイルシートを書き、本モジュールで説明されたスタイルシートの適合要件を満たす場合に本仕様に適合します。

部分的な実装

著者がフォワードコンパチブルなパース規則を利用してフォールバック値を割り当てられるように、CSS レンダラーはサポートがない at-rule、プロパティ、プロパティ値、キーワード、その他構文構成を無効として扱い（適切に無視する）必要があります。特に、UA はサポートされていない構成値を部分的に無視して、同じ多値プロパティ宣言内のサポートされている値だけを適用してはなりません：いずれかの値が無効と見なされる場合、CSS はその宣言全体を無視することを要求します。

実験的な実装

将来の CSS 機能との衝突を避けるため、CSS2.1 仕様はプロプライエタリおよび実験的拡張のためにプレフィックス付き構文を予約しています。

仕様が W3C の Candidate Recommendation ステージに達する前は、CSS 機能のすべての実装は実験的と見なされます。CSS 作業部会は、実装者に対してワーキングドラフトの機能を含むような実験的機能についてはベンダープレフィックス付き構文を使用することを推奨します。これにより、ドラフトの将来の変更による非互換を回避できます。

非実験的な実装

仕様が Candidate Recommendation ステージに達すると、非実験的な実装が可能になり、実装者は CR レベルの機能を仕様に従って正しく実装したことを示せる場合、プレフィックスなしの実装を公開するべきです。

CSS の相互運用性を確立・維持するため、CSS 作業部会は非実験的な CSS レンダラーがプレフィックスなし実装を公開する前に実装レポート（必要ならその実装レポートに使用したテストケース）を W3C に提出することを要請します。W3C に提出されたテストケースは、CSS 作業部会によるレビューと修正の対象となります。

テストケースと実装レポートの提出に関する詳しい情報は、CSS 作業部会のウェブサイト（http://www.w3.org/Style/CSS/Test/）を参照してください。質問は public-css-testsuite@w3.org 宛てに行ってください。

参考文献

規範的参考文献

参考的参考文献

索引

プロパティ索引

課題索引

:scope-context(<selector>) div {...}
scope(<selector>) div {...}
\scope <selector>\ div {...}
<selector> \scope\ div {...}