Re: [csswg-drafts] [css-cascade-6] Scoped selectors shouldn't match the scope root unless explicitly requested with :scope? (#8377)

The CSS Working Group just discussed `[css-cascade-6] Scoped selectors shouldn't match the scope root unless explicitly requested with :scope?`, and agreed to the following:

* `RESOLVED: clarifications for scoping selectors proposed by miriam`

<details><summary>The full IRC log of that discussion</summary>
&lt;fremy> miriam: the scope roots elements are currently part of the scope, with no implied relationship<br>
&lt;fremy> miriam: so, if you use the same selector for both ends, the end matches the root<br>
&lt;fremy> miriam: bramus and others found that confusing<br>
&lt;fremy> miriam: so the proposal would be to imply that nesting scope selectors include :scope<br>
&lt;fremy> miriam: except if they explicitly refererence :scope or use ampersand<br>
&lt;fremy> miriam: there are a couple of differences between :scope and ampersand<br>
&lt;TabAtkins> &amp; references all the elements matched by the scope-start selector (as normal for Nesting), :scope matches the specific element that is functioning as the scope in a given element's context.<br>
&lt;fantasai> +1 to the proposal<br>
&lt;fremy> miriam: mainly you can use &amp; multiple times<br>
&lt;TabAtkins> +1 to the proposal<br>
&lt;fremy> miriam: so the proposal clarifies the difference<br>
&lt;astearns> ack fantasai<br>
&lt;fremy> fantasai: what is the specificity of :scope and ampersand?<br>
&lt;fremy> miriam: there is another issue on that<br>
&lt;fremy> miriam: but my guess is that ampersand should work just as in nesting<br>
&lt;fremy> miriam: (wrapping the starting scope selector in :is)<br>
&lt;bramus> q+<br>
&lt;fremy> TabAtkins: (missed short comment)<br>
&lt;fremy> astearns: does that work for you fantasai ?<br>
&lt;astearns> ack bramus<br>
&lt;fremy> fantasai: yes<br>
&lt;TabAtkins> TabAtkins: That's also my preference<br>
&lt;fremy> bramus: should we also introduce :end for the end boundary?<br>
&lt;fremy> bramus: for sibling scopes, that might be useful<br>
&lt;fantasai> proposal was to have &amp; use the specificity of the selector it's referencing, and for :scope to have its normal specificity (1 pseudo-class)<br>
&lt;fremy> miriam: this sounds like a separate resolution<br>
&lt;fremy> miriam: could you provide some clear use cases for that?<br>
&lt;TabAtkins> have we discussed the meaning of relative selectors like `> .foo`? Do those get captured by Nesting, implying an &amp;, or do they imply a :scope? I think the latter should be the case.<br>
&lt;fremy> astearns: the proposed resolution is in the last comment of the thread<br>
&lt;fremy> astearns: looking at tab's question on irc<br>
&lt;fremy> astearns: tab, do you want to voice the question?<br>
&lt;fremy> miriam: I think I agree with TabAtkins suggestion<br>
&lt;fremy> miriam: relative selectors (...missed)<br>
&lt;fremy> miriam: question was what happens if the selector starts with a descendant combinator<br>
&lt;fremy> miriam: so just adding a descendant combinator should be the same as the default<br>
&lt;astearns> ack fantasai<br>
&lt;fremy> fantasai: I think that it implies that every selector inside a scope that doesn't start with an ampersand has an additional pseudo-class specificity<br>
&lt;fremy> TabAtkins: no, no difference<br>
&lt;fremy> TabAtkins: the implied-ness is just for the meaning, but not the specificity<br>
&lt;fremy> TabAtkins: the implied one does not add specificity<br>
&lt;fremy> fantasai: p and :scope p are the same, but with different specificities<br>
&lt;fremy> TabAtkins: yes<br>
&lt;fremy> fantasai: and if I add (...) I could match more<br>
&lt;fremy> TabAtkins: yes, not in that use case, but in others yes<br>
&lt;fremy> fantasai: if you use descendants, you can match much more<br>
&lt;fremy> fantasai: and both :scope and &amp; can match the scoping element, but no other selector can<br>
&lt;fremy> miriam: no other selector make it remove the nested-within combinator<br>
&lt;fremy> TabAtkins: by the magic of relative selectors, it will never happen<br>
&lt;fremy> TabAtkins: you have to make it absolute to override<br>
&lt;fremy> fantasai: ok, this is probably fine, but the spec should be extra clear about it<br>
&lt;fremy> astearns: so, the proposed resolution is to accept miriam's prososal + add new clarifications<br>
&lt;fremy> astearns: any comment?<br>
&lt;fremy> fantasai: lgtm<br>
&lt;fremy> astearns: any objection?<br>
&lt;fantasai> s/lgtm/I think this is a good change and I support it/<br>
&lt;fremy> RESOLVED: clarifications for scoping selectors proposed by miriam<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8377#issuecomment-1450541396 using your GitHub account


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

Received on Wednesday, 1 March 2023 17:24:50 UTC