>> 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.

I thought of the same analogy while reading the article

agree

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.

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.

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.

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.

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.

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.

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.

> 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.

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.

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.

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.