-
Notifications
You must be signed in to change notification settings - Fork 715
[css-nesting-1] Clarify valid position of &
in a selector
#9940
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
none of this is invalid:
The |
Indeed, they could be validated without considering the selector of the parent style rule. This is not specified. I would not mind if it was. It may be surprising that This is slighlty unrelated to my original question though. Maybe I should create a dedicated one. |
It does indeed clearly define where it's valid - it's a new type of selector (by implication, a new "simple" selector). The valid positions are thus defined by the grammar. None of the options you listed are places where you can put a selector. |
That's also correct behavior. We don't "expand" the & in a nested selector, it just represents the elements matched by the parent selector. It doesn't represent pseudo-elements, so in this example it ends up matching the |
CSS Nesting does not clearly define where
&
is allowed to appear in a selector. In Chrome/FF, these selectors are all invalid:html|&
html&|*
#&id
.&class
[&]
[attr=&]
[attr=value &]
While the position of
&
does not make a difference in its behavior, it should only match<type-selector>
and<subclass-selector>
in<compound-selector>
.I would also like to suggest to define this again (cf. #7503):
In Chrome/FF, the nested rule in
::before, div { &:first-child {} }
is valid whereas the version without nesting,::before:first-child, div:first-child {}
is not (because:first-child
is not allowed to be compounded to::before
).The text was updated successfully, but these errors were encountered: