1. ~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.
2. ~shadowの~capsule化
2.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.
2.2. ~shadow~DOMと選択子
2.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.
2.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.
2.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.
2.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.
2.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 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.
2.3. ~shadow~treeと~cascade
`~cascade文脈$【！§ ~CASCADE#cascade-sort】 `CSS-CASCADE-4$r を見よ。 ◎ See CSS Cascading 4 § 6.1 Cascade Sorting Order.
2.4. ~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!
2.4.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.
2.5. 名前を定義する構成子と継承
`~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 に与える名前, `keyframes$at に与える名前） を定義するものは、 それを `~tree視野な名前@ （ `tree-scoped name^en ） — その視野は ある~treeに絞られる名前 — として定義しなければナラナイ。 `~tree視野な名前$は、 他が指定されない限り，特定0の`~node~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 @keyframes name, it must be defined as a tree-scoped name. Tree-scoped names are "global" within a particular node tree; unless otherwise specified, they’re associated with the root of the element hosting the stylesheet that the at-rule or property is defined in.
“大域的” な名前を参照する［ ~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 "global" name, such as the font-family or animation-name properties, must define their value as a tree-scoped reference. Tree-scoped 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 defined in. This root reference stays with the tree-scoped reference as it is inherited.
`~tree視野な参照$ %参照 を［ それが参照している~CSS構成子を見出すために参照解決する所 ］では、 まず，`~tree視野な名前$のうち［ それに結付けられた`根$が %参照 に結付けられた`根$と同じになるもの ］に限り探索するモノトスル — 該当する`~tree視野な名前$は見出されなかった場合、 %参照 に結付けられた`根$は`~shadow根$であるならば，`根$の`~host$が属する`~node~tree$内でこの探索を繰返すとする （言い換えれば、 `~tree視野な名前$は，子孫~shadow~treeの中へ — 子孫~tree自身が同じ名前を定義していない限り — “継承される” ）。 ◎ Whenever a tree-scoped reference is dereferenced to find the CSS construct it is referencing, first search only the tree-scoped names associated with the same root as the tree-scoped reference must be searched. 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. (In other words, tree-scoped names "inherit" into descendant shadow trees, so long as they don’t define the same name themselves.)
［ 大域的な名前を定義する すべての~at-規則／ それらを参照する すべての~prop ］は、 これらの概念を利用するよう修正する必要がある： ◎ TODO: Fix all the at-rules that define global names, and the properties that reference them, to use these concepts.
- `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.
2.5.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.
変更点
`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()
- 結合子 `>>>^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.
~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の考慮点
【“~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 (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).