-
Notifications
You must be signed in to change notification settings - Fork 4.5k
Add @important
at-rule
#99
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
Conversation
Wrapping a set of rules with this at-rule will make every single property in those classes !important. I don't intend to use this in core, but it's really useful for folks who want to use Tailwind on top of an existing base of CSS where the non-important versions of our utilities might not be enough to defeat the specificity of their existing styles. Using this at-rule, someone could import Tailwind into their codebase like this: ``` @Important { @tailwind utilities; } ``` ...and then all of their Tailwind utilities would be !important, making it easy to use them to override their existing CSS.
Yay, nice. |
This is exactly what i need. Can you make individual classes important too? something like
|
@iaK yep, should be possible. But IMO safest and most easy is to make all utilities !important. @adamwathan If you want, i can do this one. My first thought was, that it should be a separate package because it will be useful outside of tailwind, too. But since I do not plan to use anything else in the future, I don't care where to implement it. WDYT? |
@iaK I'm not sure I understand what you mean. Can you share what you'd expect the output of this to be?
If you mean you want to be able to control whether certain utilities are important, this PR won't solve that and I don't think we intend to support that soon. It would either be on or off for the entire set of classes. |
@psren After some internal conversations we might be changing how we do this important stuff, possibly moving it to config instead of as an at-rule decorator. If we do keep it as an at-rule though we'll probably maintain it ourselves vs. pulling in a separate package; it's an extremely trivial amount of code. |
@adamwathan thats fine for me :-) I prefer the explicit @rule over a config. |
@adamwathan I want to make only certain utilities important and not have to rewrite them in the important block. So
would produce
Not such a big deal thought. I'm refactoring a bigger site, and I'm worried that something somewhere will break if i make everything important. I'm probably just paranoid :) |
@iaK why would you do that? Utilities should never be overwritten by specitifity. Your example has no benefits at all. .button--blue {
@important {
@apply .bg-blue;
}
} @adamwathan I think that could be a legit use, if you don't want to use !important for all utilities, but you specitivity sucks, or you want to make sure that the object does not allow changing. Could be a nice helper. My reason for the advice "use e.g. /* From tailwindcss */
.bg-red {
color: red;
}
/* user land */
/* "oh, the red of that button is too hard, let's adjust it" */
.bg-red {
color: #f43059;
} This has massive, unwanted sideffect. Maybe I'm going to implement something like immutable-css in my future projects. |
Closing this in favor of the config-based approach in #183. |
1.0 - Replaces text-gray-{} colors
Wrapping a set of rules with this at-rule will make every single property in those classes !important.
I don't intend to use this in core, but it's really useful for folks who want to use Tailwind on top of an existing base of CSS where the non-important versions of our utilities might not be enough to defeat the specificity of their existing styles.
Using this at-rule, someone could import Tailwind into their codebase like this:
...and then all of their Tailwind utilities would be !important, making it easy to use them to override their existing CSS.
This at-rule is processed after generating utilities but before generating responsive variants, so if you make your utilities important, the responsive utilities will automatically be important too.
@psren you'll probably be interested in this one :) I still want to merge your PR for the
screen-utilities
marker because I think it's useful either way, but want to talk over naming with other folks on the team first.