Re: [csswg-drafts] [css-nesting-1] Syntax Invites Errors (#7834)

nest
To organize the discussion a bit for tomorrow, the options we're looking at are:

1. Current spec - every nested rule needs to be unambiguous on its own, either by starting with an `&` or by being an `@nest` rule.
2. New proposal - after some parsing switch has been tripped, everything's assumed to be a nested rule. There are a few possibilities for the parsing switch:
 1. Just at-rules. This means any nested at-rule, like a nested @media, or the no-op `@nest;` rule we'd introduce.
 2. [(link)](https://github.com/w3c/csswg-drafts/issues/7834#issuecomment-1268979633) The above, plus any style rule starting with an `&`. (Rules following the switch can start with whatever.)
 3. [(link)](https://github.com/w3c/csswg-drafts/issues/7834#issuecomment-1270665794) The above, plus any style rule starting with a non-ident. (So `.foo`, `:hover`, etc will trigger the switch, but `div` won't.) (Rules following the switch can start with whatever.)
3. [Lea's proposal](https://github.com/w3c/csswg-drafts/issues/7834#issuecomment-1272373216) - No parsing switch, instead nested rules have to be locally unambiguous by starting with anything but an ident. (You can write `:is(div)` if you need to start a selector with a type selector.) (This employs the same parsing strat as (2.3) to avoid accidentally parsing invalid properties like `//color: red;` as rules.)

------

Arguments for each of the above options:

<table>
<thead>
 <tr><th>#<th>Pros<th>Cons
</thead>
<tr>
<th>(1)
<td>
<ul>
<li>Every rule is valid or invalid "locally", no need to track context.
<li>`&` or `@nest` is visually distinct from properties.
<li>`@nest`, if used only when needed, signals "odd" nesting. (But might be used anywhere.)
<li>Theoretically can mix properties and rules in any order, tho we won't retain their relative order in the data model. (All properties will be treated as preceding all rules.) (Currently the spec disallows this, to avoid confusion.)
</ul>
<td>
<ul>
<li>Syntax is different from other nesting contexts (like `@scope`, or global `@media`)
<li>More verbose than Sass/etc-style, which many authors are used to. (And is arguably just a good design.)
</ul>

<tr>
<th>(2.1)
<td>
<ul>
<li>After the switch, syntax is the same as other nesting contexts.
<li>Syntax is same as Sass/etc-style, which many authors are used to. (And is arguably just a good design.)
</ul>
<td>
<ul>
<li>The `@nest;` no-op rule is weird.
<li>Can't *quite* naively move code between nested contexts; need to make sure the switch is there (or add it) when moving *to* plain nesting. (But moving to other contexts is always safe, even if you copy over the `@nest;` too.)
<li>Can't mix properties and rules - all properties have to come first. (But this matches the data model anyway.)
</ul>

<tr>
<th>(2.2)
<td>
<ul>
<li>Same as (2.1), but you can avoid using `@nest;` most of the time if you instead start your first rule with `&`.
</ul>
<td>
<ul>
<li>Need to pay somewhat more attention to context, and make sure your first rule is written correctly - either preceded by an at-rule, or starting with `&`.
</ul>

<tr>
<th>(2.3)
<td>
<ul>
<li>Same as (2.2), but you can avoid using `@nest;` in even more cases; unless your first selector starts with a type selector, you can just nest naively.
</ul>
<td>
<ul>
<li>Still somewhat context-sensitive, just less so than (2.2).
<li>Prevents us from ever changing property syntax to start with an ascii glyph. (Like `+transform:...;` for additive properties?) (But these are probably already ruled out anyway, due to people using garbage to "comment out" their properties, like `//color: red;`, or `*color:red;` for an old IE hack.)
</ul>

<tr>
<th>(3)
<td>
<ul>
<li>Like (1), every rule is valid or invalid "locally", no need to track context.
<li>Like the (2.X) set, can *mostly* transfer rules between nested contexts. Going *from* nested to `@scope`/etc is always valid; going from `@scope`/etc *to* nested is *usually* valid, unless the rule starts with a type selector.
<li>Like the (2.X) set, syntax is same as Sass/etc-style except for selectors starting with a type selector.
<li>Like (1), can theoretically mix properties and rules again, but the data model will still have to act as if all properties as coming first.
</ul>
<td>
<ul>
<li>Rules are invalid if they start with a type selector, requiring them to be rephrased somehow. (Using `:is(div)`, starting with `&`, etc.)
<li>Like (2.3), prevents us from changing property syntax to start with an ascii glyph in the future. (But similarly, this is probably already lost to us.)
</ul>
</table>

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7834#issuecomment-1275197850 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 11 October 2022 19:51:56 UTC