1. 序論
【未策定】2. ~custom要素に対する既定の~style
`~custom要素$の定義-時には、それに対する — 組込みの要素に適用される~UA~styleと同類の — “既定の” ~styleを設定しておくよう求められることが多い。 あいにく,これを~~素の~CSSで行うのは、次の 2 点で困難である: ◎ 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木$内で利用されるかもしれず、その場合,最も外縁の文書~内にある どの選択子からも、要素を対象にするべく到達できない。 ◎ the element in question might be used in shadow trees, and thus is unreachable by any selector targeting it in the outermost document;\
- 詳細度の課題: `型~選択子$の様な詳細度が低い選択子でも、当の要素を対象にするよう~~意図された作者~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木$内 ]にわたって適用され、その中の各~規則は,作者~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内のどの文書にも適用され~MUST。 加えて,~UA~stylesheetとして解釈され~MUST。 ◎ These stylesheets must apply to every document in the window. They must be interpreted as user agent stylesheets.
注記: これは特に、各~文書ごとに,その中のすべての`~shadow木$に適用され、それらの中の宣言は`~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.
- その中の`複体~選択子$は、無効にされ~MUST。 ◎ Within these stylesheets, complex selectors must be treated as invalid.\
- その中の`合体~選択子$は、[[ 要素のうち,その`局所~名$は `defaultElementStylesMap$sl 内で当の~stylesheetに対応付けられるもの ]を選択する,`型~選択子$ ]が追加されているものと扱われ~MUST。 ◎ 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 などの他の仕様が定義するものと期待される。 ◎ 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の~encapsulation
3.1. ~shadow~DOMの説明
~INFORMATIVEこの節では、この仕様が何を定義しているかを,~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節 に定義される要素~木の各種~~特性に加え、~DOM標準は,`~shadow木$に関係するいくつかの新たな概念を追加している。 うちいくつかは~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木$ %~shadow木 を~hostすることもある — その根である`~shadow根$ %~shadow根 は、特別な種類の`文書片$である(要素~nodeではない)。 %~shadow根 の子孫は、普通の要素その他の~nodeからなる。 %~host は、 %~shadow根 の`~host$であり, 【~shadow木を~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木 内の要素は、一般に %~host の`子孫$とはされない(`子孫~結合子$の様な選択子の目的も含め)。 しかしながら, %~shadow木 は、 %~host が属する木 — `~light木$ %~light木 — における`平坦~木$の構築に利用される。 ~CSSにおいては、この平坦~木が,選択子より後の すべて目的に(継承や~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木 は、概ね,[ %~light木 における, %~host の通常の内容 ]に代わって %~host の内容として扱われる。 しかしながら,[ %~light木 における %~host の子 ]も、ある`~slot$ %~slot に割当されることにより, %~shadow木 の “中に引き込まれる” ことはある — そのような子は、~CSSの目的においては %~slot の子として扱われる。 さらには、 %~slot も,より深い`~shadow木$内の`~slot$に割当されることもある。 幸いなことに どの`~slot$も,それ自身は 既定では~boxを生成しない ので、 %~shadow木 を包装して~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木に対する選択子の照合-法
選択子が`~shadow木$に対し照合されるときの `選択子~合致-~list@† は、初期~時には,[ 先頭の`~shadow~host$, および[ `~shadow木$の`~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 仕様に定義されていたが,現在は廃され、照合する方法も含め,別の形で表現されている。 ここの, およびこの用語を参照している記述は、更新される必要がある。 】
注記: `~shadow木$は、要素の子孫には含まれない — 要素の子孫は、`~light木$内の,要素の`子$に基づく。 ◎ 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.
`木に対し選択子を照合-$するときの `木~文脈@ は、[ その~algoに渡される %根~要素 ]の`根$で与えられる。 `木~文脈$が`~shadow根$であるとき、選択子は `~shadow木の文脈~下@ で照合されてるという。 ◎ 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木$内の[ 要素~内に埋込まれて/ 要素から~linkされて ]いるとき,その~stylesheet内のどの選択子も,`~shadow木の文脈~下$にある。 `~shadow根$上で~callされる `querySelector()$m に渡す選択子~引数も同様になる。 ◎ For example, any selector in a stylesheet embedded in or linked from an 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内の各~宣言は、それを適用するために照合した選択子の`木~文脈$を継承する。 ◎ Declarations inherit the tree context of the selector that was matched to apply them.
3.2.2. ~shadow木の中から~shadow~hostを選択するとき
`~shadow~host$ %~host は、それが~hostする`~shadow木$ %~shadow木 の外側にあるので、普通は,`~shadow木の文脈~下$で評価される選択子からは対象にできないが(選択子を照合する対象は,単独の木に制限される)、 %~shadow木 の文脈の内側からも, %~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木 の内容であるものと扱うように — %~shadow木 に現れる(言い換えれば、 %~host は,`~shadow根$ — %~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木 の中では,`無特色$であると見なされ、合致し得る選択子は[ `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木 の外側に居る %~host の~markupは、 【~shadow木を内容とする】部品の作者ではなく,~page作者の制御~下にある。 ◎ The shadow host lives outside the shadow tree, and its markup is in control of the page author, not the component author.
この部品が、 %~shadow木 内の~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 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木 内の~stylesheetが, %~host に~styleをあてがうことが理に適う利用事例も依然としてある(例えば,その部品は~flexboxとして~lay-outするよう求められている場合、 %~host の `display$p を設定することが要求される)。 なので、この状況を許容しつつ,~styleが偶発的にあてがわれないようにするため、 %~host は %~shadow木 には現れるが、完全に`無特色$で,選択するためには部品~作者が明示的に[ `host$ps, あるいは `host()^ps, `host-context()^ps ]を通して~markupに合致させる他ないようにされている。 ◎ 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木の中への選択-法: `host^ps, `host()^ps, `host-context()^ps 疑似類
`host@ps 疑似類は、`~shadow木の文脈~下$では,当の`~shadow木$を~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-list$t )
それは、`~shadow木の文脈~下$では,当の`~shadow木$を~hostしている`~shadow~host$であって, かつ[ 通常の文脈~下で引数の選択子(`合体~選択子$`の~list$)にも合致する ]ものに合致するように評価される。 他の文脈~下では,何にも合致しない。 ◎ 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.
例えば、次の様な`~shadow木$を伴う部品があるとするとき: ◎ For example, say you had a component with a shadow tree like the following:
<x-foo class="foo"> <“~shadow木”> <div class="foo">...</div> </> </x-foo>
`~shadow木$の中の~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木$の中の選択子からは、普通は,`~shadow木$の外側にある要素は全く見えない。 しかしながら、~shadow木の外側のどこか, 同じ文書~内の, より上位にある先祖を選択できると有用になることもときどきある。 ◎ 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 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木$の外側に[ 特定0の選択子に合致するような先祖 ]があるかどうか試す。 その構文は、次で与えられる: ◎ 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-list$t )
`host-context()$ps 疑似類は、`~shadow木の文脈~下$では,[ 当の~shadow木を~hostしている`~shadow~host$, または その`~shadowも含む先祖$ ]のうち[ 通常の文脈~下で引数の選択子(`合体~選択子$`の~list$)に合致する ]ものに合致するように評価される。 他の文脈~下では,何にも合致しない。 ◎ 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-list>. In any other context, it matches nothing.
注記: これは、当の選択子は、[ 文書の根に到達するか, 引数に合致する要素が見つかる ]まで,~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.
- 当の木~内の他の要素を指す別名であり、それ自体は~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-list$t )
-
次をいずれも満たす要素を表現する: ◎ 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-list$t (`合体~選択子$`の~list$)に合致する。 ◎ matched by its <compound-selector-list> argument
- `slotted()^pe`before^pe の様に, 木に留まる疑似要素 を後続させれる — それは、 `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.
例えば、次の様な[ 子たち, および~shadow木 ]を伴う部品があるとする: ◎ 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木”> <div id="five">...</div> <div id="six">...</div> <slot name="foo"></slot> </> </x-foo>
`~shadow木$の中の~stylesheetにおいては、選択子 `::slotted(*)^css は,[ `#one^css, `#two^css ]のみを選択する — それらはもっぱら `slot$e 要素に 割当される要素なので。 それは、 `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.3. ~shadow木と~cascade
~shadow根~内の要素たちを対象にしている規則の~cascade法に欲される挙動に取組むため、この仕様は, `CSS3CASCADE$r に定義される ~cascade順序 を拡張する。 ◎ To address the desired cascading behavior of rules targetting elements in shadow roots, this specification extends the cascade order defined in the Cascade specification. [CSS3CASCADE]
`出自$cCと`視野$cCとの合間に,次の~cascade判定基準が追加され~MUST: ◎ An additional cascade criteria must be added, between Origin and Scope, called Shadow Tree.
- `~shadow木@cC
- `木~文脈$が互いに異なる 2 つの宣言を比較するときは、通常の規則に対しては,`~shadowも含む木~順序$において,先に来る 【実質的には、より先祖の木に属する】 宣言が勝つ。 `!important^css 規則に対しては、逆に,後に来る宣言が勝つ。 ◎ When comparing two declarations that have different tree contexts, then for normal rules the declaration earlier in the shadow-including tree order wins, and for important rules the declaration coming later in the shadow-including tree order wins.
- 注記: これは、視野付き~styleに対する場合と【先祖, 子孫の順位が】逆になる。 ◎ Note: This is the opposite of how scoped styles work.
3.4. ~DOMから要素~木への平坦化-法
選択子は,~host言語が提示する~DOM木に対し演算するが、~CSSの他の部分が[ 標準の 親/`子$ 関係性を介しては到達できない,別々の木 ]に働くためには、単一化された木~構造が必要になる。 これは、 `平坦化された要素~木@ (略して,`平坦~木$)と呼ばれ,次に従って構築される 【この “平坦化-” は、要素の入子ではなく,木の入子を平坦化することを表す。】 : ◎ 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 ) の組として与えられる~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.
- %平坦~木 ~LET ε ◎ ↓
-
~WHILE %処理待ち~node~list は空でない: ◎ Repeatedly execute the following substeps until pending nodes is empty:
- %~item ~LET %処理待ち~node~list の最初の~item ◎ ↓
- %処理待ち~node~list から %~item を除去する ◎ Pop the first element from pending nodes, and assign it to pending node.
- %~node ~LET %~item の `~node^i ◎ ↓
- ~IF[ %平坦~木 ~NEQ ε ] ⇒ %~node を,%~item の `親^i の`子$として %平坦~木 の中に挿入する ◎ Insert pending node into the flat tree as a child of its associated parent.\
- ~ELSE ⇒ %平坦~木 ~SET %根 を根とする, %根 のみからなる新たな`平坦~木$ ◎ (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木$の`~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$である ]:
- %~slotable~list ~LET `~slot用に~slotableたちを見出す$( %~node )
-
~IF[ %~slotable~list は空でない ]:
- %~slotable~list 内の ~EACH( %~slotable ) に対し ⇒ %処理待ち~node~list に ( %~slotable, %~node ) を付加する
- ~CONTINUE
- %~node の~EACH( (`~light木$における)`子$ %子 ) に対し ⇒ %処理待ち~node~list に ( `子$, %~node ) を付加する ◎ Otherwise, ◎ Append the child nodes of pending node’s light tree to pending nodes, with pending node as their associated parent.
注記: 言い換えれば、`平坦~木$は~top-level~DOM木であるが:
- 各`~shadow~host$は、その`~light木$内の子たちに代わって,`~shadow木$内の子たちで埋められる(更に,その`~shadow木$も`~shadow~host$を包含するならば,これを再帰的に続行する)
- 各`~slot$は、それに割当された~nodeたちで埋められる(更に,`~slot$自身が より深い`~shadow木$内の`~slot$が割当されたなら,これを再帰的に続行する)。
これによる明白でない結果は、~slotに割当された要素は、その~slotから【~styleを】継承することである — 要素の~light木における親や, その~slotが割当されている より深い~slotでなく。 このことは、【~slotに割当された】~text~nodeは、その親の~shadow木により~styleされ,他からはどうやっても介入できないことを意味する。 そのような~text~nodeを対象にする追加の疑似要素は,求められるか? — それらにも,要素のときと同様に at all slot-assignment levels【?】で~styleできるように。 このことは、~light木~内の~text~nodeに対しても,~slotに割当される前に,そのような疑似要素が働く必要があることを含意する。 なので、これは,ただの `slotted()$pe の変種にはなり得ない。 Luckily, this is a long-standing request!【何が Luckily?】 ◎ 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!
3.4.1. ~shadow木~内の~slotとそれに割当される要素
`~slot$は、[ `~UA出自$内の規則を介して,その `display$p に `contents$v があてがわれている ]かのように動作し~MUST。 これは、 `display$p を介して上書きできるようにされ~MUST — 欲されるときには、`~slot$が~boxを生成できるよう。 ◎ 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 規則として 実装されている。 】
注記: `~slot$に要素を割当することによる明白でない結果は、要素は,その`~slot$から【~styleを】継承することである。 [ 要素の親(`~light木$における要素の元の親) ]/[ その`~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. 変更点
2014 年 4 月 3 日付 作業草案 からの有意な変更点は: ◎ The following significant changes were made since the 3 April 2014 Working Draft.
- `content^pe を `slotted^pe に改称した。 ◎ Renamed ::content to ::slotted.
- `平坦化された要素~木$を定義した。 ◎ 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.
5. ~privacyと~security上の考慮点
この仕様は Shadow DOM および,ある~shadowを貫く能力を導入するが、それが何らかの[ ~privacy/~security ]に課題を導入することはない — 現在の~shadow ~DOMは、そのような境界にならないよう,意図的に指定されているので(また、 ~UAの[ ~shadow~DOMを利用する / そのような境界がある ]部分は、暗黙的に未だ指定されていない保護に依拠している — それはそれらをこの仕様にて定義されるものから保護する【?】 )。 ◎ This specification introduces Shadow DOM and some shadow-piercing capabilities, but this does not introduce any privacy or security issues—shadow DOM, as currently specified, is intentionally not a privacy/security boundary (and the parts of the UA that use shadow DOM and do have a privacy/security boundary implicitly rely on protections not yet specified, which protect them from the things defined in this specification).