[forgotmypassw]

I understand that but there surely must be a way to account for that, I'd imagine something like telling the tool to "don't override this section", or "this one overrides that one, but not the other way around" should be an option.

[gotchange]

This where the «!important» flag shines through but it gets a lot of hate in the community but I am seriously not convinced with their reasoning and arguments put forth as they seem not fully aware of the standard order of conflict resolution in dealing with cascading and inheritance in the language.

[d4n3]

> as they seem not fully aware of the standard order of conflict resolution

I'd say it's the other way around - a lot of usages of !important are due to lack of understanding of CSS specificity, usually as a symptom of something else like using IDs in selectors..

If you avoid using IDs in selectors and avoid deep nesting of classes, then overriding styles works as you expect - apply a more specific selector to override the style.

Selector order only comes in to play rarely, and you can structure your files to start with less specific (base) styles first.

I see !important as more of a workaround than a solution, and I don't think it is used as it was originally intended.

[gotchange]

I was talking more specifically from a debugging perspective as most of the frustration and anti-!important sentiment in the community stems from the effort and time taken in the process to fix a layout issue only to find after a half an hour of mental exercise and acrobatics an !important flag was raised somewhere and hence was this unexpected layout behavior.

I'd say that people who debug this way are at fault here not the language itself or this specific methodology followed because the order of cascading and inheritance in CSS is as follows: importance, origin, specificity and finally source order.

So, people who debug layout issue shouldn't jump first to diagnose specificity problems but importance and to lesser extent the origin albeit it's less common now to encounter a prob in this domain, and when everything is clear, you go and inspect specificity and source order.

That's why I am not sold on the complete avoidance of !important when writing CSS but I am of the opinion that you should only use them when necessary when you need to override a certain style in a very specific context and not more.

[d4n3]

Chrome devtools sort selectors by specificity by default and you can quickly see what order the selectors / properties were applied in and what overrided what.

Most of the !important uses I've seen are more due to "Why doesn't this work? Dunno, I'll just put !important on it.."

Since !important only applies to a specific property, it's not that useful for making structured CSS components, and makes it harder to override (using !important again on every property)

I can't think of many cases where using !important would be better than overriding with specificity. Maybe when using 3rd party styles or making styles that are embedded in an external page (e.g. widgets).

[micheleb]

yeah, but the point is that it's very easy to forget about adding these rules because of the very complexity that motivated splitting CSS into several files in the first place