`入子な~style規則$は、 -その`選択子$が［ -`~CSS識別子$／`関数-記法$ -］から開始し得ないことを除けば， -通常の~style規則と正確に同じ様になる。 -加えて、 -`入子な~style規則$には，`相対~選択子$を利用できる。 +`相対~選択子$を利用できることを除けば， +通常の~style規則と正確に同じ様になる +— それは、 +暗黙的に，親~規則に合致した要素から相対的になる。 ◎ -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. +A nested style rule is exactly like a normal style rule, except that it can use can use relative selectors, which are implicitly relative to the elements matched by the parent rule.
【 +この事例では、 +`a^css は`相対~選択子$であり， +その先頭には暗黙の`子孫~結合子$が在ると見なされる。 +】
+入子にされた規則は、［ `入子ng選択子$を利用して， @@ -798,131 +788,6 @@
-しかしながら、 -入子な選択子が識別子から開始している場合（言い換えれば、`型~選択子$），妥当でない： -◎ -However, starting the nested selector with an identifier (a type selector, in other words) is invalid: -
- -
-div {
- color: red;
-
- input {
- margin: 1em;
- }
-}
-/*
-`input^css は識別子なので，妥当でない。
-◎
-Invalid, because "input" is an identifier.
- */
-
-
--そのような選択子でも、 -少し書き方を違えるだけで可能になる： -◎ -Such selectors can still be written, they just need to be slightly rephrased: -
- -
-div {
- color: red;
-
- & input { margin: 1em; }
- /*
-妥当になる
-— もはや，識別子から開始していないので。
-◎
-valid, no longer starts with an identifier
- */
-
- :is(input) { margin: 1em; }
- /*
-~colonから開始しているので、
-妥当になり，上の規則と等価になる。
-◎
-valid, starts with a colon, and equivalent to the previous rule.
- */
-}
-
--あいにく，素朴に［ -`~style規則$の内側に別の~style規則を入子にする -］だけでは、 -多義的になる。 -選択子の構文【 `selector-list$t 】と宣言の構文【 `declaration-list$t 】は重合するので、 -所与の~text片が［ -宣言，ある~style規則の開始 -］どちらなのか明らかにするため，実装には際限ない先読みが要求される。 -◎ -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. -
- --例えば，ある構文解析器に対する~~入力が -`color:hover ...^css から開始している場合、 -それが［ -`color$p ~prop（無効な値 `hover^v に設定されている）, -`color^e 要素~用の選択子 -］どちらなのかは明らかにならない。 -この相違を［ -妥当な~propを成すかどうか調べることで明らかにする -］ことにさえ依拠できない -— そうすると、 -構文解析は［ -実装が どの~prop【あるいは，~propのどの値】を~supportするか -］に依存するようになり，時を経れば変化し得ることにもなる。 -◎ -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 <color> 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. -
- --この問題は、 -入子な~style規則が`~CSS識別子$から開始するのを禁止することで対処される -— 識別子から開始する`宣言$【！`宣言~群$】は，どれも~prop名を与えるので、 -構文解析器にとっては［ -`宣言$, `~style規則$ -］どちらを構文解析しているかは即時に明らかになる。 -◎ -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. -
- --一部の非~browserによる入子な規則の実装は、 -この要件を課さない。 -~propと選択子の~~分別を明らかにすることは、 -ほとんどの事例では`最終的^emにはアリだが， -そのためには構文解析器に際限ない先読みが要求される。 -すなわち，構文解析器は、［ -どちらの仕方で解釈するよう想定されているか明らかになる -］まで，未知な量の内容を保持する必要も生じ得る。 -これまでの~CSSは，［ -より効率的な構文解析~algoを許容する -］よう［ -構文解析において，既知な わずかな量の先読みしか要求していない -］ので、 -際限ない先読みは，一般に［ -~browserによる~CSSの実装においては、 -受容-可能でない -］と見なされる。 -◎ -Some non-browser implementations of nested rules do not impose this requirement. It is, in most cases, eventually 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. -
-入子な~style規則が どう構文解析されるかについての精確な詳細は、 -`CSS-SYNTAX-3$r にて定義される。 +`CSS-SYNTAX-3$r にて定義される†。 ◎ The precise details of how nested style rules are parsed are defined in [CSS-SYNTAX-3].
--~CSS~WGは、 -現在，構文解析における先読みによる帰結を探究している -— その結果として、 -許容される構文は調整され得る。 -`7961$issue -◎ -The CSSWG is currently exploring the consequences of parsing lookahead, and may adjust the allowed syntax as a result. [Issue #7961] -
+【† +現在のそれは、 +この仕様の更新（ `8662$issue ）をまだ反映していない。 +】【 +入子にされた構成子は［ +`宣言$, `~style規則$ +］どちらを開始しているのか紛らわしくもなり得るが +（例： `color:hover ...^css は、［ +無効な値 `hover^v を伴う `color$p ~propの宣言, +`color^e 要素~用の選択子を伴う規則 +］どちらに解釈するべきか？）、 +まず宣言として構文解析するよう試行され， +失敗した場合は規則として構文解析されることになるようだ +（ `7961$issue の`この~comment＠~CSSissue/7961#issuecomment-1489883575$ ）。 +】
無効な`入子な~style規則$は、 @@ -1302,7 +1165,7 @@
-一方で、 -以下に挙げるものは，妥当でない： -◎ -But these are not valid: -
- -
-/*
-識別子から開始している入子な選択子：
-◎
-Selector starts with an identifier
- */
-.foo {
- color: blue;
- div {
- color: red;
- }
-}
-
-あいにく、 -この［ -文字列に基づく解釈 -］は，作者が［ -当の入子な規則~内に`型~選択子$を追加しようと試みる -］とき多義的になる。 -例えば `Bar^css は、 -~HTMLにおける妥当な`~custom要素~名＠~HEcustom$`である^em†。 -【† `妥当な~custom要素~名＠~HEcustom#valid-custom-element-name$の構文に合致していないが、いずれにせよ，未知な要素の名前として解釈されよう。】 +これは、 +~CSSにおいては許容されない +— `入子ng選択子$【！nesting】は、 +構文を変形するものではなく，親~選択子が実際に合致する要素に合致するので。 ◎ -Unfortunately, this string-based interpretation is ambiguous with the author attempting to add a type selector in the nested rule. Bar, for example, is a valid custom element name in HTML. +This is not allowed in CSS, as nesting is not a syntax transformation, but rather matches on the actual elements the parent selector matches.
-~CSSは、 -これを行わない -— 入子な選択子~成分は、 -不可分に解釈され，文字列のように連結されない： +そもそも，選択子 `&Bar^css は、 +~CSSにおいては妥当でない +— `Bar^css が成す部分は、 +`型~選択子$であり，`合体~選択子$においては最初に来なければならないので。 +（すなわち、 +`Bar&^css と書かれなければならない）。 +なので、 +この仕様の構文は，幸いにも当の前処理器【すなわち Sass 】の構文とは重合しない。 ◎ -CSS doesn’t do this: the nested selector components are interpreted atomically, and not string-concatenated: +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.
- -
-.foo {
- color: blue;
- &Bar { color: red; }
-}
-/*
-は、
-~CSSにおいては，
-代わりに次と等価になる：
-◎
-In CSS, this is instead equivalent to
-
- .foo { color: blue; }
- Bar.foo { color: red; }
-*/
-
注記： +この挙動は、［ +多くの既存の前処理器に基づく入子法の挙動と合致する +］ことに加え，［ +既存の `CSSStyleRule$I ~objに対し，大幅な変更を要求することなく、 +規則を~CSSOM内で忠実に表出できる +］ことを確保する。 +◎ +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. +
+注記： 宣言と入子な規則は，混ぜこぜにしても`かまわない^emが、 そうすると，いくぶん［ 読み難く／紛らわしく ］なる -— すべての~propは、 +— すべての~prop【宣言】は、 すべての規則より前に来た`かのように動作する^emので。 可読性を高めるため、 作者には，［ @@ -2046,7 +1881,7 @@
-`入子ng選択子$は、 -`合体~選択子$内のどこでも許容される -— ［ -`合体~選択子$の中の順序付けに対する通常の制約 -］に違反することになる，`型~選択子$の前であっても。 -◎ -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. -
- --例えば， `&div^css は、 -次を意味する妥当な入子ng選択子である -⇒ -“何であれ，親~規則が合致するものに -— それが `div^e 要素でもある場合に限り — -合致する” +`合体~選択子$内では，`入子ng選択子$が どこに位置しようが挙動における相違は無いが +（すなわち、 +`&.foo^css と `.foo&^css は同じ要素たちに合致する）、 +それでも，［ +`合体~選択子$内に`型~選択子$が在る場合、 +それは最初に来なければならない +］とする既存の規則は適用される +（すなわち、 +`&div^css は違法であり， +代わりに `div&^css と書かれなければならない）。 ◎ -For example, &div is a valid nesting selector, meaning "whatever the parent rules matches, but only if it’s also a div element". +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).
--`div&^css として書いても，同じ意味を伴うことになるが、 -それは，`入子な~style規則$を開始するには妥当でなくなる -（が、選択子の先頭~以外には，利用できる）。 -◎ -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). -
-