When to Use "!Important" to Save the Day (When Working with CSS)

When to use !important to save the day (when working with CSS)

Consider this:

#someElement p {
    color: blue;
}

p.awesome {
    color: red;
}

How do you make awesome paragraphs always turn red, even ones inside #someElement? Without !important, the first rule will have more specificity and will win over the second rule.

When to use !important to save the day (when working with CSS)

Consider this:

#someElement p {
    color: blue;
}

p.awesome {
    color: red;
}

How do you make awesome paragraphs always turn red, even ones inside #someElement? Without !important, the first rule will have more specificity and will win over the second rule.

What does !important mean in CSS?

It means, essentially, what it says; that 'this is important, ignore subsequent rules, and any usual specificity issues, apply this rule!'

In normal use a rule defined in an external stylesheet is overruled by a style defined in the head of the document, which, in turn, is overruled by an in-line style within the element itself (assuming equal specificity of the selectors). Defining a rule with the !important 'attribute' (?) discards the normal concerns as regards the 'later' rule overriding the 'earlier' ones.

Also, ordinarily, a more specific rule will override a less-specific rule. So:

a {
    /* css */
}

Is normally overruled by:

body div #elementID ul li a {
    /* css */
}

As the latter selector is more specific (and it doesn't, normally, matter where the more-specific selector is found (in the head or the external stylesheet) it will still override the less-specific selector (in-line style attributes will always override the 'more-', or the 'less-', specific selector as it's always more specific.

If, however, you add !important to the less-specific selector's CSS declaration, it will have priority.

Using !important has its purposes (though I struggle to think of them), but it's much like using a nuclear explosion to stop the foxes killing your chickens; yes, the foxes will be killed, but so will the chickens. And the neighbourhood.

It also makes debugging your CSS a nightmare (from personal, empirical, experience).

Should I avoid using !important in CSS?

Use !important very, VERY sparingly -- it overrides just about everything, even inline styles, and messes in a less-than-obvious way with the "cascade" of style rules that gives CSS its name. It's easy to use badly, and tends to multiply, particularly when misused. You can easily end up with a element with !important rules that you want to override, at which point you often have to either refactor your styles, or use another !important rule and contribute to the problem.

And once it's spread and you're using it everywhere, you're back up in the same situation you'd be in without it (difficulty in specifying elements specifically enough to override other styles), but you also don't have !important anymore cause everything else is using it too.

When faced with a situation where !important looks appealing -- or worse, one where it's already in use and spreading -- prefer to refactor your CSS if you can. (Frankly, if you need !important outside of a user style sheet, it's usually because your selectors are already way too specific, and/or you're not taking advantage of the C in CSS.) You'd do better to define your basic styles as close as possible to the html or body elements, and when you want to override, use as little specificity as you can get away with. That way, you have plenty of room to make changes. Usually there's a reason you want to override a style, and those cases can quite often be boiled down to a class name, a particular section of the page (read: a particular parent element), etc.

(The only real exception that springs to mind is if the styles you're overriding are effectively out of your control. (If you use a framework that has very strong opinions on how your page should look, for example, you might find it annoyingly difficult to override anything. I've worked with applications that actually inserted their own inline styles, where nothing but an !important rule could override them.) If you don't have full access to the code, overriding and refactoring can easily be more trouble than they're worth. You can use !important to claw back some control, as long as you're aware of the consequences.)

css() function call failing silently?

Found the problem!!

This:

console.log('Desired position - ' + return_to_left + ':' + return_to_top);

Outputs...

Desired position - 448px:2102px;

therefore your variables return_to_left and return_to_top ALREADY have the px string at the end.

Your css call looks like this:

$(this).css('top', '448pxpx');
$(this).css('left', '2102pxpx');

Which won't work! :p Remove the + 'px' from the end of the css calls.

Override Css styling from external css file

If you have access to the HTML, you can do it inline:

<button class="myButton" style="background-color:initial;color:red;" >

Inline styling always takes precedence.

As user32342534 commented below, you can also use the !important flag in css:

<style> .myButton {background-color:initial !important; } </style>

See Also:

When to use "!important" to save the day (when working with CSS)

ngx-toastr, Toast not showing in Angular 7

I was able to make a minimal reproduction of your issue, and I don't see any problems:
https://stackblitz.com/edit/angular-avcidu

Is it possible that you have some custom styles that conflict with the toastr.css styles, or a template that is malformed (an unclosed div, for example)?

Are you using the latest version of ngx-toastr? (9.1.1 at the time of this post)

What does your template look like?

Update:

The previous stackblitz now shows the replicated problem. Here is the link again: https://stackblitz.com/edit/angular-avcidu

Looks like both bootstrap and ngx-toastr use the .toastr class, affecting the opacity property on the toastr div.

This thread has a workable answer: Setting toastr opacity?

The answer therein is to force the opacity to 1. Add this your custom stylesheet:

#toast-container > div {
    opacity:1;
}

And here's the working stackblitz: https://stackblitz.com/edit/angular-gjazzq

lint-staged not running on precommit

Reinstalled husky and now seems to be working. Thanks @mpasko256 for your help!

Will `not` media query save resources when importing css?

Whether or not it will save resources is browser dependent.

From what I have observed, the media query is evaluated at runtime after actually importing the file. You can easily check in the network tabs of the debugging tools if the file is being downloaded or not. This has the most impacts client-side.

opinionated:
For the content of the files, you should make your default.css agnostic of the colouring scheme (more about common stuff) and have a light.css with only changes that apply, and then have another dark.css for the "non-light" theme.

The less you override rules, the better (for your own sake).
Although, unless you have millions of rules, the impact of overriding a rule or adding more rules is close to negligible and is/should be optimized by the browser.

---

Related Topics