[csswg-drafts] [css-nesting-1] Name, terminology, and nesting selector misnomers are footguns (solution proposed) (#8329)

zealvurte has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-nesting-1] Name, terminology, and nesting selector misnomers are footguns (solution proposed) ==
### Problem
From https://github.com/w3c/csswg-drafts/issues/8310, I'm convinced this spec is currently a big footgun, due to the similarity to preprocessor nesting, and much of the feedback and expectations of it come from believing it can replace most use cases for preprocessor nesting, most notably as sugar for combining multiple selectors to avoid duplication.

As per that issue, it can not achieve this currently, and if it was changed to be able to, it would be a difficult enough challenge for implementers to make it performant, that they would have to delay it indefinitely until that difficultly can be overcome.

Assuming the current behaviour described (`:is()` is implicit on `&`, so that `&` refers to the parent selector's selected elements, not the parent selector) remains as is, I think this spec is going to (continue to) elicit a great deal of misunderstanding, with extra difficultly troubleshooting (by way of implicit forgiving selectors), and requiring a lot of learning resources to clarify things and list the many "gotchas" authors can encounter. It will also have to continue coexisting with the preprocessors tools, which right now seems problematic with it sharing much of the same terminology and syntax.

### Proposed Solution
To avoid all this (while allowing for a future where preprocessor-style nesting may still be introduced to CSS), I'd like to propose changing the name, terminology, and nesting selector.

#### Change Naming & Terminology
I believe "nesting" is a misnomer for this spec's original intent and current state. Nesting is just a by-product of the syntax chosen and existing syntax for writing rules, there's no (to my knowledge) inheritance between the nesting happening so there's no hierarchal nesting, and it's obviously not manipulating ascendant and descendant context selectors, so referring to it by an inconsequential aspect of it seems misleading.

I think it would be more fitting to be referred to as "chaining" or "scoping". What the spec achieves could be better described as chaining the results (i.e. selected elements) of distinct selectors, to create arbitrary scopes within that chain for applying new rules. Making that clearer in name and terminology will help differentiate it, and avoid many of the misunderstandings and "gotchas" for authors.

I'm aware "chaining" is already sometimes used as a misnomer for the descendant combinator, but I think correcting that would be a bonus. I'm also aware [css-scoping] exists, but as I understand the current state of that spec, `@scope` is not used, and the name "scoping" doesn't quite fit it when it's not utilising `:scope`, defining scope as a concept and only focuses on the scoping/encapsulating for the shadow DOM. If there is conflict with [css-scoping], it would probably be a good time to look at the shared concepts and behaviours that could be resolved together.

#### Change Nesting Selector
With the above in mind, I believe `:scope` should be used instead of `&`, because:
- `:scope` has an existing understanding of referring to the already selected elements when used in new selector within that scope
- `:scope` will make it clear that the nested parent's selector will already be resolved to selected elements, therefore nesting is more like chaining selectors in a similar way as JS does, and not sugar for deduplicating multiple selectors
- `:scope` is underutilised (being limited to CSS queries in JS), so prime real-estate for expanding upon (e.g.,  `Element.querySelector('div :scope')` and similar would also become possible under the same logic as a chaining selector that establishes a new scope.)
- `&` reads too much like an "and" combinator, which would be a new and unnatural concept in CSS
- `&` already has an understanding in preprocessor tools

### Closing
I think these changes largely shrink the footgun potential, by differentiating it from preprocessor nesting almost entirely, and making the behaviour more explicit and intuitive for it's unique place in CSS. I would feel far more comfortable about the short and long term impact of the existing behaviour being used if that happened.

(Apologies if some of these topics have been covered in depth before, I've been away from web development for years, and from some searching of open and closed issues, I only found issues mentioning some of these things in different contexts, but not this same issue and proposal)

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8329 using your GitHub account


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

Received on Wednesday, 18 January 2023 18:59:22 UTC