Re: [csswg-drafts] [selectors-4] Consider disallowing :scope inside :has() (#7211)

The issue #6952 seems to converge in the opinion of disallowing nested `:has()` only.

Based on it, I think it would be desirable to clarify these three issues that are related to each other.
* #6399
* #7211
* #7212

I think that the key point is to resolve the ambiguity between the implicit `:has()` scope and explicit `:scope` inside `:has()`. (described in the #6399)

There can be two options.

**Option 1:** We can disallow explicit `:scope()` inside `:has()`.

It looks simple and clear way to remove the ambiguity. We don't need to think about how the `:scope` works inside `:has()`. By banning this, we can simply agree on disallowing `:host`, `:host()` and `:host-context()` inside `:has()`. (Those can increase complexity of `:has()` matching/invalidation by expanding the traversal scope to out of the shadow boundary)

The only downside is that we cannot use explicit `:scope` inside `:has()`.

**Option 2:** I think that removing `:scope` dependency from the `<relative-selector>` definition and allowing explicit `:scope` inside `:has()` can be an alternative.

The only advantage is that we can use `:scope` inside `:has()`. (As described at above, it seems only work in selector query for some limited cases)

In this case, to avoid some misunderstanding, we need to clarify that the absolutizing relative-selector doesn't related to the `:scope`, so the explicit `:scope` inside `:has()` doesn't have different meaning. (_Personally I'm confusing whether the `:has()` is a scoped selector by itself - https://drafts.csswg.org/selectors/#the-scope-pseudo, https://drafts.csswg.org/selectors/#scoped-selector_)

About the risk of this option, I don't have any case right now, but I'm not sure that it will not make any tricky issues.

**Desired resolution**

In my opinion, **Option 1** looks better because it is simple and it only limit some rare usages.

**Alternative**

If the **Option 2** is accepted, we need to discuss #7212 (disallowing `:host`) separately.
* Can it be supported with reasonable performance by acceptable effort?
  > If these are only available in the selector query (as described above), I think it is not difficult. But if there can be any usage in style rules, then it will be hard to support invalidation since we need to cross the shadow boundary.
* Is there any case having potential security issues?
  > It looks not have any specific issue. (`:has()` inside `:host()` can have an issue of violating shadow encapsulation, so it was disallowed in Chrome : https://crbug.com/1307281)
* Does the case have any useful usage?
  > I cannot imagin the specific usage that `:host()` is meaningful only inside `:has()`.


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


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

Received on Friday, 20 May 2022 03:59:32 UTC