- From: Daniel Upstone via GitHub <sysbot+gh@w3.org>
- Date: Mon, 23 Jan 2023 21:32:13 +0000
- To: public-css-archive@w3.org
> [...] this feature is unmistakably "CSS Nesting". Except nesting is already a syntax and terminology that exists in CSS, yet has no single behaviour attached to it. Naming this "nesting" would be defining behaviour for only one usage of nesting purely because it uses that syntax, while creating confusion where other specs use the same term and syntax already (on top of that from familiarity with the "Selector Inheritance" behaviour). > It is not safe to reuse :scope as part of nesting. It's a selector that has existed in production for years, and has a defined meaning. Cascade-6 doesn't invent the selector, it only provides new ways to define scopes that the selector can reference. It would be safe to use for this purpose, as it still doesn't need redefining from selectors-4, and css-cascade-6's scoping mechanism already supports and allow most of what is needed. The most significant change I foresee is that `:scope` is implicitly allowed pretty much everywhere right now, but currently it's behaviour in these new contexts are not defined or explored in examples except for `scope-end`, where under scoping limits it is defined that the selector it is used in and its placement establishes the relationship to the scoping root. What happens if I put `:scope` in a `scope-start` selector of a nested `@scope`? What if it's not at the beginning? What about in a scoped selector inside `@scope`? I expect most of these to fail to ever match, but defining them in a similar way to `scope-end` would allow compatibility with css-nesting-1. It would need to explicitly show that `:scope` can be used anywhere within a selector `scope-start` and `@scope`'s body, and define what that means (especially within scoping limits). For the latter, this would override the implicit `:is(:scope)` prepended to the scoped selectors, allowing many types of scoping root relationships to be defined in a similar parsing to `scope-end`, but without it defining a scoping limit. For `scope-start`, it's the same parsing of relationship again, but establishes a new scope as it already does. These are not foreign concepts to either spec. > If we want to use `:scope` here, nesting would need to _become_ a scoping mechanism, with all that entails. That's not a rout we want to go down. I'm saying it already acts like one, so it probably should be defined in the shared language of one, so why is this not a route to take? > [...] we find that they cannot simply be merged. The use-cases overlap, but are not identical. It's important that they work together, but that requires keeping the syntaxes distinct. Can you point to something to support them not being mergeable and/or the syntaxes having to be distinct? The only conflict I see is deciding if the scoping proximity rules fit the use-cases covered by css-nesting-1 (which I think they do), and if it's decided to use strong proximity for scoped descendants by default (latest draft suggests it won't), does that remain the case, and if not, how to modify the behaviour (which may require a distinct syntax, or something that works across them all). -- GitHub Notification of comment by zealvurte Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8329#issuecomment-1401012254 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 23 January 2023 21:32:15 UTC