[css-nesting][selectors] Behavior of & at the root of a stylesheet about csswg-drafts HOT 8 CLOSED

@Afif13 I just tested in Safari 17.4.1, it increases specificity for each & (&& overrides & that comes later). Safari TP 193 does the same.

from csswg-drafts.

Just in time when I am sharing another quirk around "&": https://twitter.com/ChallengesCss/status/1787931976663466068

&& {
  /* will select the html element */
}
&&&& {
  /* will also select the html element */
}
&&&&&&& {
  /* I think you get the idea */
}

/* All the above have the same specificity */

I suppose Safari will make all the above having a different specificity? Can you test it please? I cannot.

from csswg-drafts.

I actually find it surprising that & at the root does not always have the same specificity as :scope.

I would also expect && at the root to have the same specificity as :scope:scope.

from csswg-drafts.

Currently the spec says that

The specificity of the nesting selector is equal to the largest specificity among the complex selectors in the parent style rule’s selector list (identical to the behavior of :is()).

As I read the current spec, & as the top level selector represents the same thing as :scope in the same context (i.e. :root) but has the specificity identical to that of :is() with the empty selector list (i.e. zero). So behavior of Chrome and Firefox looks intuitive to me and behavior of Safari (presuming it does some implicit conversion/substitution) seems too "magical". However, adding an explicit clarification about that particular case would be great!

from csswg-drafts.

@myfonj yes, --prop gets resolved to 1 with :where() in Safari (both stable 17.4.1 and TP194).

from csswg-drafts.

I believe this is covered by #10196 (comment)

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

Closing.

from csswg-drafts.

What if it resolves to :scope?

I believe :scope itself resolves to :root when used outside a @scope.

from csswg-drafts.

For me the "root specificity exception" (i.e. that root-level & targeting :scope has zero selector specificity, like in current Firefox and Chrome) makes also sense, but I understand that it seems like an extra hatch maybe.

Intuitively I'd expect that when I fold everything I have so far in a style with one or more &s it should not change "much", i.e. in.

<style>
& { & { body { --prop: 3; } } }
& { body { --prop: 2; } }
body { --prop: 1; }
</style>

I'd expect to --prop to be still 1.

I see that it might be inconsistent with non-root & behaviour and explicit :wheres would be required here to make it weak again, thus uniform with &'s general behaviour. I guess in

<style>
:where(&) { :where(&) { body { --prop: 3; } } }
:where(&) { body { --prop: 2; } }
body { --prop: 1; }
</style>

--prop gets resolved to 1 even in Safari right now? (Cannot test.)

This also maybe raises a question for #8752 , whether <el style="--prop: …;"> and <el style="& { --prop: …; }"> should make any difference or not.

from csswg-drafts.