csswg-drafts/css-scoping/Overview.bs at 302d7732d02e0ed6870a4f94d7b3a3345e3e3aff · w3c/csswg-drafts · GitHub

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
<pre class='metadata'>
Title: CSS Scoping Module Level 1
Level: 1
Shortname: css-scoping
Group: CSSWG
Status: ED
Work Status: Exploring
TR: https://www.w3.org/TR/css-scoping-1/
ED: https://drafts.csswg.org/css-scoping/
Previous Version: https://www.w3.org/TR/2014/WD-css-scoping-1-20140403/
Editor: Tab Atkins Jr., Google, http://xanthir.com/contact/
Abstract: This specification defines scoping/encapsulation mechanisms for CSS, focusing on the Shadow DOM scoping mechanism.
Ignored Terms: inherit, slot, custom elements, stylesheets
Ignored Vars: root elements
</pre>

<pre class="link-defaults">
spec:dom; type:dfn;
	text:host
	text:shadow root; for:/
	text:root; for:tree
	text:find slotables
	text:find flattened slotables
spec:html; type:element; text:style
spec:selectors-4; type:dfn;
	text: static profile
	text: dynamic profile
spec:css-pseudo-4; type:selector;
	text:::before
	text:::after
spec:cascade-4; type:dfn; text: inherit
</pre>

<h2 id="intro">
Introduction</h2>

	...


<!--
████████  ████████ ████████    ███    ██     ██ ██       ████████
██     ██ ██       ██         ██ ██   ██     ██ ██          ██
██     ██ ██       ██        ██   ██  ██     ██ ██          ██
██     ██ ██████   ██████   ██     ██ ██     ██ ██          ██
██     ██ ██       ██       █████████ ██     ██ ██          ██
██     ██ ██       ██       ██     ██ ██     ██ ██          ██
████████  ████████ ██       ██     ██  ███████  ████████    ██
-->

<h2 id='default-element-styles'>
Default Styles for Custom Elements</h2>

	When defining <a>custom elements</a>,
	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--
	the element in question might be used in <a>shadow trees</a>,
	and thus is unreachable by any selector targeting it in the outermost document;
	and selectors, even low-specificity ones like simple <a>type selectors</a>,
	can accidentally override author-level styles meant to target the element.

	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 <a>shadow trees</a>,
	and the rules in it apply at the <a>user agent origin</a>,
	so author-level rules automatically win.

	{{Window}}s gain a private slot <dfn attribute for=Window>\[[defaultElementStylesMap]]</dfn>
	which is a map of <a for="Element">local names</a> to <a>stylesheets</a>.

	These stylesheets must apply to every document in the window.
	They must be interpreted as user agent stylesheets.

	Note: This implies, in particular,
	that they apply to all <a>shadow trees</a> in every document,
	and that the declarations in them are from the <a>user agent origin</a>.

	For the purpose of the <a>cascade</a>,
	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, <a>complex selectors</a> must be treated as invalid.
	Every <a>compound selector</a> must be treated as containing an additional <a>type selector</a>
	that selects elements with the <a for=Element>local name</a>
	that the stylesheet is keyed with.

	Issue: Do we need to restrict the <a>at-rules</a> 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.

	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.

<!--
 ██████  ██     ██    ███    ████████   ███████  ██      ██
██    ██ ██     ██   ██ ██   ██     ██ ██     ██ ██  ██  ██
██       ██     ██  ██   ██  ██     ██ ██     ██ ██  ██  ██
 ██████  █████████ ██     ██ ██     ██ ██     ██ ██  ██  ██
      ██ ██     ██ █████████ ██     ██ ██     ██ ██  ██  ██
██    ██ ██     ██ ██     ██ ██     ██ ██     ██ ██  ██  ██
 ██████  ██     ██ ██     ██ ████████   ███████   ███  ███
-->

<h2 id='shadow-dom'>
Shadow Encapsulation</h2>

<h3 id='shadow-gloss'>
Informative Explanation of Shadow DOM</h3>

	<em>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.</em>

	In addition to the qualities of an element tree defined in [[SELECTORS4#data-model]],
	the DOM Standard adds several new concepts related to <a>shadow trees</a>,
	several of which are relevant to CSS.

	An element can host a <a>shadow tree</a>,
	which is a special kind of document fragment
	with a <a>shadow root</a>
	(a non-element node)
	at its root.
	Children of the <a>shadow root</a> are ordinary elements and other nodes.
	The element hosting the <a>shadow tree</a> is its <a>host</a>,
	or <a>shadow host</a>.

	The elements in a <a>shadow tree</a> are not <a>descendants</a> of the <a>shadow host</a> in general
	(including for the purposes of Selectors like the <a>descendant combinator</a>).
	However, the <a>shadow tree</a>,
	when it exists,
	is used in the construction of the <a>flattened element tree</a>,
	which CSS uses for all purposes <em>after</em> Selectors
	(including inheritance and box construction).

	Loosely, the <a>shadow tree</a> is treated as the <a>shadow host's</a> contents
	instead of its normal <a>light tree</a> contents.
	However, some of its <a>light tree</a> children
	can be "pulled into" the <a>shadow tree</a>
	by assigning them to <a>slots</a>.
	This causes them to be treated as children of the <a>slot</a>
	for CSS purposes.
	The <a>slots</a> can then be assigned to <a>slots</a>
	in deeper <a>shadow trees</a>;
	luckily, <a>slots</a> themselves don't generate boxes by default,
	so you don't get an unpredictable cascade of <{slot}> wrapper elements
	disrupting your CSS.

	If nothing is explicitly assigned to a <a>slot</a>,
	the <a>slot's</a> own children are instead assigned to it,
	as a sort of "default" contents.

<h3 id='selectors'>
Shadow DOM and Selectors</h3>

<h4 id='selectors-data-model'>
Matching Selectors Against Shadow Trees</h4>

	When a selector is matched against a <a>shadow tree</a>,
	the <a>selector match list</a>
	is initially the <a>shadow host</a>,
	followed by all children of the <a>shadow tree's</a> <a>shadow root</a>
	and their descendants,
	ordered by a pre-order traversal.

	Note: Remember that the <a>descendants</a> of an element
	are based on the <a>light tree</a> <a>children</a> of the element,
	which does not include the <a>shadow trees</a> of the element.

	When a selector is <a lt="match a selector against a tree">matched against a tree</a>,
	its <dfn export>tree context</dfn> is the <a>root</a> of the <var>root elements</var> passed to the algorithm.
	If the <a>tree context</a> is a <a>shadow root</a>,
	that selector is being matched <dfn export lt="in the context of a shadow tree|in the context of the shadow tree">in the context of a shadow tree</dfn>.

	<div class="example">
		For example,
		any selector in a stylesheet embedded in or linked from an an element in a <a>shadow tree</a>
		is <a>in the context of a shadow tree</a>.
		So is the argument to {{querySelector()}} when called from a <a>shadow root</a>.
	</div>

	Declarations inherit the <a>tree context</a>
	of the selector that was matched to apply them.

<h4 id='host-element-in-tree'>
Selecting Shadow Hosts from within a Shadow Tree</h4>

	A <a>shadow host</a> is outside of the <a>shadow tree</a> it hosts,
	and so would ordinarily be untargettable by any selectors evaluated <a>in the context of the shadow tree</a>
	(as selectors are limited to a single tree),
	but it is sometimes useful to be able to style it from inside the <a>shadow tree</a> context.

	For the purpose of Selectors,
	a <a>shadow host</a> also appears in its <a>shadow tree</a>,
	with the contents of the <a>shadow tree</a> treated as its children.
	(In other words, the <a>shadow host</a> is treated as replacing the <a>shadow root</a> node.)

	When considered within its own <a>shadow trees</a>,
	the <a>shadow host</a> is <a>featureless</a>.
	Only the '':host'', '':host()'', and '':host-context()'' pseudo-classes are allowed to match it.

	<details class='note'>
		<summary>Why is the shadow host so weird?</summary>

		The <a>shadow host</a> lives outside the <a>shadow tree</a>,
		and its markup is in control of the page author,
		not the component author.

		It would not be very good if a component used a particular class name
		internally in a <a>shadow tree</a> stylesheet,
		and the page author using the component accidentally <em>also</em>
		used the the same class name and put it on the <a>shadow host</a>.
		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.

		However, there are still some reasonable use-cases for letting a stylesheet in a <a>shadow tree</a>
		style its <a>shadow host</a>.
		(For example,
		the component might want to be laid out as a flexbox,
		requiring the <a>shadow host</a> to be set to ''display: flex''.)
		So, to allow this situation but prevent accidental styling,
		the <a>shadow host</a> 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.
	</details>

<!--
 ██  ██     ██  ███████   ██████  ████████
████ ██     ██ ██     ██ ██    ██    ██
 ██  ██     ██ ██     ██ ██          ██
     █████████ ██     ██  ██████     ██
 ██  ██     ██ ██     ██       ██    ██
████ ██     ██ ██     ██ ██    ██    ██
 ██  ██     ██  ███████   ██████     ██
-->

<h4 id='host-selector'>
Selecting Into the Light: the '':host'', '':host()'', and '':host-context()'' pseudo-classes</h4>

	The <dfn selector>:host</dfn> pseudo-class,
	when evaluated <a>in the context of a shadow tree</a>,
	matches the <a>shadow tree's</a> <a>shadow host</a>.
	In any other context,
	it matches nothing.

	The <dfn selector id="selectordef-host-function">:host()</dfn> function pseudo-class
	has the syntax:

	<pre>:host( <<compound-selector-list>> )</pre>

	When evaluated <a>in the context of a shadow tree</a>,
	it matches the <a>shadow tree's</a> <a>shadow host</a>
	if the <a>shadow host</a>,
	in its normal context,
	matches the selector argument.
	In any other context,
	it matches nothing.

	<div class='example'>
		For example, say you had a component with a <a>shadow tree</a> like the following:

		<pre>
			&lt;x-foo class="foo">
				&lt;"shadow tree">
					&lt;div class="foo">...&lt;/div>
				&lt;/>
			&lt;/x-foo>
		</pre>

		For a stylesheet within the <a>shadow tree</a>:

		* '':host'' matches the <code>&lt;x-foo></code> element.
		* ''x-foo'' matches nothing.
		* ''.foo'' matches only the <code>&lt;div></code> element.
		* ''.foo:host'' matches nothing
		* '':host(.foo)'' matches the <code>&lt;x-foo></code> element.
	</div>

	Ordinary, selectors within a <a>shadow tree</a>
	can't see elements outside the <a>shadow tree</a> at all.
	Sometimes, however, it's useful to select an ancestor that lies somewhere outside the shadow tree,
	above it in the document.

	<div class='example'>
		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.
	</div>

	The <dfn selector>:host-context()</dfn> functional pseudo-class tests whether there is an ancestor,
	outside the <a>shadow tree</a>,
	which matches a particular selector.
	Its syntax is:

	<pre class=prod>:host-context( <<compound-selector-list>> )</pre>

	When evaluated <a>in the context of a shadow tree</a>,
	the '':host-context()'' pseudo-class matches the <a>shadow host</a>,
	if the <a>shadow host</a> or one of its <a>shadow-including ancestors</a>
	matches the provided <<compound-selector-list>>.
	In any other context,
	it matches nothing.

	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.


<!--
 ██   ██   ██████  ██        ███████  ████████ ████████ ████████ ████████
████ ████ ██    ██ ██       ██     ██    ██       ██    ██       ██     ██
 ██   ██  ██       ██       ██     ██    ██       ██    ██       ██     ██
           ██████  ██       ██     ██    ██       ██    ██████   ██     ██
 ██   ██        ██ ██       ██     ██    ██       ██    ██       ██     ██
████ ████ ██    ██ ██       ██     ██    ██       ██    ██       ██     ██
 ██   ██   ██████  ████████  ███████     ██       ██    ████████ ████████
-->

<h4 id='slotted-pseudo'>
Selecting Slot-Assigned Content: the ''::slotted()'' pseudo-element</h4>

	The <dfn selector>::slotted()</dfn> pseudo-element
	represents the elements <a lt="find flattened slotables">assigned, after flattening,</a> to a <a>slot</a>.
	This pseudo-element only exists on <a>slots</a>.

	The ''::slotted()'' pseudo-element is an <em>alias</em> for other elements in the tree,
	and does not generate any boxes itself.

	The grammar of the ''::slotted()'' pseudo-element is:

	<pre class=prod>::slotted( <<compound-selector-list>> )</pre>

	The ''::slotted()'' pseudo-element represents the elements that are:

	* <a lt="find flattened slotables">assigned, after flattening,</a> to the <a>slot</a> that is ''::slotted''’s originating element
	* <a lt="match a selector against an element">matched</a> by its <<compound-selector-list>> argument

	The ''::slotted()'' pseudo-element can be followed by a <a>tree-abiding pseudo-element</a>,
	like ''::slotted()::before'',
	representing the appropriate pseudo-element of the elements represented by the ''::slotted()'' pseudo-element.

	<div class="example">
		For example, say you had a component with both children and a shadow tree,
		like the following:

		<pre>
			&lt;x-foo>
				&lt;div id="one" slot="foo" class="foo">...&lt;/div>
				&lt;div id="two" slot="foo">...&lt;/div>
				&lt;div id="three" class="foo">
					&lt;div id="four" slot="foo">...&lt;/div>
				&lt;/div>
				&lt;"shadow tree">
					&lt;div id="five">...&lt;/div>
					&lt;div id="six">...&lt;/div>
					&lt;slot name="foo">&lt;/slot>
				&lt;/"shadow tree">
			&lt;/x-foo>
		</pre>

		For a stylesheet within the <a>shadow tree</a>,
		a selector like ''::slotted(*)''
		selects ''#one'' and ''#two'' only,
		as they're the elements <a lt="find flattened slotables">assigned</a> to the sole <{slot}> element.
		It will <em>not</em> select ''#three''
		(no <code>slot</code> attribute)
		nor ''#four''
		(only direct <a>children</a> of a <a>shadow host</a> can be assigned to a <a>slot</a>).

		A selector like ''::slotted(.foo)'',
		on the other hand,
		will only select ''#one'',
		as it matches ''.foo'',
		but ''#two'' doesn't.

		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 <a>slots</a>,
		they're the only elements with a ''::slotted()'' pseudo-element as well.
	</div>

	Note: ''::slotted()'' can only represent the <em>elements</em>
	assigned to the <a>slot</a>.
	<a>Slots</a> 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 <a>slot</a> and relying on inheritance.

<!--
██    ██    ██
 ██    ██    ██
  ██    ██    ██
   ██    ██    ██
  ██    ██    ██
 ██    ██    ██
██    ██    ██
-->

<h4 id='deep-combinator'>
Selecting Through Shadows: the ''>>>'' combinator</h4>

	When a <dfn selector id="selectordef-shadow-piercing-descendant-combinator">>>></dfn> combinator
	(or <dfn export>shadow-piercing descendant combinator</dfn>)
	is encountered in a selector,
	replace every element in the <a>selector match list</a>
	with every element reachable from the original element
	by traversing any number of child lists or shadow trees.

	<div class='example'>
		For example, say you had a component with a <a>shadow tree</a> like the following:

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

		For a stylesheet in the outer document,
		the selector ''x-foo >>> span''
		selects all three of <code>&lt;span></code> elements:
		''#top'', ''#not-top'', <em>and</em> ''#nested''.
	</div>

	The <a>shadow-piercing descendant combinator</a> is part of the <a>static profile</a> of Selectors,
	not the <a>dynamic profile</a>.
	This means that it is usable in,
	for example, the {{querySelector()}} method,
	but is invalid when used in stylesheets.

<!--
 ██████     ███     ██████   ██████     ███    ████████  ████████
██    ██   ██ ██   ██    ██ ██    ██   ██ ██   ██     ██ ██
██        ██   ██  ██       ██        ██   ██  ██     ██ ██
██       ██     ██  ██████  ██       ██     ██ ██     ██ ██████
██       █████████       ██ ██       █████████ ██     ██ ██
██    ██ ██     ██ ██    ██ ██    ██ ██     ██ ██     ██ ██
 ██████  ██     ██  ██████   ██████  ██     ██ ████████  ████████
-->

<h3 id='shadow-cascading'>
Shadow Trees and the Cascade</h3>

	To address the desired cascading behavior of rules targetting elements in shadow roots,
	this specification extends the <a href="https://drafts.csswg.org/css-cascade/#cascading">cascade order</a>
	defined in the Cascade specification. [[!CSS3CASCADE]]

	An additional cascade criteria must be added,
	between Origin and Scope,
	called Shadow Tree.

	* When comparing two declarations
		that have different <a>tree contexts</a>,
		then for normal rules the declaration earlier in the <a>shadow-including tree order</a> wins,
		and for important rules the declaration coming later in the <a>shadow-including tree order</a> wins.

		Note: This is the <em>opposite</em> of how scoped styles work.

<!--
████████ ██          ███    ████████       ████████ ████████  ████████ ████████
██       ██         ██ ██      ██             ██    ██     ██ ██       ██
██       ██        ██   ██     ██             ██    ██     ██ ██       ██
██████   ██       ██     ██    ██             ██    ████████  ██████   ██████
██       ██       █████████    ██             ██    ██   ██   ██       ██
██       ██       ██     ██    ██             ██    ██    ██  ██       ██
██       ████████ ██     ██    ██             ██    ██     ██ ████████ ████████
-->

<h3 id='flattening' algorithm>
Flattening the DOM into an Element Tree</h3>

	While Selectors operates on the DOM tree as the host language presents it,
	with separate trees that are unreachable via the standard parent/<a>child</a> relationship,
	the rest of CSS needs a single unified tree structure to work with.
	This is called the <dfn export lt="flat tree|flattened element tree">flattened element tree</dfn>
	(or <a>flat tree</a>),
	and is constructed as follows:

	1. Let <var>pending nodes</var> be a list of DOM nodes with associated parents,
		initially containing just the document's <a>root</a> element with no associated parent.
	2. Repeatedly execute the following substeps until <var>pending nodes</var> is empty:
		1. Pop the first element from <var>pending nodes</var>,
			and assign it to <var>pending node</var>.
		2. Insert <var>pending node</var> into the <a>flat tree</a>
			as a child of its associated parent.
			(If it has no associated parent,
			it's the document root--
			just insert it into the <a>flat tree</a> as its root.)
		3. Perform one of the following,
			whichever is the first that matches:

			<dl class=switch>
				<dt><var>pending node</var> is a <a>shadow host</a>
				<dd>
					Append the child nodes of the <a>shadow root</a> of the <a>shadow tree</a> it hosts
					to <var>pending nodes</var>,
					with <var>pending node</var> as their associated parent.
				<dt><var>pending node</var> is a <a>slot</a>
				<dd>
					<a>Find slotables</a> for <var>pending node</var>,
					and append them to <var>pending nodes</var>,
					with <var>pending node</var> as their associated parent.

					If no <a>slotables</a> were found for <var>pending node</var>,
					instead append its <a>children</a> to <var>pending nodes</var>,
					with <var>pending node</var> as their associated parent.
				<dt>Otherwise,
				<dd>
					Append the child nodes of <var>pending node</var>’s <a>light tree</a>
					to <var>pending nodes</var>,
					with <var>pending node</var> as their associated parent.
			</dl>

	Note: In other words, the <a>flat tree</a> is the top-level DOM tree,
	but <a>shadow hosts</a> are filled with their <a>shadow tree</a> children
	instead of their <a>light tree</a> children
	(and this proceeds recursively if the <a>shadow tree</a> contains any <a>shadow hosts</a>),
	and <a>slots</a> get filled with the nodes that are assigned to them
	(and this proceeds recursively if the <a>slots</a> are themselves
	assigned to a <a>slot</a> in a deeper <a>shadow tree</a>).

	Issue: 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!

<h4 id='slots-in-shadow-tree'>
Slots and Slotted Elements in a Shadow Tree</h4>

	<a>Slots</a> must act as if they were assigned ''display: contents''
	via a rule in the <a>UA origin</a>.
	This must be possible to override via 'display',
	so they <em>do</em> generate boxes if desired.

	Note: A non-obvious result of assigning elements to <a>slots</a>
	is that they <a>inherit</a> from the <a>slot</a> they're assigned to.
	Their original <a>light tree</a> parent,
	and any deeper <a>slots</a> that their <a>slot</a> gets assigned to,
	don't affect inheritance.

<h2 id="changes">
Changes</h2>

	The following significant changes were made since the
	<a href="https://www.w3.org/TR/2014/WD-css-scoping-1-20140403/">3 April 2014 Working Draft</a>.

	* Renamed <css>::content</css> to ''::slotted''.
	* Define the flattened tree
	* Generally reorg and rebase the Shadow DOM section on top of current DOM.
	* Punt <css>@scope</css> and related things,
		and <css>::region</css> and related things,
		to the next level of the draft.

Privacy and Security Considerations {#priv-sec}
===============================================

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 <em>do</em> have a privacy/security boundary
implicitly rely on protections not yet specified,
which protect them from the things defined in this specification).