Re: [csswg-drafts] [css-cascade-6] Strong vs weak scoping proximity (#6790)

So after trying to wrap my head around the interactions of specificity, layers and proximity, I think there might be a case for having some mechanism for having at least opt-in strong proximity.

Correct me if I'm analysing this wrong, but let's consider using scopes for theming. A straight-forward way of implementing this would be to have a `@scope ([theme="dark"]) to ([theme])` rule.

As there's often subtle differences in how something looks in dark vs. light mode, it is reasonable to assume that both will have specific overrides with more specificity than the base-case, say when a specific element looks good with a generic box-shadow in light mode, but needs a more individualised shadow in dark mode.

In this basic example, the lower boundary is enough to prevent the more specific dark-mode shadow to mess with the element within a nested light theme, which only has a less specific "generic" style.

What worries me is that I don't think real world applications will always have a clearly defined lower boundary. In the example of themes, two CSS authors may (without knowing of each other) decide on different ways to scope their themes, where one uses `[theme="dark"]` and the other uses `[data-theme="light"]`, or anything of that sort.

This could not be solved by lower boundaries, as neither author would know where to end their scope, nor could it be fixed by layers, as these themes could be nested again and again, and the innermost theme will be the one we want to take precedence.

Without having used scoping in real-world projects yet, I haven't come across any specific example where this sort of situation might naturally happen without an easy workaround, but I'd be surprised if these cases wouldn't end up happen a lot once scopes start to be used.

-----

As for a solution, I'm not sure how I'd prefer to "opt in" to strong proximity. Adding an optional keyword to the scope @-rule seems like a last resort. My initial idea was, based on misremembering `>>`, that one could just prepend rules inside the `@scope` block with `:scope >>`, but after checking it seems like `>>` also only applies weak proximity.

Maybe an analogue operator that applies strong proximity could be a way remedy this? The advantage of that would be, of course, that it could be added later on and thus wouldn't get in the way of an initial implementation of `@scope` which I want to see as soon as possible.

<details>
<summary>Just  to illustrate this with some pseudo-CSS</summary>

something like

```css
@scope (.theme-light) { p { text-shadow: <generic> } }
@scope ([theme="dark"]) {
   p { text-shadow: <generic> }
   div.inset p { text-shadow: <tweaked> }
}
```

could turn into something like

```css
@scope (.theme-light) { :scope !>> p { text-shadow: <generic> } }
@scope ([theme="dark"]) {
   :scope !>> p { text-shadow: <generic> }
   :scope !>> div.inset p { text-shadow: <tweaked> }
}
```
</summary>

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


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

Received on Tuesday, 28 February 2023 16:12:09 UTC