-
-
Notifications
You must be signed in to change notification settings - Fork 75
Comments cause parent selector output repetition #285
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
@argyleink thanks for reporting this! I've narrowed it down to this minimum case: .foo {
/* Baz */
&.bar {
background-color: red;
}
} Which produces: .foo {
/* Baz */
}
.foo.bar {
background-color: red;
} This is mostly due to |
Tricky one 🤔 Technically it is correct and some authors might even expect exactly the current behaviour. The tricky bit is that we can't differentiate between a leading or a trailing comment : .foo {
/* #region: Base styles */
color: red;
width: 20px;
/* #endregion: Base styles */
&.bar {
/* #region: Specific styles */
color: red;
width: 20px;
/* #endregion: Specific styles */
}
} Would become : .foo {
/* #region: Base styles */
color: red;
width: 20px;
}
.foo.bar {
/* #endregion: Base styles */
/* #region: Specific styles */
color: red;
width: 20px;
/* #endregion: Specific styles */
} |
@argyleink Is this a blocking issue for you?
I can be convinced to fix this if a well defined heuristic can be found. |
not blocking, just noise. i'm commenting out my comments during dev so it's not noise in devtools.. can efforts be made to avoid producing empty selectors? i'm not worried about where the comments go, it's more the side effects and cruft produced by using comments inside nesting. some part of the plugin script is generating a new selector for the parent and then not putting anything into it, then inserting it into the stylesheet. could the selector be verified to contain rules before insertion? i get leaning onto minifiers, but it'd be cleaner if the plugin didnt produce them at all. |
This is done for truly empty selectors, but selectors with a comment node are not empty for PostCSS. Some plugins also listen to comments to change behaviour half way through a file : https://github.com/postcss/autoprefixer#control-comments
The order is preserved as this is important. .foo {
color: red;
&:where(:hover) {
width:10px;
}
width: 20px;
}
To preserve the order we must insert duplicates of the parent selector. Side note : We tried to enforce the spec here and disallowed declarations after nested rules. This backfired as there is too much sugary syntax that is a declaration in PostCSS first but then expanded to a rule later. We reverted this enforcement. If we had been able to add this enforcement it would be trivial to count all comments of this kind as belonging to the nested selector. more reading on this : csstools/postcss-nesting#95 (comment)
If we can define a good heuristic we can do this. |
yeah, i expect this to be a gotcha once folks switch from scss/postcss nesting to built-in. totally coo if you kept it 👍🏻
proposal: if a selector is only containing a comment, replace the selector and comment with just the comment? progress {
/* indeterminate Firefox */
}progress:indeterminate::-moz-progress-bar {
background: var(--_indeterminate-track);
background-size: var(--_indeterminate-track-size);
background-position: right;
animation: var(--_indeterminate-track-animation);
}progress {
/* complete */
} becomes /* indeterminate Firefox */progress:indeterminate::-moz-progress-bar {
background: var(--_indeterminate-track);
background-size: var(--_indeterminate-track-size);
background-position: right;
animation: var(--_indeterminate-track-animation);
}/* complete */ hopefully this keeps the order but targets just the problem area (selectors with only comments). that list of empty selectors in devtools looks buggy, this would be hard to explain to someone new who is just trying to diligently comment their code, yet the output bloats. thanks for looking at this, def not as simple to solve as i'd anticipated! |
I like this! |
Thanks for all of this and I'm glad it was something that could get fixed! @argyleink this got just released as |
Bug description
Source CSS
Expected CSS
Actual CSS
Does it happen with
npx @csstools/csstools-cli <plugin-name> minimal-example.css
?No response
Debug output
No response
Extra config
No response
What plugin are you experiencing this issue on?
PostCSS Nesting
Plugin version
7.4.2
What OS are you experiencing this on?
No response
Node Version
17.1.0
Validations
Would you like to open a PR for this bug?
The text was updated successfully, but these errors were encountered: