1. 序論
◎非規範的この~moduleは、別の`~style規則$の中に~style規則を入子にするための~supportを述べる — それは、内縁~規則の選択子が，外縁~規則に合致した要素を参照できるようにする。 この特能は、関係し合う~styleたちを~CSS文書の中の単独の構造に集約できるようにして，可読性と保守能を改善する。 ◎ 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.
1.1. ~module間の相互作用
この~moduleは： ◎ This module＼
- `CSS21$r 構文解析器~modelを拡張する新たな構文解析器~規則を導入する。 ◎ introduces new parser rules that extend the [CSS21] parser model.＼
- `SELECTORS-4$r ~moduleを拡張する選択子を導入する。 ◎ It introduces selectors that extend the [SELECTORS-4] module.＼
- `CSSOM$r【！CSSOM-1】 ~moduleに定義された一部の~IDLと~algoを拡張して改変する。 ◎ It extends and modifies some IDL and algorithms defined in the [CSSOM-1] module.
1.2. 値
この仕様は、新たな~propや値は定義しない。 ◎ This specification does not define any new properties or values.
【この訳に特有な表記規約】
◎表記記号2. 説明書き
◎非規範的もっと~~簡潔な仕方で書きたい~CSSがあったとする： ◎ Imagine you have some CSS that you’d like to write in a more compact way.
.foo {
color: green;
}
.foo .bar {
font-size: 1.4rem;
}
そのような~codeは、 入子法により次のように書ける： ◎ With Nesting, you can write such code as:
.foo {
color: green;
.bar {
font-size: 1.4rem;
}
}
`Sass＠https://sass-lang.com/$ その他の~CSS前処理器において ~styleを入子にしていた作者は、 これが，ごく馴染みであることを見出すことになろう。 ◎ If you’ve been nesting styles in Sass or other CSS preprocessors, you will find this very familiar.
どの規則も，親~style規則の内側に入子にできる： ◎ You can nest any rules inside of a parent style rule:
main {
div { ... }
.bar { ... }
#baz { ...}
:has(p) { ... }
::backdrop { ... }
[lang|="zh"] { ... }
* { ... }
}
既定では、 子~規則の選択子は， `子孫~結合子$を挟んで親~規則と接続するものと見做されるが、 入子な選択子は，どの結合子からでも開始するよう変更できる： ◎ By default, the child rule’s selector is assumed to connect to the parent rule by a descendant combinator, but you can start the nested selector with any combinator to change that:
main {
+ article { ... }
> p { ... }
~ main { ... }
}
新たな選択子 `&$css は、 親~選択子に合致した要素を明示的に参照rできるようにする。 なので、 直前の例は，次のように書くこともできた： ◎ The new & selector lets you refer to the elements matched by the parent selector explictly, so the previous examples could have been written as:
main {
& + article { ... }
& > p { ... }
& ~ main { ... }
}
`&$css は、 入子な選択子の中の他の所在に配置することで，親~規則と子~規則の間に他の関係性を指示できる。 例えば、 次の~CSSは： ◎ But you can place the & in other locations within the nested selector, to indicate other types of relationships between the parent and child rule. For example, this CSS:
ul {
padding-left: 1em;
}
.component ul {
padding-left: 0;
}
入子ngを利用して，次のように書き直せる： ◎ Can be rewritten using Nesting as:
ul {
padding-left: 1em;
.component & {
padding-left: 0;
}
}
ここでも、 `&$css は， “それが，入子な選択子を置くよう求まれる所” とする仕方を与える。 ◎ Again, the & gives you a way to say “this is where I want the nested selector to go”.
それはまた、 選択子の合間に~space【すなわち、`子孫~結合子$】を挟みたくないときにも，手軽になる。 例えば、 次の~codeは： ◎ It’s also handy when you don’t want a space between your selectors. For example:
a {
color: blue;
&:hover {
color: lightblue;
}
}
`a:hover {^css と同じ結果を得る。 `&$css を伴わない場合、 `a :hover {^css （ `a^css と `:hover^css の合間に~spaceがある） と同じ結果になり， ~hover~linkを~styleするのに失敗することになる。 ◎ Such code yields the same result as a:hover {. Without the &, you’d get a :hover {—notice the space between a and :hover—which would fail to style your hover link.
すでに入子にされた~CSSの内側に~CSSを入子にするよう， 欲されるだけ何~層でも深く入子にできる。 入子法は、［ `容器~query＠~CSSCOND5#container-query$／ `~supports~query＠~CSSCOND#supports-queries$／ `媒体~query＠~MQ5#media-query$／ `~cascade層＠~CASCADE#cascade-layers$ ］とも併用できる。 （およそ）何でも他のものの内側に置ける。 ◎ You can nest more than one layer deep—nesting CSS inside already-nested CSS—in as many levels as you desire. You can mix Nesting with Container Queries, Supports Queries, Media Queries, and/or Cascade Layers however you want. (Nearly) anything can go inside of anything.
3. ~style規則の入子法
`~style規則$は、 他の~style規則の内側に入子にできる。 これらの `入子な~style規則@ は、 普通の~style規則と正確に同じ様に動作する — すなわち、 選択子を介して，要素に~prop群を結付ける — が、 それらは親~規則の選択子~文脈を “継承する” ことで，選択子を — 場合によっては複数回~繰返す必要なく — 親の選択子の上に更に築くことを許容する。 ◎ Style rules can be nested inside of other styles rules. These nested style rules 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.
`入子な~style規則$は、 `相対~選択子$を利用できることを除けば， 通常の~style規則と正確に同じ様になる — それは、 暗黙的に，親~規則に合致した要素から相対的になる。 ◎ A nested style rule is exactly like a normal style rule, except that it can use relative selectors, which are implicitly relative to the elements matched by the parent rule.
すなわち、 次の様な入子な~style規則は： ◎ That is, a nested style rule like:
.foo {
color: red;
a {
color: blue;
}
}
妥当であり， 次と等価になる： ◎ is valid, and equivalent to:
.foo {
color: red;
}
.foo a {
color: blue;
}
【 この事例では、 `a^css は`相対~選択子$であり， その先頭には暗黙な`子孫~結合子$が在ると見なされる。 】
入子にされた規則は、 `入子ng選択子$を利用して，親~規則に合致した要素も直に参照rできる。 ◎ 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".
.foo {
color: red;
&:hover {
color: blue;
}
}
/*
は、
次と等価になる：
◎
equivalent to
.foo { color: red; }
.foo:hover { color: blue; }
*/
入子にされた規則は、 `相対~選択子$の構文を利用して， “子孫” 以外の関係性も指定できる： ◎ ↑
.foo {
color: red;
+ .bar {
color: blue;
}
}
/*
は、
次と等価になる：
◎
equivalent to
.foo { color: red; }
.foo + .bar { color: blue; }
*/
3.1. 構文
`~style規則$の内容は、 既存の`宣言~群$dBに加えて，今や［ `入子な~style規則$, `~at-規則$ ］も受容する。 ◎ The contents of style rules now accepts nested style rules and at-rules, in addition to the existing declarations.
`入子な~style規則$は、 入子にされない規則とは，次に挙げる仕方で相違する： ◎ Nested style rules differ from non-nested rules in the following ways:
- `入子な~style規則$は、 その .導入部として `relative-selector-list$t を受容する （ `selector-list$t だけでなく）。 `相対~選択子$は、 `入子ng選択子$により表現される要素に相対的になる。 ◎ 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.
- `relative-selector-list$t を成す各~選択子のうち［ `結合子$から開始しないが，`入子ng選択子を包含して$いるもの ］は、 `相対~選択子$ではないものと解釈される。 ◎ 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.
入子な~style規則が どう構文解析されるかについての精確な詳細は、 `CSS-SYNTAX-3$r にて定義される。 ◎ The precise details of how nested style rules are parsed are defined in [CSS-SYNTAX-3].
【 入子にされた構成子は［ `宣言$, `~style規則$ ］どちらを開始しているのか紛らわしくもなり得るが （例： `color:hover ...^css は、［ 無効な値 `hover^v を伴う `color$p ~propの宣言, `color^e 要素~用の`型~選択子$から始まる規則 ］どちらに解釈するべきか？）、 まず宣言として構文解析するよう試行され， 失敗した場合は規則として構文解析される。 】
無効な`入子な~style規則$は、 その内容とともに無視されるが，その親~規則を無効~化することはない。 ◎ An invalid nested style rule is ignored, along with its contents, but does not invalidate its parent rule.
`相対~選択子$を伴う入子な規則は、 その暗黙な`入子ng選択子$の`詳細度$を含む。 例えば、 `.foo { > .bar {...}}^css の内縁~規則~用の詳細度は， `.foo { & > .bar {...}}^css のそれと同じになる。 ◎ Nested rules with relative selectors include the specificity of their implied nesting selector. For example, .foo { > .bar {...}} and .foo { & > .bar {...}} have the same specificity for their inner rule.
注記： ［ ~CSSを生成する~toolのうち，入子ngを処理するもの ］には、 作者が［ 選択子を文字列として連結して， 複数の入子ng~levelにまたがる 1 個の`単純-選択子$を築き上げる ］ことを許容するものもある。 これは，ときには、 【！ `https://en.wikipedia.org/wiki/CSS#:~:text=bem%20(block%2C%20element%2C%20modifier)^】 BEM の様に， 階層的な~patternを成す名前で利用されることもある — 当の選択子が内部的に何回も繰返されるとき、 その回数を抑制するためとして。 ◎ Some CSS-generating tools that preprocess nesting will concatenate selectors as strings, allowing authors to build up a single simple selector across nesting levels. This is sometimes used with hierarchical name patterns like BEM to reduce repetition across a file, when the selectors themselves have significant repetition internally.
例えば、 ある~componentが~class `.foo^css を利用していて， ある入子な~componentが~class `.fooBar^css を利用している場合、 `Sass＠https://sass-lang.com/$ においては，次のように書くこともできる： ◎ For example, if one component uses the class .foo, and a nested component uses .fooBar, you could write this in Sass as:
.foo {
color: blue;
&Bar { color: red; }
}
/*
は、
Sass においては，次と等価になる：
◎
In Sass, this is equivalent to
.foo { color: blue; }
.fooBar { color: red; }
*/
これは、 ~CSSにおいては許容されない — `入子ng選択子$【！nesting】は、 構文を変形するものではなく，親~選択子が実際に合致する要素に合致するので。 ◎ This is not allowed in CSS, as nesting is not a syntax transformation, but rather matches on the actual elements the parent selector matches.
そもそも，選択子 `&Bar^css は、 ~CSSにおいては妥当でない — `Bar^css が成す部分は、 `型~選択子$であり，`複合-選択子$においては最初に来なければならないので。 （すなわち、 `Bar&^css と書かれなければならない）。 なので、 この仕様の構文は，幸いにも当の前処理器【すなわち Sass 】の構文とは重合しない。 ◎ It is also true that the selector &Bar is invalid in CSS in the first place, as the Bar part is a type selector, which must come first in the compound selector. (That is, it must be written as Bar&.) So, luckily, there is no overlap between CSS Nesting and the preprocessor syntax.
`選択子$は、 次を満たすとき， `入子ng選択子を包含して@ いるとされる ⇒ `any type of^en 選択子として 【当の文脈に適切な種別の`選択子の文法＠~SELECTORS4#grammar$に則って】 `構文解析-＠~CSSSYN#css-parse-something-according-to-a-css-grammar$した結果、 次を満たす `delim-token$t に遭遇した ⇒ .値 ~EQ `&^l （ `0026^U `AMPERSAND^cn ） ◎ A selector is said to contain the nesting selector if, when it was parsed as any type of selector, a <delim-token> with the value "&" (U+0026 AMPERSAND) was encountered.
注記： これは、 `:is(:unknown(&), .bar)^css の様な事例 を捕えるため，この明示的な方式で句される。 この選択子には、 `&$css を包含する唯一の部分として，未知な選択子（ `unknown()^ps ）がある （未知なので、 その引数が選択子として構文解析されるよう`意味されたもの^emか否か，知る仕方は無い）。 この未知な選択子は、［ より新たな~browserにおいては、 完璧に妥当な選択子として~supportされる ］`ようになるかもしれず^em，［ 構文解析は、 無関係な~version付けの課題に依存しないことが求まれる ］ので、 依然として`入子ng選択子を包含して$いるものと扱われる。 ◎ Note: This is phrased in this explicit manner so as to catch cases like :is(:unknown(&), .bar), where an unknown selector (which, being unknown, we have no way of knowing whether the argument is meant to be parsed as a selector or not) is the only part of the selector that contains an &. As that might be a perfectly valid selector that’s only supported by newer browsers, and we don’t want parsing to be dependent on unrelated versioning issues, we treat it as still containing the nesting selector.
`forgiving-selector-list$t を成す~itemは、 `入子ng選択子を包含して$いるが`無効な選択子$であっても， 破棄されることなく正確にそのまま保全される。 （これは、 当の選択子を照合するときの挙動を変更しない — それでも、 無効な選択子に合致するものは無いが。 選択子の直列化だけが変更される。） ◎ If a <forgiving-selector-list> has an item that contains the nesting selector but is invalid, that item 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.)
前~段落は、 `&$css を `SELECTORS-4$r へ移動するに伴い，そこへ移動する必要がある。 これは，`~monkey~patch$であるが、 便利~用にここに与えている。 ◎ The preceding paragraph needs to move to Selectors when we move & itself to Selectors; I’m monkey-patching for convenience here.
3.2. 例
`&^css （`入子ng選択子$）は、 それだけでも選択子として利用できる： ◎ /* & can be used on its own */
.foo {
color: blue;
& > .bar { color: red; }
> .baz { color: green; }
}
/*
は、
次と等価になる：
◎
equivalent to
.foo { color: blue; }
.foo > .bar { color: red; }
.foo > .baz { color: green; }
*/
`複合-選択子$における `&^css は、 親の選択子を精緻化する： ◎ /* or in a compound selector, refining the parent’s selector */
.foo {
color: blue;
&.bar { color: red; }
}
/*
は、
次と等価になる：
◎
equivalent to
.foo { color: blue; }
.foo.bar { color: red; }
*/
選択子~listを成す各~選択子は、 どれも，親に相対的になる： ◎ /* multiple selectors in the list are all relative to the parent */
.foo, .bar {
color: blue;
+ .baz, &.qux { color: red; }
}
/*
は、
次と等価になる：
◎
equivalent to
.foo, .bar { color: blue; }
:is(.foo, .bar) + .baz,
:is(.foo, .bar).qux { color: red; }
*/
`&^css は、 単独の選択子~内で複数回~利用できる： ◎ /* & can be used multiple times in a single selector */
.foo {
color: blue;
& .bar & .baz & .qux { color: red; }
}
/*
は、
次と等価になる：
◎
equivalent to
.foo { color: blue; }
.foo .bar .foo .baz .foo .qux { color: red; }
*/
`&^css は、 選択子の先頭に置く必要はない： ◎ /* & doesn’t have to be at the beginning of the selector */
.foo {
color: red;
.parent & {
color: blue;
}
}
/*
は、
次と等価になる：
◎
equivalent to
.foo { color: red; }
.parent .foo { color: blue; }
*/
【`&^css は、選択子とる引数にも利用できる：】
.foo {
color: red;
:not(&) {
color: blue;
}
}
/*
は、
次と等価になる：
◎
equivalent to
.foo { color: red; }
:not(.foo) { color: blue; }
*/
`相対~選択子$を利用した場合、 先頭の `&^css が自動的に含意される： ◎ /* But if you use a relative selector, an initial & is implied automatically */
.foo {
color: red;
+ .bar + & { color: blue; }
}
/*
は、
次と等価になる：
◎
equivalent to
.foo { color: red; }
.foo + .bar + .foo { color: blue; }
*/
いくぶん役立たずに見えるが、 `&^css だけでも利用できる： ◎ /* Somewhat silly, but & can be used all on its own, as well. */
.foo {
color: blue;
& { padding: 2ch; }
}
/*
は、
次と等価になる：
◎
equivalent to
.foo { color: blue; }
.foo { padding: 2ch; }
// あるいは次とも
◎
// or
.foo {
color: blue;
padding: 2ch;
}
*/
これも役立たずに見えるが、 `&^css を二重にすることもできる： ◎ /* Again, silly, but can even be doubled up. */
.foo {
color: blue;
&& { padding: 2ch; }
}
/*
は、
次と等価になる：
◎
equivalent to
.foo { color: blue; }
.foo.foo { padding: 2ch; }
*/
親~選択子は、 任意に複雑にできる： ◎ /* The parent selector can be arbitrarily complicated */
.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; }
*/
入子な選択子も、 任意に複雑にできる： ◎ /* As can the nested selector */
.foo {
& :is(.bar, &.baz) { color: red; }
}
/*
は、
次と等価になる：
◎
equivalent to
.foo :is(.bar, .foo.baz) { color: red; }
*/
選択子を複数~levelに入子にして “積み上げる” ： ◎ /* Multiple levels of nesting "stack up" the selectors */
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; }
*/
~cascade層（ `layer$at ）と併用する例： ◎ /* Example usage with Cascade Layers */
@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%; }
}
*/
~cascade層を入子にする例： ◎ /* Example nesting Cascade Layers */
@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%; }
}
*/
視野~付き（ `scope$at ）と併用する例： ◎ /* Example usage with Scoping */
@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; }
}
*/
視野~付きを入子にする例： ◎ /* Example nesting Scoping */
.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; }
}
*/
3.3. 他の~at-規則の入子法
`入子な~style規則$に加えて、 この仕様は，`~style規則$の内側に `入子な~group規則@ も許容する ⇒ ~at-規則のうち，その本体が`~style規則$を包含し得るものは、 他の`~style規則$の内側に入子にできる。 ◎ In addition to nested style rules, this specification allows nested group rules inside of style rules: any at-rule whose body contains style rules can be nested inside of a style rule as well.
`入子な~group規則$が，この仕方で入子にされたときは、 当の規則の内容は、 `rule-list$t としてではなく， `block-contents$t として構文解析される： ◎ When nested in this way, the contents of a nested group rule’s block are parsed as <block-contents> rather than <rule-list>:
- 【本体~内の】各`~style規則$は、 `入子な~style規則$になり， その`入子ng選択子$の定義を最も近い先祖の`~style規則$からとる。 ◎ Style rules are nested style rules, with their nesting selector taking its definition from the nearest ancestor style rule.
- ~prop【宣言】は、 直に利用でき，`入子な宣言~列が成す規則$内に入子にされたかのように動作する。 ◎ Properties can be directly used, acting as if they were nested in a nested declarations rule.
注記： 特定的に，次に挙げる規則は、 `入子な~group規則$になる能力がある ⇒＃ すべての`条件付き~group規則$（ `container$at, `media$at, `supports$at ）, `layer$at, `scope$at ◎ Specifically, these rules are capable of being nested group rules: • all the conditional group rules (@container, @media, @supports) • @layer • @scope
そのような`入子な~group規則$の意味と挙動は、 他においては，他が指定されない限り変化しない。 ◎ The meanings and behavior of such nested group rules is otherwise unchanged, unless otherwise specified.
例えば、 以下に挙げる条件付き規則の入子ngは，妥当になる。 ◎ For example, the following conditional nestings are valid:
~propは直に利用できる： ◎ /* Properties can be directly used */
.foo {
display: grid;
@media (orientation: landscape) {
grid-auto-flow: column;
}
}
/*
は、
次と等価になる：
◎
equivalent to
*/
.foo {
display: grid;
}
@media (orientation: landscape) {
.foo {
grid-auto-flow: column;
}
}
/* and also equivalent to the unnested: */
.foo { display: grid; }
@media (orientation: landscape) {
.foo {
grid-auto-flow: column;
}
}
条件付きも更に入子にできる： ◎ /* Conditionals can be further nested */
.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;
}
}
~cascade層（ `layer$at ）を入子にする例： ◎ /* Example nesting Cascade Layers */
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%; }
}
視野~付き（ `scope$at ）を入子にする例： ◎ /* Example nesting Scoping */
.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; }
}
直に入子にされた各［ 連続する~propたち ］は、 `入子な宣言~列が成す規則$内に自動的に包装される （これは、 ~CSSOMにおいて観測-可能になる）。 ◎ Runs of consecutive directly-nested properties are automatically wrapped in nested declarations rules. (This is observable in the CSSOM.)
3.3.1. 入子な `scope^at 規則
所与の `scope$at 規則 %規則 に対し， %規則 が`入子な~group規則$を成すときは、 %規則 の `scope-start$t における `&$css 選択子は，最も近い先祖~style規則に合致した要素を参照rする。 ◎ 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.
すなわち、 次の~codeは： ◎ 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 (:where(:scope) .limit) {
:where(:scope) .content {
color: red;
}
}
注記： `scope$at 規則~内の `&$css 選択子は、 `:where(:scope)^css の様に挙動する。 ◎ The & selector behaves like :where(:scope) in @scope rules.
3.4. 入子ng規則と宣言の混合-法
~style規則が［ 宣言, ［ `入子な~style規則$／`入子な~group規則$ ］］両者を包含するときでも， これら 3 種すべてを任意に混合できる。 ［ すべての規則より後／規則たちの合間 ］にある各［ 一連の宣言 ］は、 他の規則との相対的な順序を保全するため， 暗黙的に`入子な宣言~列が成す規則$内に包装される。 ◎ When a style rule contains both declarations and nested style rules or nested group rules, all three can be arbitrarily mixed. Declarations coming after or between rules are implicitly wrapped in nested declarations rules, to preserve their order relative to the other rules.
例えば、 次の~codeでは： ◎ For example, in the following code:
article {
color: green;
& { color: blue; }
color: red;
}
/*
は、
次と等価になる：
◎
equivalent to
*/
article { color: green; }
:is(article) { color: blue; }
article { color: red; }
/*
が、
次と等価にはならない：
◎
NOT equivalent to
*/
article { color: green; }
article { color: red; }
:is(article) { color: blue; }
`出現順序$を決定する目的においては、［ `入子な~style規則$／`入子な~group規則$ ］は，その親~規則より`後^emに来るものと見なされる。 ◎ For the purpose of determining the Order Of Appearance, nested style rules and nested group rules are considered to come after their parent rule.
例えば： ◎ For example:
article {
color: blue;
& { color: red; }
}
両~宣言とも，その詳細度は同じ (0,0,1) になるが、 入子な規則は親~規則より`後に来る^emものと見なされるので， 宣言 `color: red^css の方が~cascadeにおいて優先される。 ◎ 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:
article {
color: blue;
:where(&) { color: red; }
}
`where()$ps 疑似類により`入子ng選択子$の詳細度は 0 に抑制されるので， 宣言 `color: red^css の詳細度は (0,0,0) になり、 `出現順序$が考慮される前に， 宣言 `color: blue^css の方が優先される。 ◎ 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.
注記： 宣言と入子な規則は，混ぜ合わせても`かまわない^emが、 そうすると，いくぶん［ 読み難く／紛らわしく ］なる — 後にある~prop【入子な規則より後にある宣言たち】は、［ ~source~text内には現れない`入子な宣言~列が成す規則$ ］内に自動的に包装されるので。 可読性を高めるため、 作者には，［ ~style規則~内の~propすべてを入子な規則より前に置く ］ことが推奨される。 （そうすれば、 入子な規則を~supportしない~UAにおいても，少し良く動作することになろう — 入子な規則より後に現れている~propは、 構文解析と~error回復に特有な働きに因り，飛ばせるようになるので。） ◎ Note: While one can freely intermix declarations and nested rules, it’s harder to read and somewhat confusing to do so, since the later properties are automatically wrapped in a nested declarations rule that doesn’t appear in the source text. 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.)
4. 入子ng選択子： `&^css 選択子
`入子な~style規則$を利用するときには、 親~規則に合致した要素を参照r可能にする必要がある【！must】。 それこそが，`入子法の要^em を成す。 これを成遂げるため、 この仕様は， `&@css （ `0026^U `AMPERSAND^cn ）として記される新たな選択子として `入子ng選択子@ （ `nesting selector^en ）を定義する。 ◎ 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).
`入子ng選択子$は、 `入子な~style規則$の選択子~内で利用されたときは，親~規則に合致した要素を表現する。 他の文脈~内で利用されたときは†、 その文脈において `scope$ps に合致する【！the same】要素を表現する （他が指定されない限り）。 ◎ 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).
【† したがって、 ~top-level（入子にされない文脈）でも利用できることになる （通例的には有用にならないであろうが）。 】
注記： `入子ng選択子$による糖衣は、 それを［ 親~style規則の選択子を `is()$ps 選択子で包装したもの ］に置換することより外せる（ `desugar^en できる）。 例えば： ◎ 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; }
`入子ng選択子$は、 疑似要素を表現し得ない （ `is()$ps 疑似類の挙動に一致する）。 ◎ The nesting selector cannot represent pseudo-elements (identical to the behavior of the :is() pseudo-class).
例えば、 次の~style規則においては： ◎ For example, in the following style rule:
.foo, .foo::before, .foo::after {
color: red;
&:hover { color: blue; }
}
`&$css は， `.foo^css に合致した要素に限り表現する — 言い換えれば，次と等価になる： ◎ 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;
}
この制約は緩めたいが、［ `is()$ps, `&$css ］両者に対し同時に行う必要がある — それらは、 意図的に，同じ下層の仕組みの上に築かれるので。 （ `7433$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. (Issue 7433)
`入子ng選択子$の`詳細度$は、［ 親~style規則の`選択子~list$を成す各`複階-選択子$の`詳細度$ ］のうち最も高いものに等しい（ `is()$ps の挙動と一致する） — そのような選択子~listは存在しない場合、 ( 0, 0, 0 ) になるとする。 ◎ The specificity of the nesting selector is equal to the largest specificity among the complex selectors in the parent style rule’s selector list (identical to the behavior of :is()), or zero if no such selector list exists.
例えば，次の~style規則が与えられたなら： ◎ For example, given the following style rules:
#a, b {
& c { color: blue; }
}
.foo c { color: red; }
次の様な~DOM構造においては： ◎ Then in a DOM structure like
<b class=foo> <c>Blue text</c> </b>
~textの色は、 `red^v ではなく `blue^v になる。 `&$css の詳細度は［ `#a^css の詳細度 (1,0,0), `b^css の詳細度 (0,0,1) ］のうち高い方 (1,0,0) になるので、 選択子~全体 `& c^css の詳細度は (1,0,1) になる, — それは `.foo c^css の詳細度 (0,1,1) より高い。 ◎ 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]).
これは、［ 入子ngを外して，入子にされない規則に手動で展開した場合に得られる結果 ］とは`異なる^emことに注意。 そうした場合、 宣言 `color: blue^css は、 詳細度 (1,0,1) を伴う選択子 `#a c^css ではなく， 詳細度 (0,0,2) を伴う選択子 `b c^css に合致するので。 ◎ 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?
`入子ng選択子$の詳細度は、 意図的に， `is()$ps 疑似類と同じ規則を利用するようにしてある。 それは、 各~引数の中で最も高い詳細度を利用するだけであり， 実際に合致した選択子が`どれなのか^emを追跡しない。 ◎ 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.
ではなぜ `&$css を `is()$ps の用語で定義するのか？ 一部の非~browserによる［ 入子法の様な機能性 ］の実装は、 その多くが `is()^ps の導入~以前からあることもあって， その糖衣を — `is()^ps を通して外すことなく — 直に外す。 しかしながら，これには`有意な問題^emがついて来る — 一部の（適度に共通的な）事例では、 指数関数的な爆発のアリ性に因り，不用意に`膨大^emな選択子を生産し得るので。 ◎ 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, .b2, .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 {...}
ここには、 入子ng~levelが 3 つあり， 各~levelは 3 個の選択子からなる~listを伴う — 糖衣を外した結果， 27 個の選択子が生産される。 ［ ~listに もっと選択子を追加する／ もっと入子ng~levelを追加する／ 入子な規則をもっと複階的にする ］ことで，［ 何~megabyteもの（あるいは，それを遥かに超える）選択子に展開される ］ような比較的~短い規則を作れる。 ◎ 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!).
一部の~CSS~toolは、 一部の~variationを経験的に破棄することにより，この最悪な~~事態を避ける — なので、 それほど多量に出力せずとも，`おそらく^em正しいものになろう【？】。 が、 それは~UAに可用な~optionではない。 ◎ 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.
この問題は、 代わりに `is()$ps を通して糖衣を外すことで解消される — それは、 詳細度の有用さを少し減らす~costを伴うが，適度な~trade-offと判定された。 ◎ Desugaring with :is() instead eliminates this problem entirely, at the cost of making specificity slightly less useful, which was judged a reasonable trade-off.
`入子ng選択子$は、 `無特能$な要素に合致する能力がある — そのような要素が親~規則に合致した場合には。 ◎ The nesting selector is capable of matching featureless elements, if they were matched by the parent rule.
`複合-選択子$内では，`入子ng選択子$が どこに位置しようが挙動における相違は無いが （すなわち、 `&.foo^css と `.foo&^css は同じ要素たちに合致する）、 それでも，［ `複合-選択子$内に`型~選択子$が在る場合、 それは最初に来なければならない ］とする既存の規則は適用される （すなわち、 `&div^css は違法であり， 代わりに `div&^css と書かれなければならない）。 ◎ 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).
5. 入子な宣言~列が成す規則
いくぶん技術的な理由から、 ~style規則の内容において，~prop宣言のうち［ 頭部に来るもの（先行する規則が無いもの）, 他のもの ］を判別-可能になることが重要になる。 ◎ For somewhat-technical reasons, it’s important to be able to distinguish properties that appear at the start of a style rule’s contents from those that appear interspersed with other rules.
例えば，次において： ◎ For example, in the following two rules:
.foo {
color: red;
@media (...) {...}
background: blue;
}
宣言【！規則】 `color:red$p と 宣言【！規則】 `background:blue$p に対する扱いは，少し違える必要がある。 特に，~CSSOMにおいては、 `color:red^p は~style規則の `style$m 属性~内に公開される一方で， `background:blue^p は~style規則の `childRules＠~CSSOM1#dom-cssgroupingrule-cssrules$c ~list内に~~現れる必要がある。 ◎ We need to treat the color: red and background: blue slightly differently. In particular, in the CSSOM, the color: red is exposed in the style rule’s style attribute, while the background: blue needs to instead show up in its cssRules list.
これを成遂げるため、 ~CSS構文解析は，［ 後者の~propたちを包含するための特別な子~規則 ］内に`自動的に^em包装する。 しかしながら、 それらを `&$css 選択子を伴う`~style規則$内に包装した場合， いくぶん~~不都合な挙動になる： ◎ To accomplish this, CSS parsing automatically wraps such properties in a special child rule to contain them. However, if we were to wrap them in a style rule with an & selector, it would have somewhat unfortunate behavior:
例えば，次においては： ◎ For example, in
.foo, .foo::before {
color: red;
& {
background: blue;
}
}
入子な規則は、 疑似要素【！要素】 `.foo::before^css に対しては `background$p ~propを`適用しない^em — `&$css は、 疑似要素を表現できないので。 ◎ the nested rule does not apply the background property to the .foo::before elements, because the & can’t represent pseudo-elements.
類似に，入子な非-~style規則~内の子~宣言たちは、 何らかの仕方で`規則$として公開される必要がある — それらに類する（ `media$at の様な）規則は、 `style$m ~prop【すなわち`宣言$たち】を決して有さないので。 これらにも、 上と同じ問題が生じる。 ◎ Similarly, child declarations in nested non-style rules need to be exposed as rules in some way, because these sorts of rules (like @media) have never had style properties. These run into the same problems as above.
これらすべての課題に取組むため、 直に入子にされた［ 連続する~propたちが成す連なり ］は， `入子な宣言~列が成す規則@ 内に包装される。 ◎ To address all of these issue, we instead wrap runs of consecutive directly-nested properties in a nested declarations rule.
他が指定されない限り、 `入子な宣言~列が成す規則$は`入子な~style規則$であり， 他の~style規則と同じに動作する。 それは、 その親~style規則と正確に同じ［ 要素, 疑似要素 ］たちに合致し，詳細度の挙動も同じになる。 （これは、 `&$css 選択子を伴う~style規則に`類似する^emが、 上で説明したとおり，もう少し強力である。） ◎ Unless otherwise specified, a nested declarations rule is a nested style rule, and acts identically to any other style rule. It matches the exact same elements and pseudo-elements as its parent style rule, with the same specificity behavior. (This is similar to being a style rule with an & selector, but slightly more powerful, as explained above.)
なぜ`入子な宣言~列が成す規則$が存在するのか？ ◎ Why does the nested declarations rule exist?
この仕様は、 元々は~style規則~内のすべての宣言を一緒に~group化していた — それらが［ 元の所在から規則~内の頭部（他の規則より前）へ “移動され” ていた ］かのように動作するよう。 また、［ `入子な~group規則$の内側にある生な宣言たち ］を`入子ng選択子$を利用して，素な~style規則~内に自動的に包装していた — `& {...}^css の様に。 ◎ Originally, this specification grouped all declarations in style rules together, "moving" them from their original location to act as if they were placed at the front of the rule. It also automatically wrapped raw declarations inside of nested group rules in plain style rules, using the & selector.
代わりに`入子な宣言~列が成す規則$を利用するよう切替えた理由は、 主に 2 つある： ◎ There are two major reasons we switched to instead use the nested declarations rule.
- 宣言たちを［ `入子ng選択子$を利用して暗黙的に`入子な~group規則$内に包装する ］と，それらの挙動も変化する。 それは，親~style規則が疑似要素を包含する事例を — この注記に後続する例に示されるとおり — 非互換化することに加え、 そうでない事例でも，入子な宣言~用の詳細度の挙動は変化し得る。 `入子な宣言~列が成す規則$へ切替えることは、 これらの問題を避けて， `media$at 等々の挙動を入子にされたとき, されないときとで一致させる。 ◎ First, using an & {...} rule to implicitly wrap declarations in a nested group rule also changed the behavior. As shown in the example following this note, it breaks cases where the parent style rule contains pseudo-elements, and even when that’s not the case, it potentially changes the specificity behavior of the nested declarations. Switching to the nested declarations rule avoids these problems, making the behavior of nested @media/etc identical to the behavior of *non*-nested @media/etc.
- 将来の~CSS特能（特に， “~mixin” ）には、［ 差挟まれた宣言たちが当の~style規則~内で他の規則より前へ自動的に移動されると， 単純に正しく働かなくなる ］ような何らかの詳細がある。 それらは，他の規則との相対的な順序を保つ必要があり、 それらを~CSSOM内で実際に表現-可能にするためにも， 何らかの種類の規則で包装する必要がある — が，通常の `& {...}^css 規則だけ利用した場合、 前~段落と同じ課題が適用される。 `入子な宣言~列が成す規則$は、 副作用を伴うことなく，それを可能にする。 ◎ Second, there are some details of future CSS features (notably, "mixins") that simply won’t work correctly if interleaved declarations are automatically moved to the front of the style rule. We need to keep their relative order with other rules, and in order to actually make that representable in the CSSOM, that means they have to be wrapped in some kind of rule. The same issues as the previous paragraph apply if we just use a normal & {...} rule, so the nested declarations rule lets us do so without side effects.
例えば，次の~stylesheet片は： ◎ For example, in the following stylesheet snippet:
.foo, .foo::before, .foo::after {
color: black;
@media (prefers-color-scheme: dark) {
& {
color: white;
}
}
}
~pageが “暗な~mode” 下にあるときは、 `.foo^css 要素の~text色を `white^v へ変更するが，［ `before$pe, `after$pe ］疑似要素のそれは `black^v であり続ける — `&$css 選択子は、 疑似要素を表現できないので。 ◎ In a darkmode page, the .foo element would have its text color changed to white, but its ::before and ::after pseudos would remain black, because the & selector can’t represent pseudo-elements.
しかしながら、 代わりに次のように書かれたなら： ◎ However, it was instead written as:
.foo, .foo::before, .foo::after {
color: black;
@media (prefers-color-scheme: dark) {
color: white;
}
}
`color:white$p は`入子な宣言~列が成す規則$内に暗黙的に包装され， 親~style規則と`正確に^em同じ対象に合致することが保証されるので、 要素, 疑似要素`どちらも^em， その~text色は “暗な~mode” においては `white^v になる。 ◎ Then the color: white is implicitly wrapped in a nested declarations rule, which is guaranteed to match exactly the same as its parent style rule, so the element and its pseudo-elements would all have white text in a darkmode page.
規則たちに差挟まれた宣言たちは、 `入子な宣言~列が成す規則$内に暗黙的に包装されるようになり， それらが別々な~style規則の一部を成すようにする。 例えば、 次の~CSSが与えられたなら： ◎ Declarations interleaved with rules get implicitly wrapped in a nested declarations rule, which makes them part of a separate style rule. For example, given this CSS:
.foo {
color: black;
@media (...) {...}
background: silver;
}
`.foo^css 規則を表現する~CSSOM~obj %fooRule が精査されたとき、 %fooRule.`style$m は，宣言 `color:black$p のみを包含することになる。 ◎ If the .foo rule’s CSSOM object is examined, its style attribute will contain only one declaration: the color: black one.
宣言 `background:silver$p は、 代わりに， 暗黙的に作成された`入子な宣言~列が成す規則$内で — %fooRule.`cssRules[1].style^c にて — 見出されるようになる。 ◎ The background: silver declaration will instead be found in the implicitly-created nested declarations child rule, at fooRule.cssRules[1].style.
6. ~CSSOM
注記： `CSSOM-1$r は、 今や， `CSSStyleRule$I は子~規則を有せるものと定義する。 ◎ Note: [CSSOM-1] now defines that CSSStyleRule can have child rules.
`入子な~style規則$内の`相対~選択子$を直列化するときは、 当の選択子に暗黙な`入子ng選択子$を挿入して絶対~化するモノトスル。 ◎ When serializing a relative selector in a nested style rule, the selector must be absolutized, with the implied nesting selector inserted.
例えば，選択子 `> .foo^css は、 `& > .foo^css として直列化されることになる。 ◎ For example, the selector > .foo will serialize as & > .foo.
6.1. `CSSNestedDeclarations^I ~interface
`CSSNestedDeclarations$I ~interfaceは、 ある`入子な宣言~列が成す規則$を表現する。 ◎ The CSSNestedDeclarations interface represents a nested declarations rule.
[`Exposed$=Window]
interface `CSSNestedDeclarations@I : `CSSRule$I {
[`SameObject$, `PutForwards$=cssText] readonly attribute `CSSStyleProperties$I `style$m1;
};
`style@m1 取得子~手続きは ⇒ ~RET コレが表現する`入子な宣言~列が成す規則$用の［ 次を伴う`~CSS宣言~block$ ］を表現する `CSSStyleProperties$I ~obj ⇒＃ `算出-済みか$dB ~SET ~F, `読専か$dB ~SET ~F, `宣言~群$dB ~SET 当の規則~内に宣言された`指定d順$による宣言たち, `親~CSS規則$dB ~SET コレ, `所有者~node$dB ~SET ~NULL ◎ The style attribute must return a CSSStyleProperties object for the rule, with the following properties: ◎ computed flag • Unset readonly flag • Unset declarations • The declared declarations in the rule, in specified order. parent CSS rule • this owner node • Null
`CSSNestedDeclarations$I 規則は、 その`~CSS宣言~block$が直に`直列化された＠~CSSOM1#serialize-a-css-declaration-block$かのように`直列化される＠~CSSOM1#serialize-a-css-rule$。 ◎ The CSSNestedDeclarations rule serializes as if its declaration block had been serialized directly.
注記： このことは、 隣接な複数個の`入子な宣言~列が成す規則$ （それは、 例えば `insertRule()＠~CSSOM1#dom-cssgroupingrule-insertrule$c で作成することがアリである） は、 直列化されてから再び構文解析されたとき， 1 個の規則の中へ縮約されるようになることを意味する。 ◎ Note: This means that multiple adjacent nested declarations rules (which is possible to create with e.g. insertRule) will collapse into a single rule when serialized and parsed again.
変更点
- `2023年 2月 14日 作業草案＠~TR/2023/WD-css-nesting-1-20230214/$ からの有意な変更点： ◎ Significant changes since the Feb 14, 2023 Working Draft:
- `scope$at 規則を成す `scope-start$t 選択子は、 もはや入子ng用の親~規則として動作しなくなった。 （ `9740$issue ） ◎ The <scope-start> selector of a @scope rule no longer acts as the parent rule for nesting. (Issue 9740)
- `入子ng選択子$は［ `無特能$な要素に合致することも許容される ］ことを明確化した。 ◎ Clarified that the nesting selector is allowed to match featureless elements.
- `&div^css のような選択子は無効になるよう切替えた — 今や `CSS-SYNTAX-3$r が “無限な先読み” を行うので、 それを許容する必要は，もはやなくなった。 また、 そうすることで前処理器との衝突も避けられる。 （ `8662$issue ） ◎ Switched &div back to being invalid; now that Syntax does "infinite lookahead", we no longer need to allow it. Plus, doing so avoids a clash with preprocessors. (Issue 8662)
- ~CSSOMは，今や `CSSStyleRule$I を `CSSGroupingRule$I の下位classとして定義するので、 `cssRules^m 属性と関係する機構を成す手動な定義を除去した。 （ `8940$issue ） ◎ CSSOM now defines that CSSStyleRule is a CSSGroupingRule subclass, so the manual definition of the cssRules attribute and related machinery was removed. (Issue 8940)
- 入子ng選択子による詳細度に対する`暗黙な^em効果を明確化した。 （ `9069$issue ） ◎ Clarified the effect of the implied nesting selector on specificity. (Issue 9069)
- 規則と混ぜ合わされた宣言（および，入子な~group規則~内のすべての宣言）は、 自動的に `nest^at 規則~内に包装されるようにした （それに伴い， `nest^at 規則も追加した）。 （ `8738$issue ） ◎ Declarations intermixed with rules (or all declarations in nested group rules) are now automatically wrapped in @nest rules. (Also the @nest rule was added.) (Issue 8738)
- `nest^at を`入子な宣言~列が成す規則$に置換した。 （ `10234$issue ） ◎ Replaced @nest with nested declarations rules. (Issue 10234)