3.1. ~shadow~DOMの説明

この節では、 この仕様が何を定義しているかを［ ~DOM標準 `DOM$r を全部的に把握せずに理解する ］のを援助するため、 ~DOMが規範的に定義するいくつかの概念を説明する。 ◎ The following is a non-normative explanation of several concepts normatively defined in the DOM Standard [DOM], to aid in understanding what this spec defines without having to fully grok the DOM Standard.

`SELECTORS4$r の `§ ~data~model＠~SELECTORS4#data-model$ に定義される要素~treeの各種特性に加え、 ~DOM標準は，`~shadow~tree$に関係するいくつかの新たな概念を追加している。 うちいくつかは~CSSにも関連する。 ◎ In addition to the qualities of an element tree defined in Selectors Level 4 § data-model, the DOM Standard adds several new concepts related to shadow trees, several of which are relevant to CSS.

要素 %~host は、 ある`~shadow~tree$ %~shadow~tree を~hostすることもある — その根である`~shadow根$ %~shadow根 は、 特別な種類の`文書片$である（要素~nodeではない）。 %~shadow根 の子孫は、 普通の要素その他の~nodeからなる。 %~host は、 %~shadow根 の`~host$であり， 【 %~shadow~tree を~hostする】`~shadow~host$になる。 ◎ An element can host a shadow tree, which is a special kind of document fragment with a shadow root (a non-element node) at its root. Children of the shadow root are ordinary elements and other nodes. The element hosting the shadow tree is its host, or shadow host.

%~shadow~tree 内の要素は、 一般に， %~host の`子孫$ではない （`子孫~結合子$の様な選択子の目的も含めて）。 しかしながら， %~shadow~tree は、 %~host が属する`~node~tree$（`~light~tree$） %~light~tree における`平坦~tree$の構築に利用される。 ~CSSにおいては、 この平坦~treeが，選択子`より後の^em すべての目的（継承や~boxの構築なども含む）に利用される。 ◎ The elements in a shadow tree are not descendants of the shadow host in general (including for the purposes of Selectors like the descendant combinator). However, the shadow tree, when it exists, is used in the construction of the flattened element tree, which CSS uses for all purposes after Selectors (including inheritance and box construction).

%~shadow~tree は、 概ね，［ %~light~tree における， %~host の通常の内容 ］に代わって %~host の内容として扱われる。 しかしながら，［ %~light~tree における %~host の子 ］も、 ある`~slot$ %~slot にアテガわれることにより， %~shadow~tree の “中に引き込まれる” ことはある — そのような子は、 ~CSSの目的においては %~slot の子として扱われる。 さらには、 %~slot も，より深い`~shadow~tree$内の`~slot$にアテガわれることもある。 幸いなことに，［ どの`~slot$も，それ自身は`既定では~boxを生成しない＠#slots-in-shadow-tree$ ］ので、［ %~shadow~tree を包装して~CSSを遮断している `slot$e 要素~FN の~cascade ］を作者が予測-不能になることはない。 【~FN ~slotを作成できるのは、この型の要素に限られる。】 ◎ Loosely, the shadow tree is treated as the shadow host’s contents instead of its normal light tree contents. However, some of its light tree children can be "pulled into" the shadow tree by assigning them to slots. This causes them to be treated as children of the slot for CSS purposes. The slots can then be assigned to slots in deeper shadow trees; luckily, slots themselves don’t generate boxes by default, so you don’t get an unpredictable cascade of slot wrapper elements disrupting your CSS.

`~slot$に何も明示的にアテガわれていない場合、 代わりに，`~slot$の自前の子たちが “既定の” 内容としてアテガわれる。 ◎ If nothing is explicitly assigned to a slot, the slot’s own children are instead assigned to it, as a sort of "default" contents.

3.2. ~shadow~DOMと選択子

:host( `compound-selector$t )

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

:host-context( `compound-selector$t )

<x-foo>
  <div id="one" slot="foo" class="foo">...</div>
  <div id="two" slot="foo">...</div>
  <div id="three" class="foo">
    <div id="four" slot="foo">...</div>
  </div>
  <“~shadow~tree”>
    <div id="five">...</div>
    <div id="six">...</div>
    <slot name="foo"></slot>
  </“~shadow~tree”>
</x-foo>

4.1. ~DOMから要素~treeへの平坦~化-法

選択子は，~host言語が提示する~DOM~treeに対し演算するが、 ~CSSの他の部分が［ 標準な［ 親／子 ］関係性を介することでは到達-不能な，別々な~tree ］に働くためには，~~単一化された~tree構造が必要になる。 これは、 `平坦~化された要素~tree@ （ `flattened element tree^en ） — 略して，`平坦~tree$（ `flat tree^en ） — と呼ばれ，次に従って構築される 【この “平坦~化” は、要素の入子ではなく，~treeの入子を平坦~化することを表す。】 ： ◎ While Selectors operates on the DOM tree as the host language presents it, with separate trees that are unreachable via the standard parent/child relationship, the rest of CSS needs a single unified tree structure to work with. This is called the flattened element tree (or flat tree), and is constructed as follows:

1. %根 ~LET 文書の`根~要素$ ◎ ↓
2. %処理待ち~node~list ~LET 新たな`~list$ — この~listは、 ( `~node^i, `親^i ) が成す~tupleとして与えられる~itemたちで拡充されることになる。 ◎ Let pending nodes be a list of DOM nodes with associated parents,＼
3. %処理待ち~node~list に ( %根, ε ) を`付加する$ ◎ initially containing just the document’s root element with no associated parent.
4. %平坦~tree ~LET %根 を根とする， %根 のみからなる新たな`平坦~tree$ ◎ ↓

5. ~WHILE［ %処理待ち~node~list は`空$でない ］： ◎ Repeatedly execute the following substeps until pending nodes is empty:

   1. %~item ~LET %処理待ち~node~list[ 0 ] ◎ ↓
   2. %処理待ち~node~list から %~item を`除去する$ ◎ Pop the first element from pending nodes, and assign it to pending node.
   3. %~node ~LET %~item の `~node^i ◎ ↓
   4. ~IF［ %~node ~NEQ %根 ］ ⇒ %~node を［ %~item の `親^i の`子$ ］として %平坦~tree の中へ挿入する ◎ Insert pending node into the flat tree as a child of its associated parent.＼ ◎ (If it has no associated parent, it’s the document root—just insert it into the flat tree as its root.)

   5. ~IF［ %~node は`~shadow~host$である ］： ◎ Perform one of the following, whichever is the first that matches: ◎ pending node is a shadow host

      1. %~node が~hostしている`~shadow~tree$の`~shadow根$の`子~群$を成す ~EACH ( %子~node ) に対し ⇒ %処理待ち~node~list に ( %子~node, %~node ) を`付加する$ ◎ Append the child nodes of the shadow root of the shadow tree it hosts to pending nodes, with pending node as their associated parent.
      2. ~CONTINUE

   6. ~IF［ %~node は`~slot$である ］：

      1. %~slot可能~list ~LET `~slot用に~slot可能を見出す$( %~node )

      2. ~IF［ %~slot可能~list は`空$でない ］：

         1. %~slot可能~list を成す ~EACH( %~slot可能 ) に対し ⇒ %処理待ち~node~list に ( %~slot可能, %~node ) を`付加する$
         2. ~CONTINUE
      ◎ pending node is a slot ◎ Find slottables for pending node, and append them to pending nodes, with pending node as their associated parent. ◎ ↓If no slottables were found for pending node, instead append its children to pending nodes, with pending node as their associated parent.
   7. %~node の（`~light~tree$における）`子~群$を成す ~EACH( %子 ) に対し ⇒ %処理待ち~node~list に ( %子, %~node ) を`付加する$ ◎ Otherwise, ◎ Append the child nodes of pending node’s light tree to pending nodes, with pending node as their associated parent.

これによる明白でない結果は、 ~slotにアテガわれた要素は、 その~slotから【~styleを】継承することである — 要素の~light~treeにおける親や, その~slotがアテガわれている より深い~slotでなく。 このことは、 【~slotにアテガわれた】~text~nodeは、 その親の~shadow~treeにより~styleされ，他からはどうやっても介入できないことを意味する。 そのような~text~nodeを~targetする追加的な疑似要素は，求まれるか？ — それらにも，要素のときと同様に~slotにアテガわれた下で【！at all slot-assignment levels】~styleできるよう。 このことは、 ~light~tree内の~text~nodeに対しても，~slotに【！downwards】アテガわれる前に，そのような疑似要素が働く必要があることを含意する。 なので、 これは，ただの `slotted()$pe の変種にはなり得ない。 `Luckily, this is a long-standing request!^en【何が `Luckily^en？】 ◎ A non-obvious result of this is that elements assigned to a slot inherit from that slot, not their light-tree parent or any deeper slots their slot gets assigned to. This means that text nodes are styled by the shadow tree of their parent, with nobody else capable of intervening in any way. Do we want an additional pseudo-element for targeting those text nodes so they can be styled at all slot-assignment levels, like normal elements can be? This implies it needs to work for text nodes in the light tree before they’re assigned downwards, so this can’t just be a ::slotted() variant. Luckily, this is a long-standing request!

4.2. 名前を定義する構成子と継承

`~shadow~tree$は、 ~capsule化の境界になること — 独立な作者たちが、 互いの名前空間を不用意に汚すことなく~codeを共有するのを許容すること — が意味される。 例えば要素~IDは、 一般に，文書の中で一意になることが意味されるが、 異なる`~shadow~tree$内であれば，複数回~利用されても妥当になる。 ◎ Shadow trees are meant to be an encapsulation boundary, allowing independent authors to share code without accidentally polluting each other’s namespaces. For example, element IDs, which are generally meant to be unique within a document, can be validly used multiple times as long as each use is in a different shadow tree.

同様に，~CSSにおける`~at-規則$のうちいくつか — `keyframes$at や `font-face$at など — は、［ ~prop／他の~at-規則 ］が［ 後で，それを参照rできる名前 ］を定義する。 これらの名前は，~IDの様に［ 大域的に公開され，同じ文書の中で一意になる ］が、 この制約もまた，今や~IDの様に［ 所与の`~shadow~tree$の中で一意になる ］よう緩められる。 ◎ Similarly, several at-rules in CSS, such as @keyframes or @font-face, define a name that later at-rules or properties can refer to them by. Like IDs, these names are globally exposed and unique within a document; also like IDs, this restriction is now loosened to being unique within a given shadow tree.

しかしながら，~prop継承は、 ある~treeから別の~treeへ値を運ぶこともあるため，所与の名前から正しい定義への参照-法は複雑化する。 これは，素朴に行われた場合、 作者を［ 驚かす／惑わす ］結果を生産し得る。 この節では、 “大域的” な名前を — ~capsule化を尊重して，驚かす結果を与えない仕方で — ［ 定義する／参照する ］ときに利用される概念を定義する。 ◎ However, property inheritance can carry values from one tree to another, which complicates referencing the correct definition of a given name. Done naively, this can produce surprising and confusing results for authors. This section defines a set of concepts to use in defining and referencing "global" names in a way that respects encapsulation and doesn’t give surprising results.

［ ~at-規則／~prop ］のうち，他の~CSS構成子から参照rできる名前を定義するものは （例： `font-face$at 規則の `font-family$d 記述子や `anchor-scope$p ~prop）、 それを `~tree視野な名前@ （ `tree-scoped name^en ） — その視野は ある~treeに絞られる名前 — として定義しなければナラナイ。 各`~tree視野な名前$には、 当の［ ~at-規則／~prop ］を宣言した~stylesheetを~hostしている`要素$の`根$が結付けられる。 ◎ If an at-rule or property defines a name that other CSS constructs can refer to it by, such as a @font-face font-family name or an anchor-scope name, it must be defined as a tree-scoped name. Tree-scoped names are associated with the root of the element hosting the stylesheet that the at-rule or property is declared in.

加えて，`~tree視野な名前$は、 次に挙げる 2 種に大別される： ◎ Additionally, tree-scoped names can be＼

• `緩く照合される@tsN もの ⇒ ［ 同じ~tree／子孫~tree ］内の`~tree視野な参照$に合致し得る。 ◎ loosely matched or strictly matched, defaulting to loosely matched unless otherwise specified.＼ A loosely matched tree-scoped name can be matched by tree-scoped references (see below) in the same tree or descendant trees,＼
• `厳密に照合される@tsN もの ⇒ 正確に同じ~tree内の`~tree視野な参照$にしか合致し得ない。 ◎ while a strictly matched tree-scoped name can only be matched by tree-scoped references in the exact same tree.

`~tree視野な名前$は、 他が指定されない限り，既定では`緩く照合される$tsNとする。 ◎ ↑

`~tree視野な名前$を参照する［ ~prop／記述子 ］ （例： `font-family$p, `animation-name$p ） は、 その値を `~tree視野な参照@ （ `tree-scoped reference^en ） — その視野は ある~treeに絞られる参照 — として定義しなければナラナイ。 `~tree視野な参照$は、 指定された値とともに，暗黙的に`~node~tree$の`根$を捕捉する — それは、 他が指定されない限り，当の［ ~prop／記述子 ］を宣言した~stylesheetを~hostしている`要素$の`根$になる。 この［ `根$への参照 ］は、 継承されても当の`~tree視野な参照$に伴い続ける。 ◎ Properties or descriptors that reference a tree-scoped name, such as the font-family or animation-name properties, must define their value as a tree-scoped reference. These references implicitly capture a node tree root along with their specified value: unless otherwise specified, the root of the element hosting the stylesheet that the property or descriptor is declared in. This root reference stays with the tree-scoped reference as it is inherited.

`~tree視野な名前$が `大域的@tsN である場合（ `font-face$at の名前など）、 それを見出すために`~tree視野な参照$ %参照 を参照解決するときは、 まず，関連な`~tree視野な名前$のうち［ それに結付けられた`根$が %参照 に結付けられた`根$と同じになるもの ］に限り探索する — 見出されなかった場合、 %参照 に結付けられた`根$は`~shadow根$であるならば，`根$の`~host$が属する`~node~tree$内でこの探索を（再帰的に）繰返す。 （言い換えれば、 大域的な`~tree視野な名前$は，子孫~shadow~treeの中へ — 子孫~tree自身が同じ名前を定義していない限り — “継承される” 。） ◎ If a tree-scoped name is global (such as @font-face names), then when a tree-scoped reference is dereferenced to find it, first search only the tree-scoped names associated with the same root as the tree-scoped reference. If no relevant tree-scoped name is found, and the root is a shadow root, then repeat this search in the root’s host’s node tree (recursively). (In other words, global tree-scoped names “inherit” into descendant shadow trees, so long as they don’t define the same name themselves.)

【 したがって、 大域的な`~tree視野な名前$は，常に`緩く照合される$tsNことになる。 】

`~tree視野な名前$ %名前 が，ある要素に `局所的@tsN である場合 （ `anchor-name$p の値や `anchor-scope$p の値など）、 所与の要素~上の`~tree視野な参照$ %参照 が %名前 に合致するかどうかは， %名前 が［ `厳密に照合される$tsN, `緩く照合される$tsN ］どちらなのかに依存する。 %名前 は`厳密に照合される$tsN場合、 %名前, %参照 どちらにも同じ~treeが結付けられている場合に限り合致する。 %名前 は`緩く照合される$tsN場合、 %名前 に先祖~treeが結付けられている場合にも合致する~FN。 ◎ If a tree-scoped name is local to an element (such as anchor-name or anchor-scope values), then whether a tree-scoped reference matches the tree-scoped name on a given element depends on whether the tree-scoped name is strictly or loosely matched. A strictly matched tree-scoped name only matches if both names are associated with the same tree. A loosely matched tree-scoped name also matches if the tree-scoped name is associated with an ancestor tree.

【~FN すなわち，`大域的$tsNな`~tree視野な名前$と同様に照合される。 】【 したがって、 `~tree視野な名前$を定義する~CSS構成子は，［ `大域的$tsN, `局所的$tsN ］どちらになるか（ “ある要素に局所的であるか否か” ）も定義する必要がある（下の課題）。 】

`~tree視野な名前$どうしを直に比較する際には （例えば，`算出d値$どうしを比較するとき）、 それらは，［ 互いの識別子のみならず，互いの`根$`も^em正確に合致する場合 ］に限り合致するものと見なされる （例えば，一方の根が他方の根の【`平坦~tree$における】先祖である場合、 `合致しない^em）。 ◎ If two tree-scoped names are directly compared (for example, when comparing computed values), they are considered to match only if their identifiers match, and their roots match exactly. (If one has a root that’s an ancestor of the other, for example, they do not match.)

<p class=outer>

ここでは、
`~light~tree$【！the outer document】の "`foo^v" ~fontが利用される。
◎
Here's some text in the outer document's "foo" font.

</p>
<style>
  @font-face {
    font-family: foo;
    src: url(https://example.com/outer.woff);
  }
  body { font-family: foo; }
  my-component::part(text) { font-family: foo; }
</style>

<my-component>
  <::shadow>
    <p class=inner-default>

これは、
~light~tree【！the outer document】の `font-family^p を継承している。
◎
I'm inheriting the outer document's font-family.

    </p>
    <p class=inner-styled>

ここでは、
`my-component^e 内の "`foo^v" ~fontを利用するよう，明示的に~styleされる。
◎
And I'm explicitly styled to be in the component's "foo" font.

    </p>
    <p class=part-styled part=text>

これは、
~light~tree【！the outer document】により明示的に~styleされ，
~light~tree【！the outer document】から "`foo^v" ~fontを取得する。
◎
I'm explicitly styled by the outer document, and get the outer document's "foo" font.

    </p>
    <style>
      @font-face {
        font-family: foo;
        src: url(https://example.com/inner.woff);
      }
      .inner-styled { font-family: foo; }
    </style>
  </::shadow>
</my-component>

<style>
  @font-face {
    font-family: foo;
    src: url(https://example.com/outer.woff);
  }
  body { font-family: foo; }
</style>

<child-component>
  <::shadow>
    <style>
      @font-face {
        font-family: foo;
        src: url(https://example.com/inner.woff);
      }
    </style>

    <grandchild-component>
      <::shadow>
        <p class=inner-default>

これは、
`~light~tree$【！the outer document】の "`foo^v" ~font を継承している。
◎
I’m inheriting the outer document’s "foo" font.

        </p>
        <p class=inner-search>

局所的な "`foo^v" ~fontは見出せなかったので、
~treeをさらに遡るよう探索した結果，~shadowの "`foo^v" ~fontが見出される。
◎
And I can’t find a local "foo" font, so I’m searching further up the tree, and find the shadow’s "foo" font.
        </p>
        <style>
        .inner-search { font-family: foo; }
        </style>
      </::shadow>
    </grandchild-component>
  </::shadow>
</child-component>

<p class=outer>

ここでは、
`~light~tree$【！the outer document】の "`foo^v" ~fontが利用される。
◎
Here’s some text in the outer document’s "foo" font.

</p>
<style>
  @font-face {
    font-family: foo;
    src: url(foo.woff);
  }
  body { font-family: foo; }
</style>

<my-component>
  <::shadow>
    <p class=inner-default>

これは、
`~light~tree$【！the outer document】の `font-family^p を継承している。
◎
I'm inheriting the outer document's font-family.

    </p>
    <p class=inner-styled>

ここでは、
`my-component^e 内の "`foo^v" ~fontを利用するよう，明示的に~styleされる。
◎
And I'm explicitly styled to be in the component's "foo" font.

    </p>
    <style>
      @font-face {
        font-family: foo;
        src: url(https://example.com/foo.woff);
      }
      .inner-styled { font-family: foo; }
    </style>
    <script>
      const %innerDefault = document.querySelector('.inner-default');
      const %innerStyled = document.querySelector('.inner-styled');
      const %defaultFont = getComputedStyle(%innerDefault).fontFamily;
      const %styledFont = getComputedStyle(%innerStyled).fontFamily;

      console.log(%defaultFont == %styledFont); // true!
    </script>
  </::shadow>
</my-component>

5.1. 動機

~custom要素の能力が — 組込みの要素と同程度に — 全部的に有用になるためには、 次がアリになるベキである ⇒＃ 要素を成す各~partを外側から~styleすること／ ~custom要素の作者が，外側から正確に何を~styleできるか制御すること／ ~custom要素が~style付け用に安定的な “~API” を呈示すること ◎終 すなわち、 ~custom要素を成す ある~partを~styleするために利用される選択子は、 当の要素の内部的な詳細~についての知識を［ 公開する／要求する ］ベキでない。 ~custom要素の作者は、 選択子には触れずに，当の要素の内部的な詳細を変更-可能になるベキである。 ◎ For custom elements to be fully useful and as capable as built-in elements it should be possible for parts of them to be styled from outside. Exactly what can be styled from outside should be controlled by the element author. Also, it should be possible for a custom element to present a stable "API" for styling. That is, the selector used to style a part of a custom element should not expose or require knowledge of the internal details of the element. The custom element author should be able to change the internal details of the element while leaving the selectors untouched.

~shadow~treeの内側に対する~style付け用として以前に提案された結合子 `~gt3^css 【“~shadowを貫く結合子” 】 は、 `強力~過ぎて^em~~元も~~子もないことが~~判明した — それは、［ ~componentの内部~構造を微細にわたり公開し過ぎる ］ため，［ `Shadow DOM^cite を利用することで得られる~capsule化の便益 ］の一部を無為にしていた。 この理由から, および他の処理能に関係する理由から、 `~gt3^css 結合子は最終的に落とされた。 ◎ The previous proposed method for styling inside the shadow tree, the >>> combinator, turned out to be too powerful for its own good; it exposed too much of a component’s internal structure to scrutiny, defeating some of the encapsulation benefits that using Shadow DOM brings. For this, and other performance-related reasons, the >>> combinator was eventually dropped.

唯一残された，~shadow~treeの中まで~styleする仕方は、 `~custom~prop$を利用することである： ~componentは、［ ある種の`~custom~prop^を利用して，自身の内部を~styleする ］よう広告する — 外縁~pageは、 自身が望む~propを`~shadow~host$上に設定することもでき， 値を必要な所まで奥深く継承させられる。 これは、 多くの単純な~theme法の利用事例には，とても上手く働く。 ◎ This left us with using custom properties as the only way to style into a shadow tree: the component would advertise that it uses certain custom properties to style its internals, and the outer page could then set those properties as it wished on the shadow host, letting inheritance push the values down to where they were needed. This works very well for many simple theming use-cases.

しかしながら、 これでは立ち往かない事例もある。 ある~componentが［ 自身の~shadow~tree内の何かに任意な~style付けを許容する ］よう望む場合、 何百もの`~custom~prop$を定義する他に仕方がない （制御を許容するよう望む~CSS~propごとに 1 個ずつ） — それは、 利用能, 処理能の両面で明白に馬鹿げている。 この状況は、 作者が［ ~componentの~styleを `hover$ps の様な疑似類に基づいて違える ］よう望む場合， さらに複合される — ~componentは、 利用する`~custom~prop^を各~疑似類~用に重複する必要がある （ `:hover:focus^css の様な各~組合nごとに必要になるので、 組み合わせは膨大になる）。 これは、 利用能と処理能の問題をさらに悪くする。 ◎ However, there are some cases where this falls down. If a component wishes to allow arbitrary styling of something in its shadow tree, the only way to do so is to define hundreds of custom properties (one per CSS property they wish to allow control of), which is obviously ridiculous for both usability and performance reasons. The situation is compounded if authors wish to style the component differently based on pseudo-classes like :hover; the component needs to duplicate the custom properties used for each pseudo-class (and each combination, like :hover:focus, resulting in a combinatorial explosion). This makes the usability and performance problems even worse.

`part()$pe は、 この事例を ずっと~elegantかつ高処理能に取扱うために導入される。 `~custom~prop$名の中に何もかも束ねるのでなく、 機能性は，元々意味された様に選択子と~style規則~構文~内に生き続ける。 これは、 ~componentの作者, その利用者どちらからも，ずっと利用し易くなることに加え、 処理能はずっと良くなるはずであり， より良い［ ~capsule化／~API表面化 ］を許容する。 ◎ We introduce ::part() to handle this case much more elegantly and performantly. Rather than bundling everything into custom property names, the functionality lives in selectors and style rule syntax, like it’s meant to. This is far more usable for both component authors and component users, should have much better performance, and allows for better encapsulation/API surface.

`part()$pe は、 `理論的には，新たな力を何ら提供しない^emことに注意。 それは， `~gt3^css 結合子の焼き直しではなく、 単純に，［ 作者が`~custom~prop$ですでに行える何か ］用の より簡便かつ一貫した構文である。 要素を成すある~part（`~part要素~map$）を明示的に “公表して”， 単に包含されるだけの下位-~partから分け隔てることは、 ~capsule化の一助にもなる — 作者は、 不用意に~styleし過ぎるおそれなしに `part()^pe を利用できるので。 ◎ It’s important to note that ::part() offers absolutely zero new theoretical power. It is not a rehash of the >>> combinator, it is simply a more convenient and consistent syntax for something authors can already do with custom properties. By separating out the explicitly "published" parts of an element (the part element map) from the sub-parts that it merely happens to contain, it also helps with encapsulation, as authors can use ::part() without fear of accidental over-styling.

5.2. ~shadow要素の命名-法： `part^a 属性

~shadow~tree内の どの要素にも `part@a 属性を指定できる。 これは、 要素を`~shadow~tree$の外側に公開するために利用される。 ◎ Any element in a shadow tree can have a part attribute. This is used to expose the element outside of the shadow tree.

`part$a 属性の値は、［ 当の要素の~part名を表現している~token ］たちが成す~space等で分離された~listとして構文解析される。 ◎ The part attribute is parsed as a space-separated list of tokens representing the part names of this element.

注記： 同じ~partに複数個の名前を与えてもかまわない。 “~part名” は、 `id^a や~tagnameではなく， `class^a に類似なものと見なすベキである。 ◎ Note: It’s okay to give a part multiple names. The "part name" should be considered similar to a class, not an id or tagname.

<style>
  c-e`::part(textspan)^mk { color: red; }
</style>

<template id="c-e-template">
  <span `part="textspan"^mk>
この~textの色は `red^v になる
◎
This text will be red
</span>
</template>
<c-e></c-e>
<script>
  /* 
`template^e を，~custom要素 `c-e^e として追加する
◎
Add template as custom element c-e
 */
  ...
</script>

5.3. ~shadow要素の回送-法： `exportparts^a 属性

~shadow~tree内のどの要素にも `exportparts@a 属性を指定できる。 要素は ある`~shadow~tree$ %~shadow~tree 内の`~shadow~host$である場合、 これは，［ 要素が~hostしている`~shadow~tree$の内側にある~partたちを， %~shadow~tree の外側にある規則で~styleする ］のを許容するために利用される（それらが［ %~shadow~tree 内にある， `part$a 属性で命名された要素 ］であったかのように）。 【文書~tree内にある, または~shadow~hostでない要素には、効果はない。】 ◎ Any element in a shadow tree can have a exportparts attribute. If the element is a shadow host, this is used to allow styling of parts from hosts inside the shadow tree by rules outside this the shadow tree (as if they were elements in the same tree as the host, named by a part attribute).

`exportparts$a 属性の値は、 ~commaで分離された`~part対応付けたちが成す~listとして構文解析される＠#_parse-a-list-of-part-mappings$。 各~part対応付けは、 次に挙げるいずれかとして与えられる： ◎ The exportparts attribute is parsed as a comma-separated list of part mappings. Each part mapping is one of:

%内縁~ident : %外縁~ident ◎ innerIdent : outerIdent

%子孫 の`回送される~part名~list$に ( %内縁~ident, %外縁~ident ) を追加する。 ◎ Adds innerIdent/outerIdent to el’s forwarded part name list.

【 各 “~ident” の構文は，明示的に定義されていないが、 他所の記述から， `ident$t に合致する文字列が想定されているであろう。 】

%~ident

%子孫 の`回送される~part名~list$に ( %~ident, %~ident ) を追加する。 ◎ Adds ident/ident to el’s forwarded part name list.

注記： これは、 %~ident : %~ident 用の略記である。 ◎ Note: This is shorthand for ident : ident.

%疑似要素~名 : %外縁~ident ◎ ::ident : outerIdent

%疑似要素~名 （ `::^l が接頭された~ident ）は、 `全部的に~style可能な疑似要素$の名前である場合、 %子孫 の`回送される~part名~list$に ( %疑似要素~名, %外縁~ident ) を追加する。 他の場合、 何もしない。 ◎ If ::ident is the name of a fully styleable pseudo-element, adds ::ident/outerIdent to el’s forward part name list. Otherwise, does nothing.

その他 ◎ anything else

［ ~error回復／将来の互換性 ］用にあり、 無視される。 ◎ Ignored for error-recovery / future compatibility.

注記： 下位-~partから複数個の名前へ~mapしてもかまわない。 ◎ Note: It’s okay to map a sub-part to several names.

<style>
  c-e`::part(textspan)^mk { color: red; }
</style>

<template id="c-e-outer-template">
  <c-e-inner `exportparts="innerspan: textspan"^mk></c-e-inner>
</template>

<template id="c-e-inner-template">
  <span `part="innerspan"^mk>
    
この~textの `color^p は `red^v になる
— 包含している~shadow~hostは，
`innerspan^v を `textspan^v として文書へ回送し，それは文書~styleに合致するので。
◎
This text will be red because the containing shadow host forwards innerspan to the document as "textspan" and the document style matches it.

  </span>
  <span `part="textspan"^mk>
    
この~textの `color^p は `red^v にならない
— 文書~style内の `textspan^v は、
回送されない場合には，内縁~custom要素の内側にある~partには合致し得ないので。
◎
This text will not be red because textspan in the document style cannot match against the part inside the inner custom element if it is not forwarded.

  </span>
</template>

<c-e></c-e>
<script>
  /* 
各 `template^e を，~custom要素 `c-e^e, `c-e-inner^e として追加する。
◎
Add template as custom elements c-e-inner, c-e-outer
 */
    ...
</script>

<template id=custom-element-template>
    <p exportparts="::before : preceding-text, ::after : following-text">
        Main text.
</template>

5.4. ~shadow要素の選択-法： `part()^pe 疑似要素

`part()@pe 疑似要素は、 `part$a 属性を介して公開された要素を選択することを，作者に許容する。 その構文は： ◎ The ::part() pseudo-element allows you to select elements that have been exposed via a part attribute. The syntax is:

::part() = ::part( `ident$t+ )

`part()$pe 疑似要素は、［ その`出自の要素$ %~host は`~shadow~host$である ］場合に限り，合致する。 ◎ The ::part() pseudo-element only matches anything when the originating element is a shadow host.

`part()$pe 疑似要素は： ◎ ↓

• `全部的に~style可能な疑似要素$【`要素が裏にある疑似要素$】である。 ◎ The ::part() pseudo-element is a fully styleable pseudo-element.＼
• その`出自の要素$が~hostしている`~shadow根$の`~part要素~map$ %~map に関して，次を満たす［ 要素【／疑似要素】 ］ %要素 を表現する ⇒ 引数に指定されたどの `ident$t %ident に対しても，次が満たされる ⇒ ［ %~map[ %ident ] ~NEQ ε ］~AND［ %要素 ~IN %~map[ %ident ] ］ ◎ If the originating element’s shadow root’s part element map contains the specified <ident>, ::part() represents the elements keyed to that ident; if multiple idents are provided and the part element map contains them all, it represents the intersection of the elements keyed to each ident. Otherwise, it matches nothing.
• その`出自の要素$が~hostしている~shadow~treeにおける，それら【それが表現する要素たち】の位置に則って継承する。 ◎ ::part() pseudo-elements inherit according to their position in the originating element’s shadow tree.

5.5. `Element^I ~interfaceに対する拡張

partial interface `Element$I {
  [`SameObject$, `PutForwards$=`value$m] readonly attribute `DOMTokenList$I `part$m;
};

`part$m

取得子は、 次のようにされた `DOMTokenList$I ~objを返すモノトスル ⇒＃ `要素$tL ~SET コレ, `属性~名$tL ~SET `part^l ◎ The part attribute’s getter must return a DOMTokenList object whose associated element is the context object and whose associated attribute’s local name is part.＼

この特定0の `DOMTokenList^I ~objを成す~token集合は、 要素の `parts^en とも称される。 ◎ The token set of this particular DOMTokenList object are also known as the element’s parts.

これを~DOM仕様における `superglobal^en 【すべての名前空間より上位の大域~属性】として定義する。 [`3424$issue] ◎ Define this as a superglobal in the DOM spec. [w3c/csswg-drafts Issue #3424]

5.6. 構文解析~用の小構文