Re: [csswg-drafts] [css-cascade-6] Scoping the subject of a `:has()` selector (#9841)

`:scope:has(a)` working out-of-the-box might make sense for this particular example.

```css
@scope (my-scope) to (my-scope) {
  :scope:has(a) {
    /* … only match if `a` is within scope */
  }
}
```

But there might be cases where you'd want the current behavior. If it's easy to opt in/out of one or the behavior, it should be fine?

Maybe to opt out, the rule should just be written outside of `@scope` by itself. Although I do want to mention that nonstandard userland implementations of scoping provide a way to "bail out". For example, [CSS Modules](https://github.com/css-modules/css-modules) provides a `:global()` selector. This is useful when you want part of the selector to be within the scope and other parts to match globally.

```css
@scope (my-scope) to (my-scope) {
  :scope:global(:has(a)) {
    /* … use default unscoped :has behavior */
  }
}
```

I also like the `:scope-end` selector. It could probably be useful for other cases that we haven't thought of yet. Although, since the lower boundary itself is excluded from the scope, maybe that limits its usefulness.

---


> It does seem to me like this should work actually? What am I missing?
> 
> ```css
> @scope (section) to (section) {
>   :scope:has(a:not(:scope section *)) {
>     background: lavender;
>   }
> }
> ```

Wouldn't it break with further nesting, for example, five levels of nested `<section>`s?

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


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

Received on Tuesday, 23 January 2024 19:46:39 UTC