-
Notifications
You must be signed in to change notification settings - Fork 661
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
[css-nesting-1] Example 4 : selectors starting with an identifier #7980
Comments
I think that should be valid. No need to have that restriction for anywhere other than the beginning of the rule. |
If authors want to enforce that each selector in the list is unambiguous in case of edits they can use a linter to enforce this : div {
color: red;
& input, & textarea {
margin: 1em;
}
:is(input), :is(textarea) {
margin: 1em;
}
:is(input) &, :is(textarea) & {
margin: 1em;
}
} |
Aside (sorry)
As a CSS author, I would prefer that a solution be found to remove the restriction on |
see : #7961 |
Blink currently allows starting the second one in the list with an identifier, but it does run into an issue we've talked about before (in the context around parser switching), where deleting the first rule suddenly makes the other one invalid. I'm fine with changing this if people want to, but we'd need to what happens to the rule (does only that selector go away and the sub-rule stays, or does it poison the entire parse). |
Do you mean this case : div {
color: red;
:is(input), textarea, .something {
margin: 1em;
}
} and then changing |
CSSOM is a separate problem (one that we will need to fix, but probably warrants its own issue). I'm more thinking div {
.foo, textarea { … }
} Now the developer figures out they don't need .foo anymore, and removes it everywhere… without realizing that the remaining rule is now wrong and kills the entire rule. Or that if you just switch the ordering, the rule suddenly becomes illegal. |
Yes the previous iteration of the nesting spec had The linter rules needed to help authors write correct nested CSS have become more numerous and more complex with the new syntax. I have added this example to the list.
Also a "simple" re-ordering of selectors. div {
textarea, .foo { … }
} |
The spec says "The selector of nested style rules must not start with an identifier or a functional notation." - it does not specify "each complex selector of the selector list of a nested style rule". So, the restriction is applied to the selector (list) as a whole, and only affects the first selector in the list. (This is because the restriction only exists as a parser-level restriction to allow me to tell where a rule starts. Once we know we're in a selector, it doesn't matter what the rest of the selector does.) |
For whoever's bothered by this, I've made a Stylelint rule that auto-inserts any missing https://gist.github.com/aleclarson/2cb1be7aab5500198c985eaf07119ed2 |
https://drafts.csswg.org/css-nesting/
Does this only apply to the first selector in a list or to each?
invalid :
valid/invalid? :
From a parser perspective only the first in the list is important. But from an author perspective this is less obvious.
If you remove
:is(input)
then you need to modifytextarea
to make it valid again.I have no preference here, only need to know what to implement
The text was updated successfully, but these errors were encountered: