> selector.
That is, the following code:
.parent {
color: blue;
@scope (& > .scope) to (& .limit) {
& .content {
color: red;
}
}
}
is equivalent to:
.parent { color: blue; }
@scope (.parent > .scope) to (.parent > .scope .limit) {
.parent > .scope .content {
color: red;
}
}
For example,
in the following code:
article {
color: green;
& { color: blue; }
color: red;
}
/* equivalent to */
article {
color: green;
color: red;
& { color: blue; }
}
For example:
<![CDATA[
article {
color: blue;
& { color: red; }
}
]]>
Both declarations have the same specificity (0,0,1),
but the nested rule is considered to come after its parent rule,
so the ''color: red'' declarations wins the cascade.
On the other hand, in this example:
<![CDATA[
article {
color: blue;
:where(&) { color: red; }
}
]]>
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.
Note: This behavior both matches many existing preprocessor-based nesting behaviors,
and ensures that a rule can be faithfully expressed in the CSSOM
without requiring drastic changes to the existing {{CSSStyleRule}} object.
Note: While one can freely intermix declarations and nested rules,
it's harder to read and somewhat confusing to do so,
since all the properties act as if 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 another reason to write properties before rules.
Nesting Selector: the ''&'' selector {#nest-selector}
=====================================================
When using a nested style rule,
one must be able to refer to the elements matched by the parent rule;
that is, after all, the entire point of nesting.
To accomplish that,
this specification defines a new selector,
the nesting selector,
written as & (U+0026 AMPERSAND).
When used in the selector of a nested style rule,
the nesting selector 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).
The
nesting selector can be desugared
by replacing it with the parent style rule's selector,
wrapped in an '':is()'' selector.
For example,
a, b {
& c { color: blue; }
}
is equivalent to
:is(a, b) c { color: blue; }
For example, in the following style rule:
.foo, .foo::before, .foo::after {
color: red;
&:hover { color: blue; }
}
the ''&'' only represents the elements matched by ''.foo'';
in other words, it's equivalent to:
.foo, .foo::before, .foo::after {
color: red;
}
.foo:hover {
color: blue;
}
For example, given the following style rules:
#a, b {
& c { color: blue; }
}
.foo c { color: red; }
Then in a DOM structure like
<![CDATA[
<b class=foo>
<c>Blue text</c>
</b>
]]>
The text will be blue, rather than red.
The specificity of the ''&''
is the larger of the specificities of ''#a'' ([1,0,0])
and
b ([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
different 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]).
Why is the specificity different than non-nested rules?
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 which 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 do we define ''&'' in terms of '':is()''?
Some non-browser implementations of Nesting-like functionality
do not desugar to '':is()'',
largely because they predate the introduction of '':is()'' as well.
Instead, they desugar directly;
however, this comes with its own significant problems,
as some (reasonably common) cases can accidentally produce massive selectors,
due to the exponential explosion of possibilities.
.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 {...}
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 probably 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.
The [=nesting selector=] is capable of matching [=featureless=] elements,
if they were matched by the parent rule.
While the position of a [=nesting selector=] in a [=compound selector=]
does not make a difference in its behavior
(that is, ''&.foo'' and ''.foo&'' match the same elements),
the existing rule that a [=type selector=], if present, must be first in the [=compound selector=]
continues to apply
(that is, ''&div'' is illegal, and must be written ''div&'' instead).
CSSOM {#cssom}
==============
Note: [[CSSOM-1]] now defines
that {{CSSStyleRule}} can have child rules.
When serializing a [=relative selector=] in a [=nested style rule=],
the selector must be absolutized,
with the implied [=nesting selector=] inserted.
When serializing a [=nested group rule=],
it must serialize solely with child rules.
For example, the selector ''> .foo''
will serialize as ''& > .foo''.
A [=nested group rule=] like:
.foo {
@media (prefers-color-scheme: dark) {
color: white;
background: black;
}
}
will serialize as:
.foo {
@media (prefers-color-scheme: dark) {
& {
color: white;
background: black;
}
}
}