Overview.bs

<pre class='metadata'>
Title: CSS Nesting Module
Shortname: css-nesting
Level: 1
Status: ED
Work Status: Exploring
Group: CSSWG
ED: https://drafts.csswg.org/css-nesting/
TR: https://www.w3.org/TR/css-nesting-1/
Editor: Tab Atkins-Bittner, Google, http://xanthir.com/contact/, w3cid 42199
Editor: Adam Argyle, Google, https://nerdy.dev, w3cid 112669
Abstract: This module introduces the ability to nest one style rule inside another, with the selector of the child rule relative to the selector of the parent rule.  This increases the modularity and maintainability of CSS stylesheets.
</pre>

<pre class=link-defaults>
spec:css-color-4; type:property; text:color
spec:css-values-4; type:dfn; text:identifier
spec:cssom-1; type:dfn;
	text:child css rules
	text:specified order
</pre>

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

	<em>This section is not normative.</em>

	This module describes support for nesting a style rule within another style rule,
	allowing the inner rule's selector to reference the elements matched by the outer rule.
	This feature allows related styles to be aggregated into a single structure within the CSS document,
	improving readability and maintainability.

<h3 id="placement">
Module Interactions</h3>

	This module introduces new parser rules that extend the [[!CSS21]] parser model.
	It introduces selectors that extend the [[SELECTORS-4]] module.
	It extends and modifies some IDL and algorithms defined in the [[CSSOM-1]] module.

<h3 id="values">
Values</h3>

	This specification does not define any new properties or values.

<h3 id="motivation">
Motivation</h3>

	The CSS for even moderately complicated web pages
	often include lots of duplication
	for the purpose of styling related content.
	For example, here is a portion of the CSS markup for one version of the [[CSS-COLOR-3]] module:

	<div class='example'>
		<pre class=lang-css>
			table.colortable td {
				text-align:center;
			}
			table.colortable td.c {
				text-transform:uppercase;
			}
			table.colortable td:first-child, table.colortable td:first-child+td {
				border:1px solid black;
			}
			table.colortable th {
				text-align:center;
				background:black;
				color:white;
			}
		</pre>
	</div>

	Nesting allows the grouping of related style rules, like this:

	<div class='example'>
		<pre class=lang-css>
			table.colortable {
				& td {
					text-align:center;
					&.c { text-transform:uppercase }
					&:first-child, &:first-child + td { border:1px solid black }
				}
				& th {
					text-align:center;
					background:black;
					color:white;
				}
			}
		</pre>
	</div>

	Besides removing duplication,
	the grouping of related rules improves the readability and maintainability of the resulting CSS.

Nesting Style Rules {#nesting}
==============================

	Style rules can be nested inside of other styles rules.
	These <dfn export lt="nested style rule|nesting style rule">nested style rules</dfn>
	act exactly like ordinary style rules--
	associating properties with elements via selectors--
	but they "inherit" their parent rule's selector context,
	allowing them to further build on the parent's selector
	without having to repeat it,
	possibly multiple times.

	A [=nested style rule=] is exactly like a normal style rule,
	with the exception that its [=selector=]
	cannot start with an [=identifier=] or [=functional notation=].
	Additionally, [=nested style rules=]
	can use [=relative selectors=].

	<div class=example>
		That is,
		a nested style rule like:

		<pre class=lang-css>
		.foo {
			color: red;

			.bar {
				color: blue;
			}
		}
		</pre>

		is valid,
		and equivalent to:

		<pre class=lang-css>
		.foo {
			color: red;
		}
		.foo .bar {
			color: blue;
		}
		</pre>

		The nested rule can also use the [=nesting selector=]
		to directly refer to the parent rule's matched elements,
		or use [=relative selector=] syntax
		to specify relationships other than "descendant".

		<pre class=lang-css>
		.foo {
			color: red;

			&:hover {
				color: blue;
			}
		}

		/* equivalent to: */

		.foo { color: red; }
		.foo:hover { color: blue; }
		</pre>

		<pre class=lang-css>
		.foo {
			color: red;

			+ .bar {
				color: blue;
			}
		}

		/* equivalent to: */

		.foo { color: red; }
		.foo + .bar { color: blue; }
		</pre>
	</div>

	<div class=example>
		However, starting the nested selector with an identifier
		(a [=type selector=], in other words)
		is invalid:

		<pre class=lang-css class=invalid>
		div {
			color: red;

			input {
				margin: 1em;
			}
		}
		/* Invalid, because "input" is an identifier. */
		</pre>

		Such selectors can still be written,
		they just need to be slightly rephrased:

		<pre class=lang-css>
		div {
			color: red;

			& input { margin: 1em; }
			/* valid, no longer starts with an identifier */

			:is(input) { margin: 1em; }
			/* valid, starts with a colon,
			   and equivalent to the previous rule. */
		}
		</pre>
	</div>

	<details class=note>
		<summary>Why are there restrictions on nested rule selectors?</summary>

		Nesting style rules naively inside of other style rules is, unfortunately, ambiguous--
		the syntax of a selector overlaps with the syntax of a declaration,
		so an implementation requires unbounded lookahead
		to tell whether a given bit of text is a declaration or the start of a style rule.

		For example, if a parser starts by seeing ''color:hover ...'',
		it can't tell whether that's the 'color' property
		(being set to an invalid value...)
		or a selector for a <code>&lt;color></code> element.
		It can't even rely on looking for valid properties to tell the difference;
		this would cause parsing to depend on which properties the implementation supported,
		and could change over time.

		Forbidding nested style rules from starting with an [=identifier=]
		works around this problem--
		all [=declarations=] start with an identifier
		giving the property name,
		so the parser can immediately tell whether it's parsing a [=declaration=] or [=style rule=].

		Some non-browser implementations of nested rules do not impose this requirement.
		It <em>is</em>, in most cases, <em>eventually</em> possible
		to tell properties and selectors apart,
		but doing so requires unbounded lookahead in the parser;
		that is, the parser might have to hold onto an unknown amount of content
		before it can tell which way it's supposed to be interpreting it.
		CSS to date requires only a small, known amount of lookahead in its parsing,
		which allows for more efficient parsing algorithms,
		so unbounded lookahead is generally considered unacceptable among browser implementations of CSS.
	</details>


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

Syntax {#syntax}
------------------------

	The contents of [=style rules=]
	now accepts [=nested style rules=]
	and [=at-rules=],
	in addition to the existing [=declarations=].

	[=Nested style rules=] differ from non-nested rules
	in the following ways:

	* The selector of [=nested style rules=]
		must not start with an [=identifier=]
		or a [=functional notation=].
	* A [=nested style rule=] accepts a <<relative-selector-list>>
		as its prelude
		(rather than just a <<selector-list>>).
		Any [=relative selectors=]
		are relative to the elements represented by the [=nesting selector=].
	* If a selector in the <<relative-selector-list>>
		does not start with a [=combinator=]
		but does [=contain the nesting selector=],
		it is interpreted as a non-[=relative selector=].

	The precise details of how nested style rules are parsed
	are defined in [[!CSS-SYNTAX-3]].

	ISSUE(7961): The CSSWG is currently exploring the consequences of parsing lookahead,
	and may adjust the allowed syntax as a result.

	An invalid [=nested style rule=] is ignored,
	along with its contents,
	but does not invalidate its parent rule.

	<div class="example">
		For example, the following nestings are valid:

		<pre class=lang-css>
		<b>/* & can be used on its own */</b>
		.foo {
			color: blue;
			& > .bar { color: red; }
			> .baz { color: green; }
		}
		/* equivalent to
			.foo { color: blue; }
			.foo > .bar { color: red; }
			.foo > .baz { color: green; }
		*/


		<b>/* or in a compound selector,
		   refining the parent's selector */</b>
		.foo {
			color: blue;
			&.bar { color: red; }
		}
		/* equivalent to
			.foo { color: blue; }
			.foo.bar { color: red; }
		*/

		<b>/* multiple selectors in the list are all
		   relative to the parent */</b>
		.foo, .bar {
			color: blue;
			+ .baz, &.qux { color: red; }
		}
		/* equivalent to
			.foo, .bar { color: blue; }
			:is(.foo, .bar) + .baz,
			:is(.foo, .bar).qux { color: red; }
		*/

		<b>/* & can be used multiple times in a single selector */</b>
		.foo {
			color: blue;
			& .bar & .baz & .qux { color: red; }
		}
		/* equivalent to
			.foo { color: blue; }
			.foo .bar .foo .baz .foo .qux { color: red; }
		*/

		<b>/* & doesn't have to be at the beginning of the selector */</b>

		.foo {
			color: red;
			.parent & {
				color: blue;
			}
		}
		/* equivalent to
			.foo { color: red; }
			.parent .foo { color: blue; }
		*/

		.foo {
			color: red;
			:not(&) {
				color: blue;
			}
		}
		/* equivalent to
			.foo { color: red; }
			:not(.foo) { color: blue; }
		*/

		<b>/* But if you use a <l>[=relative selector=]</l>,
			an initial & is implied automatically */</b>

		.foo {
			color: red;
			+ .bar + & { color: blue; }
		}

		/* equivalent to
			.foo { color: red; }
			.foo + .bar + .foo { color: blue; }
		*/

		<b>/* Somewhat silly, but & can be used all on its own, as well. */</b>
		.foo {
			color: blue;
			& { padding: 2ch; }
		}
		/* equivalent to
			.foo { color: blue; }
			.foo { padding: 2ch; }

			// or

			.foo {
				color: blue;
				padding: 2ch;
			}
		*/

		<b>/* Again, silly, but can even be doubled up. */</b>
		.foo {
			color: blue;
			&& { padding: 2ch; }
		}
		/* equivalent to
			.foo { color: blue; }
			.foo.foo { padding: 2ch; }
		*/

		<b>/* The parent selector can be arbitrarily complicated */</b>
		.error, #404 {
			&:hover > .baz { color: red; }
		}
		/* equivalent to
			:is(.error, #404):hover > .baz { color: red; }
		*/

		.ancestor .el {
			.other-ancestor & { color: red; }
		}
		/* equivalent to
			.other-ancestor :is(.ancestor .el) { color: red; }

		<b>/* As can the nested selector */</b>
		.foo {
			& :is(.bar, &.baz) { color: red; }
		}
		/* equivalent to
			.foo :is(.bar, .foo.baz) { color: red; }
		*/

		<b>/* Multiple levels of nesting "stack up" the selectors */</b>
		figure {
			margin: 0;

			> figcaption {
				background: hsl(0 0% 0% / 50%);

				> p {
					font-size: .9rem;
				}
			}
		}
		/* equivalent to
			figure { margin: 0; }
			figure > figcaption { background: hsl(0 0% 0% / 50%); }
			figure > figcaption > p { font-size: .9rem; }
		*/
		
		<b>/* Example usage with Cascade Layers */</b>
		@layer base {
		  html {
				block-size: 100%;

				& body {
					min-block-size: 100%;
				}
			}
		}
		/* equivalent to
			@layer base {
				html { block-size: 100%; }
				html body { min-block-size: 100%; }
			}
		*/

		<b>/* Example nesting Cascade Layers */</b>
		@layer base {
		  html {
				block-size: 100%;

				@layer support {
					& body {
						min-block-size: 100%;
					}
				}
			}
		}
		/* equivalent to
			@layer base {
				html { block-size: 100%; }
			}
			@layer base.support {
				html body { min-block-size: 100%; }
			}
		*/
		
		<b>/* Example usage with Scoping */</b>
		@scope (.card) to (> header) {
		  :scope {
				inline-size: 40ch;
				aspect-ratio: 3/4;
				
				> header {
					border-block-end: 1px solid white;
				}
			}
		}
		/* equivalent to
			@scope (.card) to (> header) {
				:scope { inline-size: 40ch; aspect-ratio: 3/4; }
				:scope > header { border-block-end: 1px solid white; }
			}
		*/

		<b>/* Example nesting Scoping */</b>
		.card {
			inline-size: 40ch;
			aspect-ratio: 3/4;

			@scope (&) to (> header > *) {
				:scope > header {
					border-block-end: 1px solid white;
				}
			}
		}

		/* equivalent to
			.card { inline-size: 40ch; aspect-ratio: 3/4; }
			@scope (.card) to (> header > *) {
				:scope > header { border-block-end: 1px solid white; }
			}
		*/
		</pre>

		But these are not valid:

		<pre class=lang-css>
		<b>/* Selector starts with an identifier */</b>
		.foo {
			color: blue;
			div {
				color: red;
			}
		}
		</pre>
	</div>

	<div class=note>
		Some CSS-generating tools that preprocess nesting
		will concatenate selectors as strings,
		allowing authors to build up a <em>single</em> [=simple selector=]
		across nesting levels.
		This is sometimes used with hierarchical name patterns
		like <a href="https://en.wikipedia.org/wiki/CSS#:~:text=bem%20(block%2C%20element%2C%20modifier)">BEM</a>
		to reduce repetition across a file,
		when the selectors themselves have significant repetition internally.

		For example, if one component uses the class ''.foo'',
		and a nested component uses ''.fooBar'',
		you could write this in <a href="https://sass-lang.com/">Sass</a> as:

		<pre class="lang-css">
		.foo {
		        color: blue;
		        &Bar { color: red; }
		}
		/* In Sass, this is equivalent to
		   .foo { color: blue; }
		   .fooBar { color: red; }
		*/
		</pre>

		Unfortunately, this string-based interpretation is ambiguous with
		the author attempting to add a type selector in the nested rule.
		''Bar'', for example,
		<em>is</em> a valid <a href="https://html.spec.whatwg.org/multipage/custom-elements.html">custom element name</a> in HTML.

		CSS doesn't do this:
		the nested selector components are interpreted atomically,
		and not string-concatenated:

		<pre class="lang-css">
		.foo {
		        color: blue;
		        &Bar { color: red; }
		}
		/* In CSS, this is instead equivalent to
		   .foo { color: blue; }
		   Bar.foo { color: red; }
		*/
		</pre>
	</div>

	<div algorithm>
		A selector is said to <dfn export>contain the nesting selector</dfn>
		if, when it was [=CSS/parsed=] as any type of selector,
		a <<delim-token>> with the value "&" (U+0026 AMPERSAND) was encountered.

		Note: This is phrased in this explicit manner
		so as to catch cases like '':is(&:unknown, .bar)'',
		which discards its first argument during parsing
		(since it contains an unknown pseudo-class,
		and thus is an [=invalid selector=]).
		A selector like this still [=contains the nesting selector=].
	</div>

	If a <<forgiving-selector-list>> has an item that [=contains the nesting selector=]
	but is invalid,
	it is preserved exactly as-is
	rather than being discarded.
	(This does not change the matching behavior of the selector--
	an invalid selector still fails to match anything--
	just the serialization of the selector.)

	Issue: The preceding paragraph needs to move to Selectors
	when we move ''&'' itself to Selectors;
	I'm monkey-patching for convenience here.



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

Nesting Other At-Rules {#conditionals}
--------------------------------------

	In addition to [=nested style rules=],
	this specification allows <dfn export>nested group rules</dfn>
	inside of [=style rules=]:
	any at-rule whose body contains [=style rules=]
	can be nested inside of a [=style rule=] as well.

	When nested in this way,
	the contents of a [=nested group rule=] are parsed as <<style-block>>
	rather than <<stylesheet>>:

	* [=Style rules=] are [=nested style rules=],
		with their [=nesting selector=] taking its definition
		from the nearest ancestor [=style rule=].
	* Properties can be directly used,
		acting as if they were nested in a <code>& {...}</code> block.

	<div class=note>
		Specifically, these rules are capable of being [=nested group rules=]:

		* all the [=conditional group rules=] (''@media'', ''@supports'')
		* ''@layer''
		* ''@scope''
		* ''@container''
	</div>

	The meanings and behavior of such [=nested group rules=]
	is otherwise unchanged,
	unless otherwise specified.

	<div class="example">
		For example, the following conditional nestings are valid:

		<pre class="lang-css">
		<b>/* Properties can be directly used */</b>
		.foo {
			display: grid;

			@media (orientation: landscape) {
				grid-auto-flow: column;
			}
		}
		/* equivalent to
			.foo {
				display: grid;
				
				@media (orientation: landscape) {
					& {
						grid-auto-flow: column;
					}
				}
			}
		*/

		/* finally equivalent to
			.foo { display: grid; }

			@media (orientation: landscape) {
				.foo {
					grid-auto-flow: column;
				}
			}
		*/

		<b>/* Conditionals can be further nested */</b>
		.foo {
			display: grid;

			@media (orientation: landscape) {
				grid-auto-flow: column;

				@media (min-width > 1024px) {
					max-inline-size: 1024px;
				}
			}
		}

		/* equivalent to
			.foo { display: grid; }

			@media (orientation: landscape) {
				.foo {
					grid-auto-flow: column;
				}
			}

			@media (orientation: landscape) and (min-width > 1024px) {
				.foo {
					max-inline-size: 1024px;
				}
			}
		*/

		<b>/* Example nesting Cascade Layers */</b>
		html {
			@layer base {
				block-size: 100%;

				@layer support {
					& body {
						min-block-size: 100%;
					}
				}
			}
		}
		/* equivalent to
			@layer base {
				html { block-size: 100%; }
			}
			@layer base.support {
				html body { min-block-size: 100%; }
			}
		*/

		<b>/* Example nesting Scoping */</b>
		.card {
			inline-size: 40ch;
			aspect-ratio: 3/4;

			@scope (&) {
				:scope {
					border: 1px solid white;
				}
			}
		}

		/* equivalent to
			.card { inline-size: 40ch; aspect-ratio: 3/4; }
			@scope (.card) {
				:scope { border-block-end: 1px solid white; }
			}
		*/
		</pre>
	</div>

	All directly-nested properties are treated
	as if they were collected together, in order,
	and nested in a [=nested style rule=]
	with the selector ''&'',
	and placed before all other child rules.
	This includes in the OM.
	(That is,
	the {{CSSContainerRule/childRules}} attribute
	actually starts with this [=nested style rule=],
	containing all the directly-nested properties.)

	<div class=example>

		For example, the earlier example:

		<pre highlight=css>
		.foo {
			display: grid;

			@media (orientation: landscape) {
				grid-auto-flow: column;
			}
		}
		/* equivalent to
			.foo {
				display: grid;

				@media (orientation: landscape) {
					& {
						grid-auto-flow: column;
					}
				}
			}
		*/
		</pre>

		is in fact <em>exactly</em> equivalent,
		producing the exact same CSSOM structure.
		The {{CSSMediaRule}} object
		will have a single {{CSSStyleRule}} object
		in its <code highlight=js>.childRules</code> attribute,
		containing the 'grid-auto-flow' property.
	</div>

	Note: This does mean that the serialization of such rules will differ
	from how they were originally written,
	with <em>no</em> directly-nested properties in the serialization.


<h4 id=nesting-at-scope>
Nested ''@scope'' Rules</h4>

	When the ''@scope'' rule is a [=nested group rule=],
	an ''&'' in the <<scope-start>> selector
	refers to the elements matched
	by the nearest ancestor style rule.

	For the purposes of the style rules in its body
	and its own <<scope-end>> selector,
	the ''@scope'' rule is treated as an ancestor style rule,
	matching the elements matched by its <<scope-start>> selector.

	<div class=example>
		That is, the following code:

		<pre highlight=css>
		.parent {
			color: blue;

			@scope (& > .scope) to (& .limit) {
				& .content {
					color: red;
				}
			}
		}
		</pre>

		is equivalent to:

		<pre highlight=css>
		.parent { color: blue; }
		@scope (.parent > .scope) to (.parent > .scope .limit) {
			.parent > .scope .content {
				color: red;
			}
		}
		</pre>
	</div>

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

Mixing Nesting Rules and Declarations {#mixing}
-----------------------------------------------

	When a style rule contains both declarations
	and [=nested style rules=] or [=nested conditional group rules=],
	all three can be arbitrarily mixed.
	However, the relative order of declarations
	vs other rules
	is not preserved in any way.

	<div class=example>
		For example,
		in the following code:

		<pre class=lang-css>
		article {
			color: green;
			& { color: blue; }
			color: red;
		}

		/* equivalent to */
		article {
			color: green;
			color: red;
			& { color: blue; }
		}
		</pre>
	</div>

	For the purpose of determining the [[css-cascade-4#cascade-sort|Order Of Appearance]],
	[=nested style rules=] and [=nested conditional group rules=]
	are considered to come <em>after</em> their parent rule.

	<div>
		For example:

		<xmp class=lang-css>
			article {
				color: blue;
				& { color: red; }
			}
		</xmp>

		Both declarations have the same specificity (0,0,1),
		but the nested rule is considered to come <em>after</em> its parent rule,
		so the ''color: red'' declarations wins the cascade.

		On the other hand, in this example:

		<xmp class=lang-css>
			article {
				color: blue;
				:where(&) { color: red; }
			}
		</xmp>

		The '':where()'' pseudoclass reduces the specificity of the [=nesting selector=] to 0,
		so the ''color: red'' declaration now has a specificity of (0,0,0),
		and loses to the ''color: blue'' declaration
		before "Order Of Appearance" comes into consideration.
	</div>

	Note: While one <em>can</em> freely intermix declarations and nested rules,
	it's harder to read and somewhat confusing to do so,
	since all the properties <em>act as if</em> they came before all the rules.
	For readability's sake,
	it's recommended that authors put all their properties first in a style rule,
	before any nested rules.
	(This also happens to act slightly better in older user agents;
	due to specifics of how parsing and error-recovery work,
	properties appearing after nested rules can get skipped.)

	Note: Like with other types of rules,
	the serialization of style rules in the presence of nesting
	can vary from how they were originally written.
	Notably, all directly-nested properties
	will be serialized before any nested rules,
	which is <em>another</em> reason to write properties before rules.


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

Nesting Selector: the ''&'' selector {#nest-selector}
=====================================================

	When using a <a>nested style rule</a>,
	one must be able to refer to the elements matched by the parent rule;
	that is, after all, <em>the entire point of nesting</em>.
	To accomplish that,
	this specification defines a new selector,
	the <dfn export>nesting selector</dfn>,
	written as <dfn selector>&</dfn> (U+0026 AMPERSAND).

	When used in the selector of a <a>nested style rule</a>,
	the <a>nesting selector</a> represents the elements matched by the parent rule.
	When used in any other context,
	it represents the same elements as '':scope'' in that context
	(unless otherwise defined).

	<div class="note">
		The <a>nesting selector</a> can be desugared
		by replacing it with the parent style rule's selector,
		wrapped in an '':is()'' selector.
		For example,

		<pre class=lang-css>
		a, b {
			& c { color: blue; }
		}
		</pre>

		is equivalent to

		<pre class=lang-css>
		:is(a, b) c { color: blue; }
		</pre>
	</div>

	The [=nesting selector=] cannot represent pseudo-elements
	(identical to the behavior of the '':is()'' pseudo-class).

	<div class=example>
		For example, in the following style rule:

		<pre class=lang-css>
		.foo, .foo::before, .foo::after {
			color: red;

			&:hover { color: blue; }
		}
		</pre>

		the ''&'' only represents the elements matched by ''.foo'';
		in other words, it's equivalent to:

		<pre class=lang-css>
		.foo, .foo::before, .foo::after {
			color: red;
		}
		.foo:hover {
			color: blue;
		}
		</pre>
	</div>

	Issue: We'd like to relax this restriction,
	but need to do so simultaneously for both '':is()'' and ''&'',
	since they're intentionally built on the same underlying mechanisms.
	(<a href="https://github.com/w3c/csswg-drafts/issues/7433">Issue 7433</a>)

	The <a>specificity</a> of the <a>nesting selector</a>
	is equal to the largest specificity among the complex selectors
	in the parent style rule's selector list
	(identical to the behavior of '':is()'').

	<div class="example">
		For example, given the following style rules:

		<pre class=lang-css>
		#a, b {
			& c { color: blue; }
		}
		.foo c { color: red; }
		</pre>

		Then in a DOM structure like

		<xmp class="lang-html">
			<b class=foo>
				<c>Blue text</c>
			</b>
		</xmp>

		The text will be blue, rather than red.
		The specificity of the ''&''
		is the larger of the specificities of ''#a'' ([1,0,0])
		and <css>b</css> ([0,0,1]),
		so it's [1,0,0],
		and the entire ''& c'' selector thus has specificity [1,0,1],
		which is larger than the specificity of ''.foo c'' ([0,1,1]).

		Notably, this is <em>different</em> than the result you'd get
		if the nesting were manually expanded out
		into non-nested rules,
		since the ''color: blue'' declaration would then be matching
		due to the ''b c'' selector ([0,0,2])
		rather than ''#a c'' ([1,0,1]).
	</div>

	<details class=note>
		<summary>Why is the specificity different than non-nested rules?</summary>

		The [=nesting selector=] intentionally uses the same specificity rules
		as the '':is()'' pseudoclass,
		which just uses the largest specificity among its arguments,
		rather than tracking <em>which</em> selector actually matched.

		This is required for performance reasons;
		if a selector has multiple possible specificities,
		depending on how precisely it was matched,
		it makes selector matching much more complicated and slower.

		That skirts the question, tho:
		why <em>do</em> we define ''&'' in terms of '':is()''?
		Some non-browser implementations of Nesting-like functionality
		do <em>not</em> desugar to '':is()'',
		largely because they predate the introduction of '':is()'' as well.
		Instead, they desugar directly;
		however, this comes with its own <em>significant</em> problems,
		as some (reasonably common) cases can accidentally produce <em>massive</em> selectors,
		due to the exponential explosion of possibilities.

		<pre class=lang-css>
		.a1, .a2, .a3 {
			.b1, .b3, .b3 {
				.c1, .c2, .c3 {
					...;
				}
			}
		}

		/* naively desugars to */
		.a1 .b1 .c1,
		.a1 .b1 .c2,
		.a1 .b1 .c3,
		.a1 .b2 .c1,
		.a1 .b2 .c2,
		.a1 .b2 .c3,
		.a1 .b3 .c1,
		.a1 .b3 .c2,
		.a1 .b3 .c3,
		.a2 .b1 .c1,
		.a2 .b1 .c2,
		.a2 .b1 .c3,
		.a2 .b2 .c1,
		.a2 .b2 .c2,
		.a2 .b2 .c3,
		.a2 .b3 .c1,
		.a2 .b3 .c2,
		.a2 .b3 .c3,
		.a3 .b1 .c1,
		.a3 .b1 .c2,
		.a3 .b1 .c3,
		.a3 .b2 .c1,
		.a3 .b2 .c2,
		.a3 .b2 .c3,
		.a3 .b3 .c1,
		.a3 .b3 .c2,
		.a3 .b3 .c3 {...}
		</pre>

		Here, three levels of nesting,
		each with three selectors in their lists,
		produced 27 desugared selectors.
		Adding more selectors to the lists,
		adding more levels of nesting,
		or making the nested rules more complex
		can make a relatively small rule
		expand into multiple megabytes of selectors
		(or much, much more!).

		Some CSS tools avoid the worst of this
		by heuristically discarding some variations,
		so they don't have to output as much
		but are still <em>probably</em> correct,
		but that's not an option available to UAs.

		Desugaring with '':is()'' instead eliminates this problem entirely,
		at the cost of making specificity slightly less useful,
		which was judged a reasonable trade-off.
	</details>

	The <a>nesting selector</a> is allowed anywhere in a <a>compound selector</a>,
	even before a <a>type selector</a>,
	violating the normal restrictions on ordering within a <a>compound selector</a>.

	<div class='example'>
		For example, ''&div'' is a valid nesting selector,
		meaning "whatever the parent rules matches,
		but only if it's also a <{div}> element".

		It could also be written as ''div&'' with the same meaning,
		but that wouldn't be valid to start a [=nested style rule=]
		(but it could be used somewhere other than the very start of the selector).
	</div>


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

CSSOM {#cssom}
==============

Modifications to {{CSSStyleRule}} {#cssom-style}
---------------------------------------------

CSS style rules gain the ability to have nested rules:

<pre class=idl>
partial interface CSSStyleRule {
	[SameObject] readonly attribute CSSRuleList cssRules;
	unsigned long insertRule(CSSOMString rule, optional unsigned long index = 0);
	undefined deleteRule(unsigned long index);
};
</pre>

The <dfn attribute for=CSSStyleRule>cssRules</dfn> attribute
must return a {{CSSRuleList}} object for the [=CSSRule/child CSS rules=].

The <dfn method for=CSSStyleRule>insertRule(<var>rule</var>, <var>index</var>)</dfn> method
must return the result of
invoking [=insert a CSS rule=] <var>rule</var>
into the [=CSSRule/child CSS rules=] at <var>index</var>.


The <dfn method for=CSSStyleRule>deleteRule(<var>index</var>)</dfn> method
must [=remove a CSS rule=] from the [=CSSRule/child CSS rules=] at <var>index</var>.

Note: Serialization of {{CSSStyleRule}} with nested rules
are already well-defined by [[CSSOM]],
via [=serialize a CSS rule=].

Note: The restriction on what a [=nested style rule's=]
selector can start with
counts as a "constraint imposed by CSS"
in step 5 of [=insert a CSS rule=]
(when invoked by anything that takes [=nested style rules=],
not just {{CSSStyleRule}} itself).

When setting {{CSSStyleRule/selectorText}},
if the {{CSSStyleRule}} is a [=nested style rule=],
and the returned group of selectors
starts with a selector
that starts with an ident or function token,
do nothing and return.

Issue: The above paragraph will be inlined into the CSSOM algo,
rather than monkey-patched.