-
Notifications
You must be signed in to change notification settings - Fork 3.4k
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
Keep empty selectors (rulesets) option #1006
Comments
Do you mean the |
No, probably i should have called it a "rule" ;)
They get deleted on compiling to css |
Why would you want to keep them? They're not doing anything lying around blank in the generated CSS file. You say you're trying to do styling via Firebug, but I don't understand what your approach is. |
The requirement is that the rule have to already exist in order for the plugin to sync back correctly, and obviously, if the element hasn't had styles before, i'll have to create a empty rule for the first time. It worked when i used pure CSS, but now, when i switched to LESS, i realized that compiler deletes the empty rules, and the plugin is unable to sync back the styles. I realize that that's a pretty narrow use-case... |
This seems like a very specific use case. In most cases, people would rather LESS optimized their CSS and didn't leave empty rules. I would suggest using <script type="text/javascript">
less.env = "development";
less.watch();
</script> or append If you have issues, there are some suggestions here: http://www.paulsprangers.com/2011/04/quick-tip-less-js-in-development-and-watch-mode/ |
Good advice from @Soviut. also if you don't like that, for work-around add a fake rule e.g.
|
Agreed. @agatronic 's solution does what you need without causing every other LESS file to generate inefficient CSS. |
@agatronic that's what i was doing for the last 2 weeks since i started using LESS, but a few times such fake rules got into production because i forgot to remove them, so i thought maybe there is a more clear way to fix that :( @Soviut unfortunately that's entirely different workflow, i'm not ready to give it up for using Less... also using less compiler in browser caused some serious performance issues, page load increased from 500-700ms to 2-3 s.. I understand that this option will not get added, and I agree with you, but If that's not a problem, can you tell me please in which source code file i can change the behavior by myself? |
@chetzof I figured out the solution for this. that's no the BEST way, but works for what you looking for. i have put that way: #selector { /**/ } it will appear empty on firebug. |
@d4ng3rmax Cool point! |
This thing is a must have for use during development with .main {
/*! keep */
}
.loading {
/*! keep */
}
.button {
/*! keep */
}
.form {
/*! keep */
}
|
@garkin What's your reasoning / use-case for writing out your selectors like that with CSS modules? |
Otherwise they would be import * as React from 'react'
import * as cx from 'classnames';
import css from './home.less';
export class Home extends React.Component {
render() {
const isLoading = true;
return <div className={cx(css.main, {
[css.loading]: isLoading
})}>
Home
</div>
}
} This leads to the runtime exceptions and ruins hot module replacement. Preventing selectors from removing fixes all those issues. |
@garkin Hmm... isn't the answer just to finish writing your stylesheet? I'm saying it's a problem caused only by this development approach. For example, where I work we use Less and Sass depending on the team, and in our current Sass build setup, empty selectors won't pass linting (the app won't compile). So I've been forced to just change my approach with CSS modules / React. It's really this pattern that's the problem: {
[css.loading]: isLoading
} If you changed to this pattern it wouldn't cause an exception: <div className={`${isLoading && css.loading}`}></div> In your example, you're attempting to define an object property with a name that may be undefined. If you switch the logic, your class can be undefined and no exception will be thrown. |
This so called "finish writing your stylesheet" requires a specific cognitive context and could take a significant amount of a time. It's much easier to be done after scaffolding step with markup and working HMR at hand. This pattern is a dominant and a semi-official guideline to use, it was a part of the React distribution some time ago. return <div className={cx(css.post, sharedCss.frame, {
[css.support]: post.isSupport,
[css.foreign]: showTranslation,
[css.private]: post.isInternal,
[css.cached]: post.status.isLoading
...
})}>...</div> |
CSS-modules is the primary approach to do styles this days and will be only more so in the future. This behavior should be at least avoidable through configuration. |
That's interesting. Re-opening not so much just for that use case but because Less shouldn't be in the business of "cleaning" CSS. The Likely this behavior was created when an empty selector was irrelevant to the browser, but it's somewhat valid that it's not irrelevant as data when you factor in CSS modules. |
Actually, unless someone objects, I think this is safe to implement as an option. IMO it would be Edit: or should it be |
And it's not limited to those only. Also consider things like programmatic access via the CSSOM. I'd say |
I don't disagree, but do you have an alternate suggestion? It seems like a very specific behavior, so sometimes it helps to be explicit. There's nothing stopping it from being |
Should it just be |
I would use:
|
Looks fine for me. |
When we can expect for actual implementation of it? |
@orchidoris PRs welcome! |
Workaround plugin... Adds
For preact with less-loader:
|
Can you add please an options to keep empty selectors, or at least point me at the file where i can add it myself. I need it to ease the styling via firebug.
The text was updated successfully, but these errors were encountered: