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

[ @LeaVerou, @jensimmons, @bradkemper, @tabatkins, @mirisuzanne and I discussed this problem today; this comment is a summary of the discussions.]

The following options outline the available syntax space for nested style rules:

- Prefix each individual rule
- Nest rules into a block
- Switch into rule-parsing mode after a syntactic trigger

The first option has the problems outlined above.
The second option increases the indentation level, which CSSWG had concluded was objectionable.
So that leaves us the third option.

Regardless, once we're in rule-parsing mode, in order to make nested style rules compatible with style rules elsewhere, the desire is to allow both:
- relative selectors, like in `@scope` and `:has()` (which essentially imply a prefixed &)
- &-anchored selectors, as in the current proposal, to enable patterns like `&.foo` or `.foo &`
    - Note: see https://github.com/w3c/csswg-drafts/issues/5745 for making these valid everywhere

<hr>

In terms of syntactic triggers for a rule-parsing mode, the following options were considered:
- A &-prefixed style rule (possibly empty)
- A specific delimiter token such as `&&` or `@@`.
- At rules, sub-options being:
    - A specific @rule such as `@nest;`
    - Any known @rule, including a new (essentially otherwise no-op) `@nest;`
    - Any conditional rule or `@nest;`
    - Any statement @rule (including `@nest;`) but not any block @rules
    - Any @rule known or unknown

After the trigger, parsing would continue in rule-parsing mode and not in declaration-parsing mode, so &-prefixing would no longer be required for subsequent nested style rules.

Forwards compatibility considerations:
- If we allow any at-rule, known or unknown, to act as a trigger, then we we will have difficulty in the future if we want to introduce an at-rule that can be interleaved with declarations.
- If we restrict to a known set of at-rules, then we have difficult in the future when we introduce another at-rule to the set, because new style sheets using that as the trigger won't trigger in older browsers.

Backwards compatibility considerations:
- Allowing &-prefixed rules to trigger is means existing nested code continues to work.

Pros/cons of triggering on &-prefixed rules:
    - Pro: compatibility with existing nested code
    - Pro: less noisy than introducing `@nest` everywhere
    - Con: first selector in a set of nested style rules has this special requirement, which is an odd positional requirement

Pros/cons of triggering on @nest:
    - Pro: nested style rules are all subject to the same requirements
    - Con: Lots of visually-impactful clutter in highly structured stylesheets

Pros/cons of triggering on new delimiter:
    - Pro: nested style rules are all subject to the same requirements
    - Pro: less noisy than introducing `@nest` everywhere
    - Con: such a delimiter is consequently banned from Selector grammar forever

The recommended option from the discussions today was to allow as a trigger both:
- An &-prefixed style rule
- Any at-rule, known or unknown (and introduce `@nest;` as a convenient convention)

Agenda+ to discuss

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


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

Received on Wednesday, 5 October 2022 20:46:34 UTC