5 ms·

> This is implied in the previous recommendations, but since it’s crucial I want to stress it: Don’t use !important in your code. Ehhhh, sometimes `!important`

> This is implied in the previous recommendations, but since it’s crucial I want to stress it: Don’t use !important in your code. Ehhhh, sometimes `!important` is a good option. I agree that just for the 'quick fix' it's a bad idea, but it can solve other issues beautifully. For example: If you're writing a plugin or some sort of module that will inject a block of styled content in websites whose normal styling you have no control over, and you need to not accidentally let the sites override your own styling, it's a great fit. In that situation, it's used to ensure that your block will display correctly across thousands or millions of websites and not fall victim to some awkward accidental local CSS rule like `#body #content #post strong {}` that some developer thought was a clever idea at one point, but didn't realize the implications of the insane level of specificity that is assigned. (I've seen this happen and the support load that it causes). Far better to have reasonable selectors targeting only your markup, with `!important` so that sites, if they want to, can override your styling, but they just need to be explicit about it. Long story short, rigidly holding to rules like these in /all/ situations can lead to far worse results for your users than taking them with a grain of salt and making educated decisions while understanding the implications.

mkay581 10y ago
I think any training wheels or safeguards against specificity should be left up to the developer, not a plugin. And any issues that come up as a result from their lack of understanding of specificity is that developer's own problem--not yours. No offense, I know you may think of it as helpful, but this type of hand-holding for developers actually makes things worse for programmers and the coding community in general imo.
michaelgrafl 10y ago
Apparently you're at a stage where you get to follow your own recommendations. For the rest of us, not using !important is probably a good guideline.
koolba 10y ago
>> This is implied in the previous recommendations, but since it’s crucial I want to stress it: Don’t use !important in your code. > Ehhhh, sometimes `!important` is a good option. I agree that just for the 'quick fix' it's a bad idea, but it can solve other issues beautifully. `!important` is the GOTO of CSS. In general you're not supposed to use it, but if you do, it makes some things much simpler.
- tambourine_man 10y ago
  I thought of the same analogy while reading the article
  - treerunner 10y ago
    agree
waylandsmithers 10y ago
The only situation I can justify using it for is to override inline styles that jQuery can leave behind in the DOM. Other than that, I haven't seen any legitimate cases for using it to get past the normal specificity rules.
- ratbeard 10y ago
  I use it for 'style classes' that you add to an element purely to get some styling change - for example '.pad-left' or '.text-center'. In this case you may be trying to override a style from a stronger selector like `.table td { text-align: left }`. With style classes you don't run in to the issue of needing to then override the !important rule w/ another important rule - you would just remove the style class.
lojack 10y ago
For junior developers, !important is far and above the most abused feature of CSS. 99% of the time I see !important in code, it shouldn't exist and theres probably a better way. Additionally, once you start using it, it becomes very difficult to refactor out of code. If you've reached the point where you know the right time to use !important, you probably already know its bad and most likely don't need any of this advice.
- treerunner 10y ago
  I agree but only if all front-end aspects your application is 100% built in-house. Otherwise, you have framework styles, 3rd party plugin/library styles, etc. Sometimes you have to lean on !important and it's OK - not something to bug yourself out over.
e12e 10y ago
> In that situation, it's used to ensure that your block will display correctly across thousands or millions of websites and not fall victim to some awkward accidental local CSS rule like `#body #content #post strong {}` Yeah, and possibly break font-size and contrast changes for the visually impaired, if it's not scoped right - break printing ... in general I'd say you're more likely to create an issue than not, using !important.
russelluresti 10y ago
The best use of "!important" is for utility classes. For example, if you want to just have a single class that determines when something is hidden, it's a lot easier to have a ".hidden" class that has "display: none !important" on it that overrides any other display you may have set. Otherwise, you'd need to have a ".Module_hidden" class for every single module or component you have - which is dumb.
zkhalique 10y ago
I am surprised none of the replies (thus far) endorsed the above view, so I will. Yes, if you are building something that should look the same across websites, this is a good idea. Though it's often better to just have your own iFrames and use cross-domain communication, since your plugin will have to do its own authentication and API as well.
dhcar 10y ago
The author does mention that "It is also used a lot when you are including a CSS framework with very specific rules and it’s just too hard to override them." Which seems like a perfectly valid use case for !important. In my experience working with a lot of CSS frameworks there are times where not using !important would make the site too brittle if layout had to be changed. When it comes down to abusing selector nesting vs using !important, use !important.
tracker1 10y ago
Even writing a stand alone module, you can get some weirdness... A module I recently wrote is injected into an element at the end of the body with a specific MyModuleName as the id attribute... all of my rules were nested #MyModuleName .foo, unfortunately, even with a reset for MyModuleName div... there were some things I didn't catch, only because something else in the project it was being embedded in had defined .foo, and properties I didn't think to reset. If you're writing a module, best to prefix each class with some abbreviation. `#MyModuleName .mmn-foo` ... much less likely to clash, still need the `#MyModuleName div` reset, but it's better than dealing with weird integration issues.

mkay581 10y ago

I think any training wheels or safeguards against specificity should be left up to the developer, not a plugin. And any issues that come up as a result from their lack of understanding of specificity is that developer's own problem--not yours. No offense, I know you may think of it as helpful, but this type of hand-holding for developers actually makes things worse for programmers and the coding community in general imo.

michaelgrafl 10y ago

Apparently you're at a stage where you get to follow your own recommendations. For the rest of us, not using !important is probably a good guideline.

koolba 10y ago

>> This is implied in the previous recommendations, but since it’s crucial I want to stress it: Don’t use !important in your code. > Ehhhh, sometimes `!important` is a good option. I agree that just for the 'quick fix' it's a bad idea, but it can solve other issues beautifully. `!important` is the GOTO of CSS. In general you're not supposed to use it, but if you do, it makes some things much simpler.

tambourine_man 10y ago
I thought of the same analogy while reading the article
- treerunner 10y ago
  agree

waylandsmithers 10y ago

The only situation I can justify using it for is to override inline styles that jQuery can leave behind in the DOM. Other than that, I haven't seen any legitimate cases for using it to get past the normal specificity rules.

ratbeard 10y ago
I use it for 'style classes' that you add to an element purely to get some styling change - for example '.pad-left' or '.text-center'. In this case you may be trying to override a style from a stronger selector like `.table td { text-align: left }`. With style classes you don't run in to the issue of needing to then override the !important rule w/ another important rule - you would just remove the style class.

lojack 10y ago

For junior developers, !important is far and above the most abused feature of CSS. 99% of the time I see !important in code, it shouldn't exist and theres probably a better way. Additionally, once you start using it, it becomes very difficult to refactor out of code. If you've reached the point where you know the right time to use !important, you probably already know its bad and most likely don't need any of this advice.

treerunner 10y ago
I agree but only if all front-end aspects your application is 100% built in-house. Otherwise, you have framework styles, 3rd party plugin/library styles, etc. Sometimes you have to lean on !important and it's OK - not something to bug yourself out over.

e12e 10y ago

> In that situation, it's used to ensure that your block will display correctly across thousands or millions of websites and not fall victim to some awkward accidental local CSS rule like `#body #content #post strong {}` Yeah, and possibly break font-size and contrast changes for the visually impaired, if it's not scoped right - break printing ... in general I'd say you're more likely to create an issue than not, using !important.

russelluresti 10y ago

The best use of "!important" is for utility classes. For example, if you want to just have a single class that determines when something is hidden, it's a lot easier to have a ".hidden" class that has "display: none !important" on it that overrides any other display you may have set. Otherwise, you'd need to have a ".Module_hidden" class for every single module or component you have - which is dumb.

zkhalique 10y ago

I am surprised none of the replies (thus far) endorsed the above view, so I will. Yes, if you are building something that should look the same across websites, this is a good idea. Though it's often better to just have your own iFrames and use cross-domain communication, since your plugin will have to do its own authentication and API as well.

dhcar 10y ago

The author does mention that "It is also used a lot when you are including a CSS framework with very specific rules and it’s just too hard to override them." Which seems like a perfectly valid use case for !important. In my experience working with a lot of CSS frameworks there are times where not using !important would make the site too brittle if layout had to be changed. When it comes down to abusing selector nesting vs using !important, use !important.

tracker1 10y ago

Even writing a stand alone module, you can get some weirdness... A module I recently wrote is injected into an element at the end of the body with a specific MyModuleName as the id attribute... all of my rules were nested #MyModuleName .foo, unfortunately, even with a reset for MyModuleName div... there were some things I didn't catch, only because something else in the project it was being embedded in had defined .foo, and properties I didn't think to reset. If you're writing a module, best to prefix each class with some abbreviation. `#MyModuleName .mmn-foo` ... much less likely to clash, still need the `#MyModuleName div` reset, but it's better than dealing with weird integration issues.