Re: [csswg-drafts] [css-cascade-6] Specificity of Implicitly-Added `:scope` in Scoped Rules (#10196)

The CSS Working Group just discussed ``[css-cascade-6] Specificity of Implicitly-Added `:scope` in Scoped Rules``, and agreed to the following:

* `RESOLVED: explicitly state in specs that when an ampersand doesn't actually have a parent rule to draw from then its specificity is zero`

<details><summary>The full IRC log of that discussion</summary>
&lt;jarhar> emilio: the at scope rules insert an explicit :scope selector when you dont have it, much like nesting<br>
&lt;jarhar> emilio: its weird but it seems intentional as per the discussion in the issue that :scope doesnt contribute to specificity<br>
&lt;jarhar> emilio: its weird but it also seems like if you do the ampersand then webkit and blink have different behavior which is weird<br>
&lt;jarhar> emilio: i think i would expect webkits behavior there<br>
&lt;jarhar> emilio: thats basically a question<br>
&lt;jarhar> miriam: webkits behavior in which?<br>
&lt;jarhar> emilio: in the ampersand case.<br>
&lt;TabAtkins> https://github.com/w3c/csswg-drafts/issues/10196#issuecomment-2065371007<br>
&lt;jarhar> TabAtkins: the example with which behavior chrome is and which behavior webkit is<br>
&lt;jarhar> emilio: basically ampersand inside scope rules means :scope and right now chrome seems to ignore the specificity of scope ? you have explicitly written the ampersand<br>
&lt;jarhar> miriam: ampsersand isnt :scope exactly, it refers to the scope root element, and the ampersand refers to the seelector in the scope start. consistent with how those two selectors have worked in other places. ampersand refers to a selector and ? refers to an element?<br>
&lt;jarhar> TabAtkins: the ampersand the referring selector is empty<br>
&lt;jarhar> emilio: ampersand and :scope are effectively the same right?<br>
&lt;jarhar> TabAtkins: behavior is the same except for this case because ones a pseudo class and one is a parent selector. how academic this is is a good question<br>
&lt;jarhar> kizu: you could use it not to just target the scope itself ?<br>
&lt;jarhar> kizu: i managed to do something with it but i dont remember exactly<br>
&lt;jarhar> miriam: what does ampersand do on its own?<br>
&lt;jarhar> TabAtkins: its supposed to match the same element in the parent rule?<br>
&lt;jarhar> miriam: what about root level of a stylesheet<br>
&lt;jarhar> matthieud: the root level - it should be :root and it gets one specificity of the pseudo class<br>
&lt;jarhar> TabAtkins: that is not specified in the spec. the specificity line explicitly refers to the line ? selector list, doesnt say what specificity is<br>
&lt;jarhar> TabAtkins: thats just what browsers are doing on their own right now<br>
&lt;jarhar> miriam: im getting zero specificity in chromium<br>
&lt;jarhar> emilio: another case where gecko and chromium do zero specificity but webkit does use specificity<br>
&lt;emilio> data:text/html,&lt;style>&amp; p { color: green } p { color: blue }&lt;/style>&lt;p>ABC<br>
&lt;emilio> green in webkit, blue in gecko / blink<br>
&lt;jarhar> astearns: so we need to fix both things<br>
&lt;jarhar> TabAtkins: we can decide on which behavior we like better, but ...<br>
&lt;jarhar> TabAtkins: zero specificity in chrome<br>
&lt;jarhar> miriam: that feels a little strange to me but i dont have an argument why the other would feel less strange. i dont think of it as a zero specificity selector<br>
&lt;jarhar> TabAtkins: doesnt have a specificity to refer to, it just matches the same thing as scope<br>
&lt;jarhar> TabAtkins: not defined in terms of that selector existing having specificity<br>
&lt;jarhar> miriam: if we have it at zero specificity, then we specify everything on ampersand instead of root<br>
&lt;jarhar> miriam: people will say where root to get zero specificity<br>
&lt;jarhar> TabAtkins: the only difference is if ? target root to ? some of the properties with html as a selector. that would lose if it had a pseuco class specificity. in all cases it wouldnt matter<br>
&lt;jarhar> TabAtkins: they can already do it with where<br>
&lt;jarhar> miriam: maybe the scope case is a better one to look at. is it surprising you write styles scoped styles in an embedded stylesheet you use the ampersand, you get zero specificity<br>
&lt;jarhar> miriam: thats where it would become an issue more often because someone woudl be targeting that div<br>
&lt;jarhar> miriam: if you use solely an ampersand it becomes zero outside stylesheets have ? specificitity, scope comes into play, that becomes riskky<br>
&lt;jarhar> TabAtkins: giving it a specificyt of zero pseudo class is easy to override, zero is easier but not by a huge amount<br>
&lt;jarhar> astearns: im hearing lots of strong opinions, how are we going to decide?<br>
&lt;jarhar> TabAtkins: technically chrome and firefox agree and spec. as 2/3 aint bad<br>
&lt;jarhar> emilio: yeah not strong opinion. just some of it - having a ? context selector doesn't increase specificity<br>
&lt;jarhar> emilio: yeah i guess its ok<br>
&lt;emilio> s/? context selector/more complex selector which/<br>
&lt;jarhar> matthieud: i dont have a strtong opionin either, but when you ? a selector more when you add some part to a selector :root i guess itm kaes sense when you are more explicit that you get something from it<br>
&lt;jarhar> matthieud: all this is really edge case i dont know if anyone will check this<br>
&lt;jarhar> miriam: so thats an argument for zero?<br>
&lt;jarhar> astearns: and i believe that the issue about wpt, do they test for zero or something else?<br>
&lt;jarhar> emilio: i think that they test for zero specificity but thats for visit scope not ampersand<br>
&lt;jarhar> astearns: so we could resolve on zeroing both a bare ampersand and scope<br>
&lt;jarhar> astearns: since nobody has a strong opinion about it and they should probably match and we have tests that browsers pass, but with the option of reopening it if we find a use case for doing non-zero at some point in the future<br>
&lt;jarhar> TabAtkins: ultimately authors can do that - they can just put :scope in the @scope selector and that will do it<br>
&lt;jarhar> astearns: and if we find people doing that maybe we can say hey maybe we should be doing hta tautomatically<br>
&lt;jarhar> fantasai: summary of what we're talking about?<br>
&lt;jarhar> TabAtkins: do you want to the proposed resolution?<br>
&lt;jarhar> fantasai: we talked about :scope and ampersand, are we talking about both fo tth eresoultion?<br>
&lt;emilio> explicit :scope is fine, things to discuss are "implicit" scope and bare ampersand<br>
&lt;jarhar> TabAtkins: no, ampersand doesn't have a selector for its parent, when it implicitly selects nothing at all its specificity is zero<br>
&lt;jarhar> astearns: which is tested but not specified<br>
&lt;jarhar> TabAtkins: it is technically specified, not explicitly. it should be more explicit<br>
&lt;jarhar> fantasai: and whats an example of a case where ? selector<br>
&lt;jarhar> TabAtkins: its at the root level or inside a scope which doesnt have a scope start<br>
&lt;jarhar> fantasai: for example inside a style element<br>
&lt;jarhar> TabAtkins:<br>
&lt;jarhar> TabAtkins: right<br>
&lt;jarhar> astearns: there would also be a resolution that the - that scope would match this as well<br>
&lt;jarhar> fantasai: :scope would be zero always or only when its implicit<br>
&lt;jarhar> fantasai: if i have an at scope and a id selector, then when i write foo inside there, im implicitly adding :scope and that adds a pseudo class to it<br>
&lt;jarhar> TabAtkins: no, that was a decision we made on purpose. you just get the selector that you wrote plus the magical scoping behavior<br>
&lt;jarhar> fantasai: so it doesn't inherit the scope start specificity unless you write :scope explicitly<br>
&lt;jarhar> fantasai: so why dont we do that in the case ??<br>
&lt;jarhar> matthieud: its not true for the ? selector<br>
&lt;jarhar> TabAtkins: for general nesting, its expected - if nesting didnt ? the specificity then everything would break. scoping gives us some ? for nesting you assume your rules are more specific<br>
&lt;jarhar> TabAtkins: otherwise &amp;hover would almost never match because the parent rule would override it<br>
&lt;jarhar> fantasai: i was trying to figure out why it would suddenly gain some specificity<br>
&lt;jarhar> miriam: nobody is proposing that<br>
&lt;jarhar> miriam: its not clearly defined in either place, lets make sure its the same<br>
&lt;emilio> s/&amp;hover/&amp;:hover/<br>
&lt;jarhar> TabAtkins: explicitly state in specs that when an ampersand doesn't actually have a parent rule to draw from then its specificity is zero<br>
&lt;jarhar> TabAtkins: explicitly defined in the spec<br>
&lt;jarhar> astearns: any objections?<br>
&lt;jarhar> astearns: do we also have to make a scope resolution?<br>
&lt;jarhar> TabAtkins: neither ampersand nor explicit scope - thats already in the spec<br>
&lt;jarhar> astearns: i think we are done<br>
&lt;astearns> RESOLVED: explicitly state in specs that when an ampersand doesn't actually have a parent rule to draw from then its specificity is zero<br>
</details>


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


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

Received on Tuesday, 11 June 2024 16:01:40 UTC