1. 序論
~shadow~DOMは、 ~pageをいくつかの “~component” — ~markupが成す下位treeであって、 その詳細は，外側~pageでなく自身に限り関連するもの — に分離することを作者に許容する。 これは、［ ~pageを成す ある~part用に意味された ある~style ］が［ 不用意に適用され過ぎることにより， ~pageを成す他の~partの見かけがおかしくなる機会c ］を抑制する。 しかしながら、 この~style付け防壁により， ~pageが~componentとヤリトリすることも難しくなる — 実際にそうするよう`求まれた^emときに。 ◎ Shadow DOM allows authors to separate their page into "components", subtrees of markup whose details are only relevant to the component itself, not the outside page. This reduces the chance of a style meant for one part of the page accidentally over-applying and making a different part of the page look wrong. However, this styling barrier also makes it harder for a page to interact with its components when it actually wants to do so.
この仕様は、 `part()$pe 疑似要素を定義する。 それは、 作者が［ `~shadow~tree$内にある，ある目的で公開された特定の要素 ］を［ 外側~pageの文脈から~styleする ］ことを許容する。 これらの疑似要素は、 `~custom~prop$ （それは、 外側~pageが，自身の意のままに特定0の値（~theme色など）を~componentに渡せるようにする） と組合せることにより — ~capsule化を保守しつつ，すべての制御をあきらめることなく — ~componentと外側~pageが安全かつ強力な仕方でヤリトリすることを許容する。 ◎ This specification defines the ::part() pseudo-element, which allows an author to style specific, purposely exposed elements in a shadow tree from the outside page’s context. In combination with custom properties, which let the outside page pass particular values (such as theme colors) into the component for it to do with as it will, these pseudo-elements allow components and the outside page to interact in safe, powerful ways, maintaining encapsulation without surrendering all control.
［ `host$ps, その`関数-形＠~SELECTORS4#functional-pseudo-classes$ `host()$ps ］疑似類は、 `~shadow~tree$の`~shadow~host$に合致する。 ◎ The :host pseudo-class and its functional counterpart :host() match the shadow tree’s shadow host.
［ `slotted()$pe `疑似要素$, それに関係する `has-slotted$ps `疑似類$ ］は、［ `~slot$, それがアテガわれた`~shadow~tree$ ］とヤリトリする仕方を供する。 ◎ Furthermore, the ::slotted pseudo-element and the related :has-slotted pseudo-class provide ways to interact with slots and their assigned shadow tree.
注記： この仕様は， 元々は `CSS Scoping Module Level 1^en と称されていたが、［ `CSS Shadow Parts Module Level 1^en と併合され， ~shadow~DOM特能を包括的に受持つようになった ］ことを もっと反映するため， `CSS Shadow Module Level 1^en に改称された。 初期~時は この~moduleにおいて述べられた特能 `視野~付き~style規則＠~CASCADE6#scoped-style-rules$は、 `css-cascade-6$r へ移動された。 ◎ Note: This specification was originally titled CSS Scoping Module Level 1. It has since been merged with CSS Shadow Parts Module Level 1 and renamed to CSS Shadow Module Level 1 to better reflect its comprehensive coverage of Shadow DOM features. The scoped style rules feature initially described in this module has been moved to [css-cascade-6].
2. ~custom要素に対する既定の~style
この節は、 試験的であり，論の最中にある。 実装する前に，~CSS~WGに諮ること。 ◎ This section is experimental, and is under active discussion. Do not implement without consulting the CSSWG.
`~custom要素$を定義するときは、 それ用に［ 組込みの要素に適用される~UA~styleと同類な， “既定の~style” ］を設定しておくよう求まれることが多い。 あいにく，~~従来の~CSSでこれを行うことは、 次に挙げることから難しい： ◎ When defining custom elements, one often wants to set up "default" styles for them, akin to the user-agent styles that apply to built-in elements. This is, unfortunately, hard to do in vanilla CSS, due to issues of scoping and specificity—＼
-
視野~法の課題： 当の要素は，`~shadow~tree$内で利用されるかもしれない — その場合、 `文書~tree$†内にある，要素を~targetしている選択子 ］からは到達-不能になる。
【† 原文には， “最も外縁な文書（ `outermost document^en ）” と記されているが、 実際には，`文書~tree$を指す （~stylesheetは、複数の文書に適用し得ない）。 この仕様に現れる語 “文書” は， 実際には`~node~tree$ — ［ `文書~tree$, `~shadow~tree$ ］の総称 — を意味する箇所が多いので、 この訳では，そのように改める。 】
◎ the element in question might be used in shadow trees, and thus is unreachable by any selector targeting it in the outermost document;＼ - 詳細度の課題： `型~選択子$の様な`詳細度$が低い選択子でも、［ 当の要素を~targetするよう意味された，作者~levelの~style ］を不用意に上書きし得る。 ◎ and selectors, even low-specificity ones like simple type selectors, can accidentally override author-level styles meant to target the element.
これを援助するため、 この節では，［ 所与の要素に “既定の要素~style” を与える~stylesheet ］の作成-法を定義する。 この種の~stylesheetは、［ 文書~全体, および すべての`~shadow~tree$内 ］にわたって適用され、 その中の各~規則は — 作者~levelの規則が自動的に優先されるよう — `~UA出自$の下で適用される。 ◎ To aid in this, this section defines a way to create a stylesheet of "default element styles" for a given element. This stylesheet applies across the entire document, in all shadow trees, and the rules in it apply at the user agent origin, so author-level rules automatically win.
各 `Window$I は、 `defaultElementStylesMap@sl 内部~slotを有する — それは、 要素の`局所~名$を`~stylesheet$に対応付ける。 それらの~stylesheetは： ◎ Windows gain a private slot [[defaultElementStylesMap]] which is a map of local names to stylesheets.
-
当の~windowに`結付けられた文書$を成す どの`~node~tree$【！every document in the window】にも適用するモノトスル。 加えて，~UA~stylesheetとして解釈するモノトスル。 ◎ These stylesheets must apply to every document in the window. They must be interpreted as user agent stylesheets.
注記： このことは、 当の~stylesheetは`~shadow~tree$【！all shadow trees in every document】にも適用され，その中の宣言は`~UA出自$になることを含意する。 ◎ Note: This implies, in particular, that they apply to all shadow trees in every document, and that the declarations in them are from the user agent origin.
- `~cascade$の目的においては、 ~UAの自前の~stylesheetより後の順になる。 この種の~stylesheetどうしの順序は、 観測され得ないので，問われない。 ◎ For the purpose of the cascade, these stylesheets are ordered after the user agent’s own stylesheets; their relative ordering doesn’t matter as it is not observable.
- その中の`複階-選択子$は、 無効になるモノトスル。 ◎ Within these stylesheets, complex selectors must be treated as invalid.＼
- その中の`複合-選択子$は、［ 次に該当する要素を選択する，`型~選択子$ ］が追加されたものとして扱うモノトスル。 ⇒ その`局所~名$は、 `defaultElementStylesMap$sl 内で当の~stylesheetに対応付けられる ◎ Every compound selector must be treated as containing an additional type selector that selects elements with the local name that the stylesheet is keyed with.
この種の~stylesheetに利用-可能な`~at-規則$を制約する必要はあるか？ 例えば、 `font-face$at は許容されるか？ 編集者は、 とりあえず，何か不都合を［ 聞くまで／聞かない限り ］は、 許容したままにしておくことにする。 ◎ Do we need to restrict the at-rules that can be used in these sheets? For example, do we allow an @font-face? I’m going to leave it as allowed unless/until I hear complaints.
この仕様は、 `defaultElementStylesMap$sl を一般に操作する方法 — 追加する, 除去する, その他 — は，定義しない。 そうするための仕方は、 `DOM$r などの他の仕様が定義するものと期待される。 【今や、`有順序~map＠~INFRA#ordered-map$ `INFRA$r 用の演算として定義されるであろう。】 ◎ This specification does not define how to add to, remove from, or generally manipulate the [[defaultElementStylesMap]]. It is expected that other specifications, such as [DOM], will define ways to do so.
3. ~shadowの~capsule化
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 要素†の~cascade ］を作者が予測-不能になることはない。 【†~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と選択子
3.2.1. ~shadow~treeに対する選択子の照合-法
選択子が`~shadow~tree$に対し照合されるときの `selector match list^en† は、 初期~時には，［ 先頭の`~shadow~host$ ］および［ ~tree順序による【！ordered by a pre-order traversal】，`~shadow~tree$の`~shadow根$の子孫~すべて ］からなるとする。 ◎ When a selector is matched against a shadow tree, the selector match list is initially the shadow host, followed by all children of the shadow tree’s shadow root and their descendants, ordered by a pre-order traversal.
† これを【更新された `SELECTORS4$r 仕様の】より新たな形の照合~algoへの~callに見合うよう書直す。 ◎ Rewrite this against the newer call forms of the matching algorithms.
注記： `~shadow~tree$は、 要素の子孫には含まれない — 要素の子孫は、［ `~light~tree$における，要素の`子$ ］に基づく。 ◎ Note: Remember that the descendants of an element are based on the light tree children of the element, which does not include the shadow trees of the element.
`~treeに対し選択子を照合-$するときの `~tree文脈@ は、［ その~algoに渡される %根~要素 ］の`根$で与えられる。 `~tree文脈$が`~shadow根$であるとき、 選択子は `~shadow~treeの文脈~下@ で照合されてるという。 ◎ When a selector is matched against a tree, its tree context is the root of the root elements passed to the algorithm. If the tree context is a shadow root, that selector is being matched in the context of a shadow tree.
例えば，ある~stylesheetが`~shadow~tree$内の［ 要素~内に埋込まれている／要素から~linkされている ］とき、 その~stylesheet内のどの選択子も，`~shadow~treeの文脈~下$にある。 `~shadow根$に対し~callされる `querySelector()＠~DOM4#dom-parentnode-queryselector$c に渡す選択子~引数も同様になる。 ◎ For example, any selector in a stylesheet embedded in or linked from an element in a shadow tree is in the context of a shadow tree. So is the argument to querySelector() when called from a shadow root.
宣言~block内の各~宣言は、 それを適用するために照合した選択子の`~tree文脈$を継承する。 ◎ Declarations inherit the tree context of the selector that was matched to apply them.
3.2.2. ~shadow~treeの中から~shadow~hostを選択するとき
`~shadow~host$ %~host は、［ それが~hostする`~shadow~tree$ %~shadow~tree の外側にある ］ので，普通は［ `~shadow~treeの文脈~下$で評価される選択子からは~target不能 ］になる（選択子の~targetは，単独の~treeに制限される）が、 ときには， %~shadow~tree の文脈の内側からも %~host を~style可能になれば有用になることもある。 ◎ A shadow host is outside of the shadow tree it hosts, and so would ordinarily be untargettable by any selectors evaluated in the context of the shadow tree (as selectors are limited to a single tree), but it is sometimes useful to be able to style it from inside the shadow tree context.
- 選択子の目的においては、 %~host は %~shadow~tree にも — %~shadow~tree の内容が %~host の子として扱われるように — 現れる （言い換えれば、 %~host は［ %~shadow~tree の`根$である`~shadow根$ ］を置換するものとして扱われる）。 ◎ For the purpose of Selectors, a shadow host also appears in its shadow tree, with the contents of the shadow tree treated as its children. (In other words, the shadow host is treated as replacing the shadow root node.)
- %~host は、 %~shadow~tree の中では`無特能$であると見なされ， それに合致し得る選択子は［ `host$ps ／ `host()$ps ／ `host-context()$ps ］疑似類に限られる。 ◎ When considered within its own shadow trees, the shadow host is featureless. Only the :host, :host(), and :host-context() pseudo-classes are allowed to match it.
注記： なぜ~shadow~hostは`無特能$にされているのか ？ ◎ Why is the shadow host so weird?
%~shadow~tree の外側に居る %~host の~markupは、 【~shadow~treeを内容とする】部品の作者ではなく，~page作者の制御~下にある。 ◎ The shadow host lives outside the shadow tree, and its markup is in control of the page author, not the component author.
この部品が、 %~shadow~tree 内の~stylesheet内で，特定0の~class名を内部的に利用しているとする。 そのような部品を利用している~page作者が，同じ~class名を偶発的に %~host に利用した場合、 良くないことが起こる。 そのような状況の結果， 【その~class名を選択する選択子を通して，~hostに】 偶発的にあてられる~styleは、 部品~作者には予測-不可能であり，~page作者も~debugに戸惑うことになる。 ◎ It would not be very good if a component used a particular class name internally in a shadow tree stylesheet, and the page author using the component accidentally also used the same class name and put it on the shadow host. Such a situation would result in accidental styling that is impossible for the component author to predict, and confusing for the page author to debug.
しかしながら、［ %~shadow~tree 内の~stylesheetが %~host を~styleする ］ことが適理になる利用事例は，依然としてある （例えば，当の部品は~flexboxとして~lay-outするよう求まれている場合、 %~host の `display$p を設定することが要求される）。 なので、 この状況を許容しつつ，偶発的に~styleされないようにするため、 %~host は，［ %~shadow~tree には現れる ］が［ 完全に`無特能$ ］かつ［ 選択するためには、 ~page作者が供した~markupに対し，部品~作者が明示的に［ `host^ps ／ `host()^ps ／ `host-context()^ps ］を通して照合する他にない ］ようにしてある。 ◎ However, there are still some reasonable use-cases for letting a stylesheet in a shadow tree style its shadow host. (For example, the component might want to be laid out as a flexbox, requiring the shadow host to be set to display: flex.) So, to allow this situation but prevent accidental styling, the shadow host appears but is completely featureless and unselectable except through :host and its related functional forms, which make it very explicit when you’re trying to match against markup provided by the page author.
3.2.3. ~light~treeの中への選択-法： `host^ps, `host()^ps, `host-context()^ps 疑似類
`host@ps 疑似類は、 `~shadow~treeの文脈~下$では，［ 当の`~shadow~tree$を~hostしている`~shadow~host$ ］に合致するように評価される。 他の文脈~下では，何にも合致しない。 ◎ The :host pseudo-class, when evaluated in the context of a shadow tree, matches the shadow tree’s shadow host. In any other context, it matches nothing.
関数形の疑似類 `host()@ps の構文は、 次で与えられる： ◎ The :host() function pseudo-class has the syntax:
:host( `compound-selector$t )
それは、 `~shadow~treeの文脈~下$では，［ 当の`~shadow~tree$を~hostしている`~shadow~host$ ］であって［ 通常の文脈~下で，引数の選択子（`複合-選択子$）にも合致するもの ］に合致するように評価される。 他の文脈~下では，何にも合致しない。 ◎ When evaluated in the context of a shadow tree, it matches the shadow tree’s shadow host if the shadow host, in its normal context, matches the selector argument. In any other context, it matches nothing.
`host$ps の`詳細度$は、 疑似類のそれとする。 `host()$ps の`詳細度^は、 疑似類のそれに引数の`詳細度^を足したものになる。 ◎ The specificity of :host is that of a pseudo-class. The specificity of :host() is that of a pseudo-class, plus the specificity of its argument.
注記： これは、 `is()$ps や `not()$ps の様な［ 類似するが，引数の詳細度しかとらない疑似類 ］の詳細度とは異なる。 そのわけは、 `host$ps が， “通常の” 疑似類の様に~~独力で【すなわち，引数なしでも】要素を選択するからである — それは構文上の理由から引数に選択子をとるが（ `:host.foo^css に合致するなら `.foo^css にも合致させる必要がある）、 他の点では，単に ある選択子が後続している `host^ps を利用することに一致する。 【 `:host.foo^css は `:host^css と `.foo^css の論理積を表すが、 `.foo^css 単体では~shadow~treeの外にあるものに合致し得ない。】 ◎ Note: This is different from the specificity of similar pseudo-classes, like :is() or :not(), which only take the specificity of their argument. This is because :host is affirmatively selecting an element all by itself, like a "normal" pseudo-class; it takes a selector argument for syntactic reasons (we can’t say that :host.foo matches but .foo doesn’t), but is otherwise identical to just using :host followed by a selector.
例えば、 次の様な`~shadow~tree$を伴う部品があるとするとき： ◎ For example, say you had a component with a shadow tree like the following:
<x-foo class="foo">
<“~shadow~tree”>
<div class="foo">...</div>
</“~shadow~tree”>
</x-foo>
`~shadow~tree$の中の~stylesheetにおいては： ◎ For a stylesheet within the shadow tree:
- `host$ps は、 `x-foo^e 要素に合致する。 ◎ :host matches the <x-foo> element.
- `x-foo^css は、 何にも合致しない。 ◎ x-foo matches nothing.
- `.foo^css は `div^e 要素のみに合致する。 ◎ .foo matches only the <div> element.
- `.foo:host^css は、 何にも合致しない — `.foo^css は `x-foo^e 要素に合致しないので。 ◎ .foo:host matches nothing
- `:host(.foo)^css は、 `x-foo^e 要素に合致する — 引数の `.foo^css も合致するので。 ◎ :host(.foo) matches the <x-foo> element.
`~shadow~tree$の中の選択子からは、 普通は，`~shadow~tree$の外側にある要素は まったく見えない。 しかしながら、 ときには， ~shadow~treeの外側にあるどこか — 同じ文書~内の, より上位にある先祖 — を選択できると有用になることもある。 ◎ Ordinary, selectors within a shadow tree can’t see elements outside the shadow tree at all. Sometimes, however, it’s useful to select an ancestor that lies somewhere outside the shadow tree, above it in the document.
例えば，一群の部品からなる~groupは、［ 各自がどう応答するかを知る，一握りの色~theme ］を定義することもある — ~page作者が、［ それらの部品または, 文書~内のより上位 ］に特定の~classを追加して，特定0の~themeを任意選択で選べるような。 ◎ For example, a group of components can define a handful of color themes they know how to respond to. Page authors could opt into a particular theme by adding a specific class to the components, or higher up in the document.
【 すなわち、 部品を内容に含ませている先祖にあてがわれた~classに応じて、 利用する色~theme （部品どうしや, その内部の構成子たちの色合いが調和するように設計された，色の集合） を切り替える。 】
関数形の疑似類 `host-context()@ps は、 `~shadow~tree$の外側に［ 特定0の選択子に合致する先祖 ］は在るかどうかを~testする。 その構文は、 次で与えられる： ◎ The :host-context() functional pseudo-class tests whether there is an ancestor, outside the shadow tree, which matches a particular selector. Its syntax is:
:host-context( `compound-selector$t )
`host-context()$ps 疑似類は、 `~shadow~treeの文脈~下$では，［ 当の~shadow~treeを~hostしている`~shadow~host$, または その`~shadowも含めた先祖$ ］のうち［ 通常の文脈~下で引数の選択子（`複合-選択子$）に合致する ］ものに合致するように評価される。 他の文脈~下では，何にも合致しない。 ◎ When evaluated in the context of a shadow tree, the :host-context() pseudo-class matches the shadow host, if the shadow host or one of its shadow-including ancestors matches the provided <compound-selector>. In any other context, it matches nothing.
`host-context()$ps の`詳細度$は、 疑似類のそれに引数の`詳細度^を足したものになる。 ◎ The specificity of :host-context() is that of a pseudo-class, plus the specificity of its argument.
注記： このことは、 当の選択子は，［ 文書の根に到達するか, 引数に合致する要素が見つかる ］まで［ ~shadow境界を貫くように遡る ］ことを意味する。 ◎ Note: This means that the selector pierces through shadow boundaries on the way up, looking for elements that match its argument, until it reaches the document root.
3.2.4. ~slotにアテガわれた内容の選択-法： `slotted()^pe 疑似要素
`slotted()@pe 疑似要素は、［ `平坦~化され$た結果，`~slot$にアテガわれた要素たち ］を表現する。 この疑似要素は： ◎ The ::slotted() pseudo-element represents the elements assigned, after flattening, to a slot.＼
- `~slot$上にのみ存在する。 【すなわち、当の~slotが，この疑似要素の`出自の要素$になる。】 ◎ This pseudo-element only exists on slots.
- 当の~tree内の他の要素を指す`別名^emであり、 それ自体は~boxを生成しない。 【すなわち，`要素が裏にある疑似要素$である。】 ◎ The ::slotted() pseudo-element is an alias for other elements in the tree, and does not generate any boxes itself.
-
その文法は、 次で与えられる： ◎ The grammar of the ::slotted() pseudo-element is:
::slotted( `compound-selector$t )
-
~AND↓ を満たす要素を表現する： ◎ The ::slotted() pseudo-element represents the elements that are:
- `平坦~化され$た結果として，［ `slotted()^pe の`出自の要素$である`~slot$ ］にアテガわれている。 ◎ assigned, after flattening, to the slot that is ::slotted’s originating element
- `要素に対し選択子を照合-$したとき， 引数の `compound-selector$t （`複合-選択子$）に合致する。 ◎ matched by its <compound-selector> argument
- `slotted()^pe`before^pe の様に， `~treeに留まる疑似要素＠~CSSPSEUDO#tree-abiding$を後続させれる — それは、 `slotted()$pe 疑似要素により表現される要素を`出自の要素$とする適切な疑似要素を表現する。 ◎ The ::slotted() pseudo-element can be followed by a tree-abiding pseudo-element, like ::slotted()::before, representing the appropriate pseudo-element of the elements represented by the ::slotted() pseudo-element.
`slotted()$pe の`詳細度$は、 疑似要素のそれに引数の`詳細度^を足したものになる。 ◎ The specificity of ::slotted() is that of a pseudo-element, plus the specificity of its argument.
例えば、 次の様な［ 子たち, および~shadow~tree ］を伴う部品があるとする： ◎ For example, say you had a component with both children and a shadow tree, like the following:
<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>
`~shadow~tree$の中の~stylesheetにおいては、 選択子 `::slotted(*)^css は，［ `#one^css, `#two^css ］のみを選択する — それらは、 もっぱら `slot$e 要素に`アテガわれる要素＠~DOM4#find-flattened-slotables$なので。 それは、 `slot$a 属性を有さない `#three^css は選択しない。 また、 `#four^css も選択しない （`~slot$にアテガわれる~nodeは、 `~shadow~host$の（直な）`子$に限られるので）。 ◎ For a stylesheet within the shadow tree, a selector like ::slotted(*) selects #one and #two only, as they’re the elements assigned to the sole slot element. It will not select #three (no slot attribute) nor #four (only direct children of a shadow host can be assigned to a slot).
一方で， `::slotted(.foo)^css の様な選択子は、［ `#one^css, `#two^css ］のうち `.foo^css に合致する前者のみを選択する。 ◎ A selector like ::slotted(.foo), on the other hand, will only select #one, as it matches .foo, but #two doesn’t.
注記： `::slotted(*)^css の様な選択子は、 `*::slotted(*)^css と等価になる — 先頭の `*^css は、 `slot$e 要素の他にも多数の要素を選択するが、 `~slot$になるのは `slot$e 要素に限られるので，合致するのは `slotted()$pe 疑似要素に合致する要素に限られる。 ◎ Note: Note that a selector like ::slotted(*) is equivalent to *::slotted(*), where the * selects many more elements than just the slot element. However, since only the slot elements are slots, they’re the only elements with a ::slotted() pseudo-element as well.
注記： `~slot$には~text~nodeもアテガえるが、 それらは `slotted()$pe では表現されないので，選択できない。 そのような~text~nodeを~styleする仕方は、 `~slot$を~styleした上で，継承に依拠する他にない。 ◎ Note: ::slotted() can only represent the elements assigned to the slot. Slots can also be assigned text nodes, which can’t be selected by ::slotted(). The only way to style assigned text nodes is by styling the slot and relying on inheritance.
3.2.5. ~slotにアテガわれた~nodeの有無に対する照合-法： `has-slotted^ps 疑似類
`has-slotted@ps 疑似類は、 次を満たす `slot$e 要素に合致する ⇒ 次の結果は空でない ⇒ `~slot用に平坦~化された~slot可能なものを見出す$( 当の要素 ) ◎ The :has-slotted pseudo-class matches slot elements which have a non-empty list of flattened slotted nodes.
ある［ ~fallback内容†を伴う`~slot$ ］が `has-slotted$ps に合致したならば、［ 当の~fallback内容は表示されて`いない^em ］ものと結論できる。 ◎ When :has-slotted matches a slot with fallback content, we can conclude that the fallback content is not being displayed.
【† すなわち、 上の “結果” が空になるとき，当の~slotにアテガわれる内容 （当の `slot^e 要素の内容）。 】
注記： 【上の “結果” が】空白のみからなる 1 個の~text~nodeであっても， `has-slotted$ps を適用させるものとして足る。 そのように設計されたのは、 この疑似類の挙動を `assignedNodes()＠~HEscripting#dom-slot-assignednodes$c ~methodの挙動と一貫させるためである。 この仕様の将来~versionは、 この事例で合致することを除外する仕方を導入するものと期待される。 ◎ Note: Even a single whitespace text node is sufficient to make :has-slotted' apply. This is by design, so that the behavior of this pseudo-class is consistent with the behavior of the assignedNodes() method. A future version of this specification is expected to introduce a way to exclude this case from matching.
注記： この仕様の将来~versionは、 関数形の `has-slotted()^ps 疑似類を導入することが期待される — それは、 選択子~引数を受容することにより，もっと木目細かな照合を許容する。 `has-slotted$ps は、 `:has-slotted(*)^css の別名には`ならない^em — 前者は［ 上の “結果” が~text~nodeのみであっても合致する ］が、 後者はそうでない。 ◎ Note: It is expected that a future version of this specification will introduce a functional :has-slotted() pseudo-class that allows more fine-grained matching by accepting a selector argument. :has-slotted is not an alias of :has-slotted(*), as the latter would not match slotted text nodes, but :has-slotted does.
4. ~shadow~treeと~cascade
`~cascade文脈$【！§ ~CASCADE#cascade-sort】 `CSS-CASCADE-4$r を見よ。 ◎ See CSS Cascading 4 § 6.1 Cascade Sorting Order.
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:
- %根 ~LET 文書の`根~要素$ ◎ ↓
- %処理待ち~node~list ~LET 新たな`~list$ — この~listは、 ( `~node^i, `親^i ) が成す~tupleとして与えられる~itemたちで拡充されることになる。 ◎ Let pending nodes be a list of DOM nodes with associated parents,＼
- %処理待ち~node~list に ( %根, ε ) を`付加する$ ◎ initially containing just the document’s root element with no associated parent.
- %平坦~tree ~LET %根 を根とする， %根 のみからなる新たな`平坦~tree$ ◎ ↓
-
~WHILE［ %処理待ち~node~list は`空$でない ］： ◎ Repeatedly execute the following substeps until pending nodes is empty:
- %~item ~LET %処理待ち~node~list[ 0 ] ◎ ↓
- %処理待ち~node~list から %~item を`除去する$ ◎ Pop the first element from pending nodes, and assign it to pending node.
- %~node ~LET %~item の `~node^i ◎ ↓
- ~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.)
-
~IF［ %~node は`~shadow~host$である ］： ◎ Perform one of the following, whichever is the first that matches: ◎ pending node is a shadow host
- %~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.
- ~CONTINUE
-
~IF［ %~node は`~slot$である ］：
- %~slot可能~list ~LET `~slot用に~slot可能なものを見出す$( %~node )
-
~IF［ %~slot可能~list は`空$でない ］：
- %~slot可能~list を成す ~EACH( %~slot可能 ) に対し ⇒ %処理待ち~node~list に ( %~slot可能, %~node ) を`付加する$
- ~CONTINUE
- %~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.
注記： 言い換えれば、 `平坦~tree$は，~top-levelの~DOM~treeであるが：
- 各`~shadow~host$は、［ その`~light~tree$内の子たち ］に代わって，［ `~shadow~tree$内の子たち ］で埋められる （更に，［ 当の`~shadow~tree$も`~shadow~host$を包含する ］ならば、 これを再帰的に続行する）。
- 各`~slot$は、［ それにアテガわれた~nodeたち ］で埋められる （更に，当の`~slot$も［ より深い`~shadow~tree$内の`~slot$ ］にアテガわれるなら、 これを再帰的に続行する）。
これによる明白でない結果は、 ~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.1.1. ~shadow~tree内の~slotとそれにアテガわれる要素
`~slot$は、［ `~UA出自$内の規則を介して，その `display$p には `contents$v がアテガわれていた ］かのように動作するモノトスル。 これは、 `display$p を介して上書きできるモノトスル — 欲されるときには、 `~slot$が`~boxを生成できる^emよう。 ◎ Slots must act as if they were assigned display: contents via a rule in the UA origin. This must be possible to override via display, so they do generate boxes if desired.
【 `HTML$r においては、 これは，~UA~stylesheetの `slot{ display: contents }^css 規則として`実装される＠~HTMLrendering#flow-content-3$。 】
注記： `~slot$に要素をアテガうことによる明白でない結果は、 要素は，その`~slot$から【~styleを】継承することである。 ［ `~light~tree$における要素の元の親 ］／［ その`~slot$もまた 他の`~slot$にアテガわれたとするときの，他の`~slot$ ］は、 継承には影響しない。 ◎ Note: A non-obvious result of assigning elements to slots is that they inherit from the slot they’re assigned to. Their original light tree parent, and any deeper slots that their slot gets assigned to, don’t affect inheritance.
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が結付けられている場合にも合致する†。 ◎ 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.
【† すなわち，`大域的$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.)
［ 大域的な名前を定義する すべての~at-規則／ それらを参照する すべての~prop ］は、 これらの概念を利用するよう修正する必要がある： ◎ TODO: Fix all the at-rules that define global names, and the properties that reference them, to use these concepts.
次に挙げるものは、 `大域的$tsNな名前になる： ◎ Global names include:
- `font-family$p から参照される `font-face$at ◎ @font-face, referenced by font-family
- `font-family$p から参照される `font-feature-values$at ◎ @font-feature-values, referenced by font-family
- `animation-name$p から参照される `keyframes$at ◎ @keyframes, referenced by animation-name
- `list-style-type$p から参照される `counter-style$at ◎ @counter-style, referenced by list-style-type
- `color$f 関数 から参照される `color-profile$at ◎ @color-profile, referenced by the color() function
- `font-palette$p から参照される `font-palette-values$at ◎ @font-palette-values, referenced by font-palette
- その他には？ ◎ others?
例えば，次の文書において （仮想の~markup［ `<::shadow>^c … `</::shadow>^c ］は、 要素の`~shadow~tree$を指示する）： ◎ For example, given the following document (using the imaginary <::shadow></::shadow> markup to indicate an element’s shadow tree):
<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>
`.outer^css 要素は、 外縁な `font-face$at を参照するので， "`outer.woff^v" ~font資源【！~file】を利用する。 ◎ The .outer element references the outer @font-face, using the "outer.woff" file.
`.inner-default^css 要素は、 `.outer^css と同じ`~tree視野な参照$を利用しているので， `font-family$p の値 `foo^v を`~light~tree$【！the outer document】から継承する。 したがって、 それも "`outer.woff^v" ~font資源【！~file】を利用する。 ◎ The .inner-default element inherits the font-family: foo value from the outer document, using the same tree-scoped reference as .outer, and thus also uses the "outer.woff" font file.
他方， `.inner-style^css 要素は、 ~shadowの内側にある~stylesheetから `font-family$p の値 `foo^v を受取る — その`~tree視野な参照$は~shadowの `font-family^at を参照rするので， "`inner.woff^v" ~font資源【！~file】を利用する。 ◎ The .inner-style element, on the other hand, receives a font-family: foo from the stylesheet inside the shadow, and thus its tree-scoped reference refers to the shadow’s @font-family, and it uses the "inner.woff" file.
`.part-styled^css 要素も，自身の~styleを`~light~tree$【！the outer document】から受取るが、 継承によらずに，直に設定されている。 したがって、 その`~tree視野な参照$も~light~tree【！the outer document】を参照rするので， "`outer.woff^v" ~font資源【！~file】を利用する。 ◎ The .part-styled element also receives its style from the outer document, tho by being directly set rather than by inheritance. Thus, its tree-scoped reference also refer’s to the outer document, and it uses the "outer.woff" file.
［ `~tree視野な名前$, `~tree視野な参照$ ］がどう継承されるかを精確に~~説明するため、 3 ~levelの~treeからなる，もっと複階的な例を次に示す： ◎ Here is a more complex example, showing three levels of trees, and illustrating precisely how tree-scoped names and tree-scoped references inherit.
<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>
ここでの `.inner-default^css は、 前の例と同じく，`~light~tree$【！the outer document】内に宣言された `font-family$p を継承している — その結果［ ~light~tree【！the outer document】の `font-face$at を参照する ］ようになるので， "`outer.woff^v" ~font資源【！~file】で描画される。 ◎ Here, just as in the previous example, .inner-default is inheriting the font-family: foo declared in the outer document, and so it ends up referencing the outer document’s @font-face, and is rendered with the "outer.woff" file.
他方， `.inner-search^css は、［ 自身の~styleを `grandchild-component^e の~shadow~tree内の~stylesheetから受取る ］ので，［ その~tree内の `foo^v ~fontを定義している `font-face$at ］を見出そうと試みる。 そのような `font-face^at は無いので、［ ~shadow~treeを遡って， `child-component^e 内に適切な `font-face^at を見出す ］ことになり， "`inner.woff^v" ~font資源【！~file】で描画される。 ◎ On the other hand, .inner-search receives its style from a stylesheet in <grandchild-component>’s shadow tree, so it attempts to find a @font-face defining a foo font in that tree. There is no such @font-face, so it starts walking up the shadow trees, finding an appropriate @font-face in <child-component>, so it’s rendered with the "inner.woff" file.
4.2.1. ~tree視野な参照が直列化されるとき
`~tree視野な参照$が直列化される場合、 その値しか直列化されず，結付けられた`根$は失われる。 ◎ If a tree-scoped reference is serialized, it serializes only its value; the associated root is lost.
このことは、
%要素.style.foo = getComputedStyle(%要素).foo;
は
— `~shadow~tree$が存在しなければ、
概して何もしないのと違って —
何もしないとは限らないことを含意する。
◎
This implies that `el.style.foo = getComputedStyle(el).foo;` is not necessarily a no-op, like it typically was before shadow trees existed.
例えば，次の文書において （仮想の~markup［ `<::shadow>^c … `</::shadow>^c ］は、 要素の`~shadow~tree$を指示する）： ◎ For example, given the following document (using the imaginary <::shadow></::shadow> markup to indicate an element’s shadow tree):
<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>
`.outer^css 要素は、 `~light~tree$【！the outer document】の "`foo^v" `font-face$at で~styleされる。 `.inner-default^css 要素 %innerDefault は、 ~light~tree【！the outer document】から `font-family$p を継承するので， ~light~tree【！the outer document】を参照している`~tree視野な参照$も継承する — その結果， `.outer^css 要素と同じ~fontが利用される。 ◎ The .outer element is styled with the outer document’s "foo" @font-face. The .inner-default element inherits font-family from the outer document, meaning it inherits a tree-scoped reference referencing that outer document, and so it’s in the same font as .outer.
その一方， `.inner-styled^css 要素 %innerStyled は、 当の~shadow根の内側から明示的に~styleされるので、 それを根とする~shadow~treeを参照している`~tree視野な参照$を新規に受取る — その結果、 この~shadowの自前の "`foo^v" `font-face$at で~styleされる。 ◎ Meanwhile, .inner-styled is explicitly styled from inside the shadow root, so it receives a fresh tree-scoped reference referencing its shadow tree, and it is instead styled the shadow’s own "foo" @font-face.
にも関わらず，`my-component^e の内側で走っている~scriptからは、
%innerDefault, %innerStyled
の `font-family$p 用の値は同じに見える
— `~tree視野な参照$の［
`根$への参照
］を成す部分は、
直列化により保全されないので。
~~仮に，
%innerDefault.style.fontFamily = %defaultFont;
のように設定した場合、
%innerDefault 用の~fontは，いきなり
%innerStyled 用の~fontに切替わる
— ［
~shadow~tree内に住まう，
%innerDefault の`~CSS~style属性$の~stylesheet
］内で `font-family$p ~propが設定されるので。
◎
Despite that, the script running inside the component sees the two elements as having the same value for font-family, because the root-reference part of a tree-scoped reference is not preserved by serialization. If it were to set innerDefault.style.fontFamily = defaultFont; (thus setting the font-family property of the element’s attribute stylesheet, which lives in the shadow tree), the .inner-default element would suddenly switch to the same font as .inner-styled!
注記： `css-typed-om-1$r は、［ 値を`具象化-$する規則において，`~tree視野な参照$の［ `根$への参照 ］も反映する ］ことにより，次を作者に許容するものと期待される ⇒＃ 当の参照は，どの`~node~tree$から その値を得るかについて、伝えること／ 2 つの`~node~tree$間で，値の意味が変化しないように値を~transportすること ◎ Note: The [css-typed-om-1] is expected to reflect the root reference of a tree-scoped reference in its reification rules for values, allowing authors to tell what node tree the reference is taking its values from, and allowing values to be transported across node trees without changing their meaning.
5. ~shadow要素の公開-法
`~shadow~tree$内の要素は、［ `part$a, `exportparts$a ］属性を利用して，~treeの外側へ — ~stylesheetによる~style付け用に — ~exportできる。 ◎ Elements in a shadow tree may be exported for styling by stylesheets outside the tree using the part and exportparts attributes.
各~要素は、 次に挙げるものを有する： ◎ ↓
- `~part名~list@ 【 `part$a 属性により拡充される】 ◎ Each element has a part name list＼
- ~tokenたちが成す`有順序~集合$ ◎ which is an ordered set of tokens.
- `回送される~part名~list@ 【 `exportparts$a 属性により拡充される】 ◎ Each element has a forwarded part name list＼
- ［ 2 個の`文字列$が成す`~tuple$ ］たちが成す`~list$ — 各~tupleは、 ( 【外縁へ】回送される内縁~partの名前, 公開される名前 ) を与える。 ◎ which is a list of tuples containing a string for the inner part being forwarded and a string giving the name it will be exposed as.
各`~shadow根$は、 `~part要素~map@ を有するものとみなせる — それは、 `文字列$を［ 要素【／疑似要素】たちが成す`有順序~集合$ ］へ対応付ける`~map$である。 ◎ Each shadow root can be thought of as having a part element map with keys that are strings and values that are ordered sets of elements.
`~part要素~map$は、 この仕様にて~styleを計算するための~algoの一部としてのみ述べられる — この~mapを計算することは、 高価にもなり得るので 【実装には，実際に必要になるまで計算しない裁量の余地がある】 。 それはまた、 ~DOMを介して公開されることはない — さもなければ、 閉な~shadow根の内側にある要素への~accessを許容するので。 ◎ The part element map is described only as part of the algorithm for calculating style in this spec. It is not exposed via the DOM, as calculating it may be expensive and exposing it could allow access to elements inside closed shadow roots.
`~part要素~map$は、 要素の追加や除去, および~DOM内の要素の［ `~part名~list$／`回送される~part名~list$ ］に対する変更により影響される。 ◎ Part element maps are affected by the addition and removal of elements and changes to the part name lists and forwarded part name lists of elements in the DOM.
`~part名~mapを計算する@ ~algoは、 所与の ( ~shadow根 %外縁~根 ) に対し： ◎ To calculate the part element map of a shadow root, outerRoot:
- %外縁~map ~LET %外縁~根 の`~part要素~map$ ◎ ↓
- %外縁~map を空にする 【この段は、この訳による補完。さもなければ、計算し直す度に~mapは肥大する一方になる。】
-
%外縁~根 の中の ~EACH( `子孫$ %子孫 ) に対し： ◎ For each descendant el within outerRoot:
- %子孫 の`~part名~list$を成す ~EACH( %名前 ) に対し ⇒ %外縁~map[ %名前 ] に %子孫 を`付加する$set ◎ For each name in el’s part name list, append el to outerRoot’s part element map[name].
- ~IF［ %子孫 は`~shadow~host$でない ］ ⇒ ~CONTINUE 【この ~CONTINUE は、この訳による補完。】 ◎ ↓
- %内縁~根 ~LET %子孫 の`~shadow根$el ◎ If el is a shadow host itself then let innerRoot be its shadow root.
- `~part名~mapを計算する$( %内縁~根 ) 【前回の計算と同じ結果になることが判っていれば、実装は，この段を省ける。】 ◎ Calculate innerRoot’s part element map.
- %内縁~map ~LET %内縁~根 の`~part要素~map$ ◎ ↓
-
%子孫 の`回送される~part名~list$を成す ~EACH( ( %内縁~名, %外縁~名 ) ) に対し： ◎ For each innerName/outerName in el’s forwarded part name list:
- ~IF［ %内縁~map[ %内縁~名 ] ~EQ ε ］~OR［ %内縁~map[ %内縁~名 ] は空である ］ ⇒ ~CONTINUE
-
~IF［ %外縁~map[ %外縁~名 ] ~EQ ε ］ ⇒ %外縁~map[ %外縁~名 ] ~SET 新たな`有順序~集合$
【 この段と前~段は、 この訳による補完。 】
-
%内縁~map[ %内縁~名 ] を成す ~EACH( %要素 ) に対し：
- ~IF［ %内縁~名 は疑似要素~名である ］ ⇒ %要素 ~SET %要素 を`出自の要素$とする, 名前 %内縁~名 を伴う疑似要素 【！%内縁~根 の疑似要素たち】
- %外縁~map[ %外縁~名 ] に %要素 を`付加する$set
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>
`exportparts$a 属性には、 `全部的に~style可能な疑似要素$の名前も利用できる — それにより、 この属性を利用した~component内にある当の疑似要素は， `part()$pe として装うようになる： ◎ For example, a fully styleable pseudo-element can be used in the exportparts attribute, to masquerade as a ::part() for the component it’s in:
<template id=custom-element-template>
<p exportparts="::before : preceding-text, ::after : following-text">
Main text.
</template>
この `template^e を利用している要素は、 `x-component::part(preceding-text)^css の様な選択子を利用して， その~shadow~tree内の `p::before^css 疑似要素を~targetにできる。 なので、 当の~componentの利用者は， `preceding-text^v として公開されたもの【！the preceding text】が疑似要素として実装されたかどうか知る必要はない。 ◎ An element using that template can use a selector like x-component::part(preceding-text) to target the p::before pseudo-element in its shadow, so users of the component don’t need to know that the preceding text is implemented as a pseudo-element.
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.
例えば，ある~custom~button（ `id="x-button"^a ）が［ ~style付け用に（ `part="label"^a を介して）公開される `label^l 要素 ］を【当の~buttonが~hostしている~shadow~tree内に】包含する場合、 作者は， `#x-button::part(label)^css でそれを選択できる。 ◎ For example, if you have a custom button that contains a "label" element that is exposed for styling (via part="label"), you can select it with x-button::part(label).
各~part名は、 ~classと同様に動作する ⇒＃ 複数個の要素が同じ~part名を有せる。 同じ要素が複数個の~part名を有せる。 ◎ Part names act similarly to classes: multiple elements can have the same part name, and a single element can have multiple part names.
~tabstrip~controlを成す要素たちに `part="tab"^a を伴わせれば、 そのすべては `::part(tab)^css により選択される。 ◎ A tabstrip control might have multiple elements with part="tab", all of which are selected by ::part(tab).
同時に “作動中（ `active^en ）” になる~UItabは 1 個だけならば、 特別に `part="tab active"^a で指示した上で， `::part(tab active)^css により選択できる （順序は問われないので、 `::part(active tab)^css でも選択できる）。 ◎ If a single tab is active at a time, it can be specially indicated with part="tab active" and then selected by ::part(tab active) (or ::part(active tab), as order doesn’t matter).
`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.
例えば `x-panel::part(confirm-button)::part(label)^css に合致するものは無い。 合致すると，構造上の情報を意図される以上に公開することになるので。 ◎ For example, x-panel::part(confirm-button)::part(label) never matches anything. This is because doing so would expose more structural information than is intended.
`x-panel^e の内部的な “`confirm^en” ~buttonが `part="label => confirm-label"^a 【`exportparts="label : confirm-label"^a ？】 の様な何かを利用して，~buttonの内部~partたちを `x-panel^e の自前の`~part要素~map$へ回送していた場合、 `x-panel::part(confirm-label)^css の様な選択子は、 他のどの~labelも無視して，ただ 1 つの~buttonの~labelを選択することになる。 ◎ If the <x-panel>’s internal confirm button had used something like part="label => confirm-label" to forward the button’s internal parts up into the panel’s own part element map, then a selector like x-panel::part(confirm-label) would select just the one button’s label, ignoring any other labels.
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. 構文解析~用の小構文
5.6.1. ~part対応付けを構文解析する規則
`妥当な~part対応付け@ は、 文字~並び［ 0 個以上の `0020^U `SPACE^cn, 1 個の文字 `003A^U `COLON^cn, 0 個以上の `0020^U `SPACE^cn ］で分離された 2 個の~tokenからなる【！↓tuple】。 各~tokenは、 文字［ `003A^U `COLON^cn ／ `002C^U `COMMA^cn ］を包含してはナラナイ。 【~tokenに対するそれ以上の制約は、特に言及されてはいない。】 ◎ A valid part mapping is a tuple of tokens separated by a U+003A COLON character and any number of space characters before or after the U+003A COLON The tokens must not contain U+003A COLON or U+002C COMMA characters.
`~part対応付けを構文解析する@ ~algoは、 所与の ( 文字列 %入力 ) に対し， 2 個の~tokenが成す`~tuple$を返す： ◎ The rules for parsing a part mapping are as follows: • Let input be the string being parsed.
- %位置 ~LET %入力 の先頭の文字を指している`位置~変数$ ◎ Let position be a pointer into input, initially pointing at the start of the string.
- %入力 内の %位置 から `0020^U `SPACE^cn からなる`符号位置~並びを収集する$ ◎ Collect a sequence of code points that are space characters
- %最初の~token ~LET %入力 内の %位置 から { `0020^U `SPACE^cn, `003A^U `COLON^cn } 以外の`符号位置~並びを収集する$ ◎ Collect a sequence of code points that are not space characters or U+003A COLON characters, and let first token be the result.
- ~IF［ %最初の~token ~EQ 空~文字列 ］ ⇒ ~RET `~error^i ◎ If first token is empty then return error.
- %入力 内の %位置 から `0020^U `SPACE^cn からなる`符号位置~並びを収集する$ ◎ Collect a sequence of code points that are space characters.
- ~IF［ %位置↗ ~EQ ε ］ ⇒ ~RET `~tuple$( %最初の~token, %最初の~token ) ◎ If the end of the input has been reached, return the tuple (first token, first token)
- ~IF［ %位置↗ ~NEQ `003A^U `COLON^cn ］ ⇒ ~RET `~error^i ◎ If character at position is not a U+003A COLON character, return error.
- %位置 ~INCBY 1 ◎ Consume the U+003A COLON character.
- %入力 内の %位置 から `0020^U `SPACE^cn からなる`符号位置~並びを収集する$ ◎ Collect a sequence of code points that are space characters.
- %最後の~token ~LET %入力 内の %位置 から { `0020^U `SPACE^cn, `003A^U `COLON^cn } 以外の`符号位置~並びを収集する$ ◎ Collect a sequence of code points that are not space characters or U+003A COLON characters. and let second token be the result.
- ~IF［ %最後の~token ~EQ 空~文字列 ］ ⇒ ~RET `~error^i ◎ If second token is empty then return error.
- %入力 内の %位置 から `0020^U `SPACE^cn からなる`符号位置~並びを収集する$ ◎ Collect a sequence of code points that are space characters.
- ~IF［ %位置↗ ~NEQ ε ］ ⇒ ~RET `~error^i ◎ If position is not past the end of input then return error.
- ~RET `~tuple$( %最初の~token, %最後の~token ) ◎ Return the tuple (first token, second token).
5.6.2. ~part対応付けたちが成す~listを構文解析する規則
`妥当な~part対応付け~list@ は、 文字~並び［ 0 個以上の `0020^U `SPACE^cn, 1 個の文字 `002C^U `COMMA^cn, 0 個以上の `0020^U `SPACE^cn ］で分離された， 0 個以上の`妥当な~part対応付け$からなる。 ◎ A valid list of part mappings is a number of valid part mappings separated by a U+002C COMMA character and any number of space characters before or after the U+002C COMMA
`~part対応付け~listを構文解析する@ ~algoは、 所与の ( 文字列 %入力 ) に対し，次に従う： ◎ The rules for parsing a list of part mappings are as follow: • Let input be the string being parsed.
- %対応付け~list ~LET « » ◎ ↓Split the string input on commas. Let unparsed mappings be the resulting list of strings. ◎ Let mappings be an initially empty list of tuples of tokens. This list will be the result of this algorithm.
-
`~commaで分割する$( %入力 ) の結果を成す ~EACH( %対応付け~文字列 ) に対し： ◎ For each string unparsed mapping in unparsed mappings, run the following substeps:
- ~IF［ %対応付け~文字列 は `0020^U `SPACE^cn 以外の文字を包含しない（空~文字列も含む） ］ ⇒ ~CONTINUE ◎ If unparsed mapping is empty or contains only space characters, continue to the next iteration of the loop.
- %対応付け ~LET `~part対応付けを構文解析する$( %対応付け~文字列 ) ◎ Let mapping be the result of parsing unparsed mapping using the rules for parsing part mappings.
- ~IF［ %対応付け ~EQ `~error^i ］ ⇒ ~CONTINUE ◎ If mapping is an error then continue to the next iteration of the loop. This allows clients to skip over new syntax that is not understood.
- %対応付け~list に %対応付け を`付加する$ ◎ Append mapping to mappings.
変更点
- `2014年 4月 3日 作業草案＠~TR/2014/WD-css-scoping-1-20140403/$ からの有意な変更点 ◎ The following significant changes were made since the 3 April 2014 Working Draft.
- `~tree視野な名前$は、 子孫~shadow~treeの中へ継承されるものと定義した。 ◎ Defined that tree-scoped names inherit into descendant shadow trees
- `content^pe を `slotted^pe に改称した。 ◎ Renamed ::content to ::slotted.
- `平坦~化された要素~tree$を定義した。 ◎ Define the flattened tree.
- § ~shadow~DOM を，現在の `DOM$r に基づくように~~編成し直した。 ◎ Generally reorg and rebase the Shadow DOM section on top of current DOM.
- `scope^at, `region^pe に関係するものを次の~levelの草案まで~~先送りした。 ◎ Punt @scope and related things, and ::region and related things, to the next level of the draft.
- 次に挙げるものの`詳細度$を定義した ⇒ `host$ps, `host()$ps, `host-context()$ps, `slotted()$pe ◎ Define the specificity of :host, :host(), :host-context(), and ::slotted()
- 結合子 `~gt3^css （~~過去には `/deep/^css と呼ばれていた）を除去した。 ◎ Remove the >>> (previously called /deep/) combinator.
- `~treeに留まる疑似要素＠~CSSPSEUDO#tree-abiding$は、 `slotted()$pe の後にも許容されるものと定義した。 ◎ Define that tree-abiding pseudos are allowed after ::slotted().
- すべての［ 疑似要素／疑似類 ］に `compound-selector$t【！compound-selector-list】 を許容した。 ◎ Allow <compound-selector-list> in all the pseudos.
- 所与の要素~用の既定の要素~styleを成す~stylesheetを作成する仕方を定義した。 ◎ Define a way to create a stylesheet of default element styles for a given element.
- `無特能$な要素には、 何も合致しないようにした。 ◎ Make featureless elements match nothing.
- “`~shadow~treeの文脈~下$” を定義した。 ◎ Define in the context of a shadow tree.
- `CSS-SHADOW-PARTS$r を併合して， この仕様を `CSS Shadow Module Level 1^en に改称した。 （ `5809$issue ） ◎ Merged [css-shadow-parts] and renamed the specification to CSS Shadow Module Level 1. (Issue #5809)
- `part()$pe において複数個の名前~用の~supportを追加した。 ◎ Added support for multiple names in ::part()
- “`part name map^en（~part名~map）” を “`forwarded part name list^en （`回送される~part名~list$）” に改称した。 ◎ Renamed 'part name map' to forwarded part name list
- “~part要素~list” ~algo【たぶん，`~part名~mapを計算する$~algo】を構造し直した。 ◎ Restructured 'part element list' algorithm
- `part()$pe を成す様々な詳細を`全部的に~style可能な疑似要素$へ移動した。 ◎ Moved various ::part() details to fully styleable pseudo-element
- `Web Platform Tests coverage^en を追加した。 ◎ Added Web Platform Tests coverage
- その他の編集上の改善。 ◎ Minor editorial improvements
~privacyの考慮点
この仕様は，~shadow~DOMおよび，ある［ ~shadowを貫く能力 ］を導入するが、 それが~privacyの課題を導入することはない — 現在の~shadow~DOMは、 ~privacy境界にならないよう，意図的に指定されているので （また、 ~UAの［ ~shadow~DOMを利用する，かつ~privacy境界が`ある^em ］各部は、 暗黙的に，未だ指定されていない保護に依拠している — それは、 それらをこの仕様にて定義されるものから保護する）。 ◎ This specification introduces Shadow DOM and some shadow-piercing capabilities, but this does not introduce any privacy issues—shadow DOM, as currently specified, is intentionally not a privacy boundary (and the parts of the UA that use shadow DOM and do have a privacy boundary implicitly rely on protections not yet specified, which protect them from the things defined in this specification).
【 この文脈における “~privacy境界（ `privacy boundary^en ）である” とは、 何を意味する？ その背景0にある原則は何か？ 】
~securityの考慮点
この仕様が導入する能力は、 ~page作者の便利~用に過ぎない 【…以下 “~privacy” を “~security” に読み替える下で， § ~privacyの考慮点と同じ（なので、和訳は省略する）。】 ◎ This specification introduces Shadow DOM and some shadow-piercing capabilities, but this does not introduce any security issues—shadow DOM, as currently specified, is intentionally not a security boundary, merely a convenience for page authors. Exposing shadow trees to selectors in this way introduces no new security considerations. (And the parts of the UA that use shadow DOM and do have a security boundary implicitly rely on protections not yet specified, which protect them from the things defined in this specification).