CSS is mathematics. Each selector boils down to a specificity number. If numbers are equal, the last one applies. If they are not equal, the highest applies, regardless of order.
You could try to use tools like specificity calculator to link selectors to particular numbers but, really, you don't need to.
The general point is:
!important > style="inline rules" > #id > .class > attribute = element
The selector you're trying to override is:
body.jconfirm-noscroll {
some rule !important;
}
This means !important + 1 x class + 1 x element
. You could override it with the same exact selector as long as yours is placed lower in page (parsed later by browser).
Or, to make sure, you could override it with
html body.jconfirm-noscroll {
some rule !important;
}
Or, of course, if you know any other class you have on body, add it to the selector. Or put an #id
on <body>
and use it. It will beat the .class
. But you can't beat body.class !important
with body !important
. That is a certainty.
Important note: There will be cases when you are absolutely certain your selector is stronger, but it still refuses to apply. Don't dispair. It happens to us all. From experience, it falls down in any of these cases:
- you have a syntax error in a previous rule which disables the one you're currently looking at (check for unclosed braces)
- an even stronger selector applies. please be aware that inline styles (placed in
style
attribute of the element) are actually stronger than #id
s. That's why styles applied via javascript
usually apply. They don't override !important
s, though
- your markup is utterly broken. In rare cases, when your markup is not valid, css doesn't apply because the elements you are looking at are not the elements you think they are for the browser. I'm talking cases of nested
<a>
tags and similar
- if none of the above help, check your selector closely. Check it against the markup, step by step. Make sure it has spaces where it should have and doesn't have where it shouldn't have. I'm considered (by some) a CSS expert but you'd be surprised at how many times I write faulty selectors and it takes me a good minute or two to spot the typo. It has something to do with being human, I guess.