Re: [csswg-drafts] [cascade-6] Unclear proximity for scoped descendant combinator (#8380)

@mirisuzanne My point with (2) vs (3) was that they can not both expand to effectively the same `@scope` chain (as you have done), because they do not select the same elements.

> A >> B C >> D -> @scope (A) { @scope (B C) { D }

For example, the `@scope` chain would match `B -> A -> C -> D`, but the selector would not.

The `@scope` chain would also match `B -> ACD` (where `ACD` is an element that can be matched by either `A` or `C` or `D`) since scoping is root-inclusive. (Although that's a separate point).

> To make sure I understand what's implemented: When @scope rules are nested, you're not currently calculating all the proximity relationships up the chain - only the final relationship.

Yes, exactly. I did not see anything in https://drafts.csswg.org/css-cascade-6/#scope-atrule that would suggest anything else.

> I think that might be a reasonable solution, and certainly the easiest one to reason about.

It should be completely uncontroversial in terms of performance, and if it's easy to reason about I guess that's something authors will appreciate as well. The question is if it's "too simple" from the author's perspective, i.e. would proximity still be useful enough in more complicated (nested) scoping scenarios? (I can't answer this question).


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


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

Received on Thursday, 2 February 2023 00:17:33 UTC