Re: [csswg-drafts] [css-nesting-1] Clearer definition of “nest-containing” (#7972)

Proposal Part 1: Selector Lists
--------------------------------

Split on top-level commas, and decide whether each selector is relative or not independently. (`.foo { .bar, .baz & {...}}` desugars to `.foo .bar, .baz .foo {...}`). (Doing anything else seems like it would give strange results, and result in worse editting hazards for authors.)

Proposal Part 2: Enclosed &
--------------------------------

* Option 1: Relativeness is decided based on only top-level &. An & inside any other construct (such as `:is()` or `:nth-child()`) is ignored for this purpose.
* Option 2: Relativeness is decided based on & both at the top level and within functional syntaxes (such as `:has()` or `:is()`).
* Option 3: Relativeness is decided based on & both at the top level and within only *non-forgiving* functional syntaxes (visible in `:has()` or `:nth-child()` but ignored in `:is()` or `:where()`).

Option 2 seems to be the most preferable to me, but it's unclear how `:is(:unknown(&), .bar)` should (or even *can be*) handled - once we're no longer looking at a valid selector, all bets are off on what that `&` might mean. It might be reasonable to assume we won't use `&` in a selector context in a way that doesn't represent the nesting selector, but `:is()` drops its invalid arguments when serialized, so reserializing could change the relative/non-relativeness of the selector which is bad.

Between Option 1 and Option 3, Option 1 has the advantage of being simpler to understand and explain. Both of these can potentially lead to selectors that simply cannot be written in a nested fashion (for example, `.foo { :not(&) {...}}`), but the solution is to just... not nest those. And the simpler and easier we make such situations to notice and understand, the better.

So, I propose we go with Option 1, and only recognize & at the top-level of a selector to determine whether the nested selector is relative or not.

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


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

Received on Tuesday, 10 January 2023 23:47:25 UTC