> 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: 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 allowed anywhere in a compound selector,
even before a type selector,
violating the normal restrictions on ordering within a compound selector.
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).
CSSOM {#cssom}
==============
Modifications to {{CSSStyleRule}} {#cssom-style}
---------------------------------------------
CSS style rules gain the ability to have nested rules:
partial interface CSSStyleRule {
[SameObject] readonly attribute CSSRuleList cssRules;
unsigned long insertRule(CSSOMString rule, optional unsigned long index = 0);
undefined deleteRule(unsigned long index);
};
The cssRules attribute
must return a {{CSSRuleList}} object for the [=CSSRule/child CSS rules=].
The insertRule(rule, index) method
must return the result of
invoking [=insert a CSS rule=] rule
into the [=CSSRule/child CSS rules=] at index.
The deleteRule(index) method
must [=remove a CSS rule=] from the [=CSSRule/child CSS rules=] at index.
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.