13 ms·

Engineering is doing what you can with what you've actually got. If what you've actually got is an inherited tremendous ball of spaghetti css, a need to change

Engineering is doing what you can with what you've actually got. If what you've actually got is an inherited tremendous ball of spaghetti css, a need to change just one thing on the page, and scant prospects for future changes in the area, then it may be good engineering to use "!important" to make your change over a more complex solution. This is in fact the situation I find myself in at work somewhat often, although luckily I can't recall the last time I had to use "!important". But I wouldn't issue a blanket disendorsement of it.

soperj 5y ago
You should probably use specificity first, then important, just in case you need to over-ride it in the future.
- calibas 5y ago
  This, if you understand the CSS rules for specificity, you almost never need to use !important.
  - thrwy_ywrht 5y ago
    On the other hand, using ever-increasing specificity to emulate !important is about as elegant and semantic as using the hypothetical properties !importanter, !importanterer and !importantererer
    - calibas 5y ago
      Ever-increasing specificity is how CSS works, to call that "emulating !important" is misleading. I'm suggesting using CSS as intended, the cascading part of cascading style sheets, instead of relying on a troublesome override. Edit: Take this example: div {font-size: 60% !important;} If I can't control the order the CSS is loaded, and I can't change that line directly, how do I modify it? Like this: html div {font-size: 70% !important;} The use of !important isn't some simple way of bypassing ever-increasing specificity. In many cases it just makes things more complex.
- have_faith 5y ago
  Being more specific often ends up more tightly coupling your selector to the structure of the DOM. .className { property: value !important; } is more resilient to DOM changes than adding extra selectors to increase specificity.
  - smegsicle 5y ago
    having an id on the top <html> tag and mentioning it in css rules seemed very effective to me- especially when the tag was the name of the page, which is what i wanted to override by anyway
    - debesyla 5y ago
      I personally like the body:not(#fakeid) trick :-)
      - datavirtue 5y ago
        You know what I hate about CSS? Having to learn a bunch of "tricks."
        hallway_monitor 5y ago
        So much so that a business with those keywords recently sold for eight figures!
  - soperj 5y ago
    I haven't found that to be the case.
  - csnover 5y ago
    I’ve noticed many CSS authors don’t seem to know that you can just repeat a selector to increase its specificity. For your example, `.className.className` increases the specificity without adding more reliance on DOM structure.
    - 5y ago
innocentoldguy 5y ago
While I agree with your statement overall, most of the time, using !important just kicks the problematic spaghetti-code can down the road. The CSS eventually becomes un-workable/maintainable. At one place I worked (a subsidiary of NTT), the effort to clean up the CSS and remove all the !important overrides was so time consuming management wanted to make sure it never happened again, so using !important at all would affect our performance reviews. We were expected to fix any bad CSS right away without overriding the default cascading rules.
- rossdavidh 5y ago
  "The CSS eventually becomes un-workable/maintainable..." True that, but sometimes one has already reached that point, and yet must make this change anyway somehow. But I don't recall using "important" in years, so I guess it's not that often.
mattwad 5y ago
One caveat: every time I use !important, there's at least a clear reason why ("X" library is doing stupid stuff) and you could be surfacing this like any other tech debt. Often, 'spaghetti css' is an easy excuse to not even look into what's going on.
- cpfohl 5y ago
  Yup. If you've used important it should be accompanied by documentation. So much of frontend development work is using, adapting, updating, or integrating code you have no control over that it's inevitable to need to use some blunt force on occasion...
blowski 5y ago
Technical debt in CSS seems to be both more inevitable and less problematic than application code. By the time it becomes a problem, either marketing decides on a redesign or the latest frontend lead wants to use a new framework. So “screw it, this works” seems to be an entirely justifiable methodology.
- meerita 5y ago
  OOCSS leads you to technical debt. The bigger you become, the easy you land into techdebt.
  - orwin 5y ago
    OO leads to technical debt in most cases. You can limit it to a narrow scope (interfaces), or you can have objects that wont move or inherit much (bascially if the parents can be replaced by traits), but someday someone will try to be clever and your team will soon enter OO hell. Bonus hell points if you allow third-party plugin in your software (shoutout to Jenkins!).
- madeofpalk 5y ago
  This is why, as someone who loves writing CSS and thinks they're reasonably good at it, I've come to the conclusion that writing CSS is an anti pattern, and if you want teams to quickly build interfaces with a maintainable "frontend styling layer", it should prevent the ability to write css.
  - felipemnoa 5y ago
    What would you recommend instead of CSS?
    - bamboozled 5y ago
      Tailwind
      - 5y ago
edgyquant 5y ago
This can be a slippery slope. I’ve seen projects with an initial nice hierarchy become spaghetti when engineers looking to save time start throwing important everywhere. Not that it should never be used. It’s like gotos in C code. They definitely have a purpose but if you find you’ve implemented more than half of your program control via gotos you’ve probably made your codebase into a horrific mess.
cerved 5y ago
That's a quick fix and I fail to see anything engineering specific about it. The same approach can be applied to any other problem in any other profession. Personally, I'm not a fan of this approach. I also think it's the wrong quick fix. What you want is a rule of increased specificity. Better use a unique id, maybe in conjunction with an element selector. !important rules should be avoided like the plague
galaxyLogic 5y ago
Right, the flaw in this argument: > Anything else is probably misuse, and a sign you may not understand the cascade properly. is that it assumes the cost of changing the "whole cascade" is minimal. And that it would be easy to design an initial cascade which works perfectly for your needs without any changes needed as the design evolves. In other words it assumes the classical waterfall method where the spec and design are complete and never-changing once the "implementation" phase begins. The suggestion is that there is nothing wrong with CSS, only in developers who can not come up with a perfect CSS-design before they start coding. A big problem with CSS in my view is precisely its cascading nature. When you change anything anywhere it can break things in many other places, and there is no good tool as far as I know that would tell you what all can change because of any given change in a single CSS-rule. It is assumed that developers should have such a tool in their brain, and if you don't you are not a worthy developer. :-)
- willseth 5y ago
  Having a good justification for misuse doesn't make it not misuse. And bad tooling and hard-to-understand CSS design might be reasonable excuses to not understand cascades, but the point is valid -- even more valid.
  - bryans 5y ago
    > Having a good justification for misuse doesn't make it not misuse. If there is a good justification for misuse, that would logically mean the original intent isn't applicable to real world scenarios -- which doesn't make the intent incorrect, but it does betray short-sightedness. To claim misuse strictly because it's outside of that extremely narrow original vision, is completely disregarding the actual logistics of front-end development.
    - galaxyLogic 5y ago
      It's a bold claim to say that "anything else is misuse". To prove a claim like that you would have to show how every possible use of !important is "misuse", except when it is for font-size problems. Now maybe it is possible to show that every conceivable other use is misuse, but until we see such a proof we shouldn't just take for granted just because somebody makes such a claim. A better claim would be "I don't see any good reason to use it". Just because one person doesn't see any good reason to use it doesn't mean there isn't one, or two, or three, or more. It is always very hard to prove a negative ("There isn't any such that ...")
MatthiasPortzel 5y ago
One place where I end up using !important very frequently is writing user-styles/extensions for websites. Obviously not a common use case, but it makes me glad that CSS has `!important`. If you're explicitly trying to overwrite another rule that you do not control, `!important` is more idiomatic than the alternative. (If you've lucky enough to have never had to do this, the alternative is adding otherwise pointless qualifiers to your selector, since CSS gives higher priority to "more specific" selectors. e.g `html > body > div {...}` takes precedence over `div {}`)
- lolinder 5y ago
  You can make the qualifiers less silly looking by matching the qualifier you're trying to override exactly. This makes it more obvious what exactly it is that you are overriding, and has the added benefit of only applying in that one place. If you explicitly want to change one element in every place, though, !important comes in handy.
dheera 5y ago
I use !important all the time to get rid of fucking GDPR popups and things like that.
- dorgo 5y ago
  What do you do if you encounter GDPR popups with !important directive? I think we need !!important...
  - dheera 5y ago
    I think if your CSS comes after theirs in the DOM yours will take priority.
DonHopkins 5y ago
Speaking of working with what you've actually got, CSS source code so looks dull and boring, all in the same font and style and format. I want to be able to mark up my CSS sources with HTML tags, and style it with CSS, so it's beautiful self documenting literate code! Imagine how easy and pleasurable to read and understand CSS would be you could simply use CSS in your CSS to format "font-weight: bold" in bold, and "font-style: italic" in italic!
- 3np 5y ago
  Xzibit Style; Pimp my sheetz
underwater 5y ago
That's hacking (or coding), not engineering.
grishka 5y ago
Also, "!important" is a blessing when you're writing a user stylesheet to apply to someone else's website.
More-nitors 5y ago
hm maybe we need "important levels"? !important-10 > !important-9 > ... we need more important stuff!
raxxorrax 5y ago
I agree that you often need to be pragmatic. Not that the keyword is the definition of grace in any way. If you have to overwrite something later you can append it as the last !important gets precedence. I am no web developer and I honestly don't like html/css, even if I use it nearly exclusively for visualization by now. There is so much baggage that you basically have to know to be able to create efficient solutions. Wanted to visualize some data where you basically color small cells in a larger table. I used a HTML table tag and styled it with CSS. Big mistake! It was incredibly slow for something very simple, I had perhaps 50,000 cells. Little did I know about the background calculation of html table cells and I also did not know why no browser version of Excel derivative uses that tag to implement their grid. Of course you can say that everyone knows this. Doesn't change the fact of the severe baggage.
epolanski 5y ago
> Engineering is doing what you can with what you've actually got. Well said. There's also no mention about !important having that specific purpose in the CSS spec, nor the tweet discusses why other already existing solutions would've not fit that use case.

soperj 5y ago

You should probably use specificity first, then important, just in case you need to over-ride it in the future.

calibas 5y ago
This, if you understand the CSS rules for specificity, you almost never need to use !important.
- thrwy_ywrht 5y ago
  On the other hand, using ever-increasing specificity to emulate !important is about as elegant and semantic as using the hypothetical properties !importanter, !importanterer and !importantererer
  - calibas 5y ago
    Ever-increasing specificity is how CSS works, to call that "emulating !important" is misleading. I'm suggesting using CSS as intended, the cascading part of cascading style sheets, instead of relying on a troublesome override. Edit: Take this example: div {font-size: 60% !important;} If I can't control the order the CSS is loaded, and I can't change that line directly, how do I modify it? Like this: html div {font-size: 70% !important;} The use of !important isn't some simple way of bypassing ever-increasing specificity. In many cases it just makes things more complex.
have_faith 5y ago
Being more specific often ends up more tightly coupling your selector to the structure of the DOM. .className { property: value !important; } is more resilient to DOM changes than adding extra selectors to increase specificity.
- smegsicle 5y ago
  having an id on the top <html> tag and mentioning it in css rules seemed very effective to me- especially when the tag was the name of the page, which is what i wanted to override by anyway
  - debesyla 5y ago
    I personally like the body:not(#fakeid) trick :-)
    - datavirtue 5y ago
      You know what I hate about CSS? Having to learn a bunch of "tricks."
      - hallway_monitor 5y ago
        So much so that a business with those keywords recently sold for eight figures!
- soperj 5y ago
  I haven't found that to be the case.
- csnover 5y ago
  I’ve noticed many CSS authors don’t seem to know that you can just repeat a selector to increase its specificity. For your example, `.className.className` increases the specificity without adding more reliance on DOM structure.
  - 5y ago

innocentoldguy 5y ago

While I agree with your statement overall, most of the time, using !important just kicks the problematic spaghetti-code can down the road. The CSS eventually becomes un-workable/maintainable. At one place I worked (a subsidiary of NTT), the effort to clean up the CSS and remove all the !important overrides was so time consuming management wanted to make sure it never happened again, so using !important at all would affect our performance reviews. We were expected to fix any bad CSS right away without overriding the default cascading rules.

rossdavidh 5y ago
"The CSS eventually becomes un-workable/maintainable..." True that, but sometimes one has already reached that point, and yet must make this change anyway somehow. But I don't recall using "important" in years, so I guess it's not that often.

mattwad 5y ago

One caveat: every time I use !important, there's at least a clear reason why ("X" library is doing stupid stuff) and you could be surfacing this like any other tech debt. Often, 'spaghetti css' is an easy excuse to not even look into what's going on.

cpfohl 5y ago
Yup. If you've used important it should be accompanied by documentation. So much of frontend development work is using, adapting, updating, or integrating code you have no control over that it's inevitable to need to use some blunt force on occasion...

blowski 5y ago

Technical debt in CSS seems to be both more inevitable and less problematic than application code. By the time it becomes a problem, either marketing decides on a redesign or the latest frontend lead wants to use a new framework. So “screw it, this works” seems to be an entirely justifiable methodology.

meerita 5y ago
OOCSS leads you to technical debt. The bigger you become, the easy you land into techdebt.
- orwin 5y ago
  OO leads to technical debt in most cases. You can limit it to a narrow scope (interfaces), or you can have objects that wont move or inherit much (bascially if the parents can be replaced by traits), but someday someone will try to be clever and your team will soon enter OO hell. Bonus hell points if you allow third-party plugin in your software (shoutout to Jenkins!).
madeofpalk 5y ago
This is why, as someone who loves writing CSS and thinks they're reasonably good at it, I've come to the conclusion that writing CSS is an anti pattern, and if you want teams to quickly build interfaces with a maintainable "frontend styling layer", it should prevent the ability to write css.
- felipemnoa 5y ago
  What would you recommend instead of CSS?
  - bamboozled 5y ago
    Tailwind
    - 5y ago

edgyquant 5y ago

This can be a slippery slope. I’ve seen projects with an initial nice hierarchy become spaghetti when engineers looking to save time start throwing important everywhere. Not that it should never be used. It’s like gotos in C code. They definitely have a purpose but if you find you’ve implemented more than half of your program control via gotos you’ve probably made your codebase into a horrific mess.

cerved 5y ago

That's a quick fix and I fail to see anything engineering specific about it. The same approach can be applied to any other problem in any other profession. Personally, I'm not a fan of this approach. I also think it's the wrong quick fix. What you want is a rule of increased specificity. Better use a unique id, maybe in conjunction with an element selector. !important rules should be avoided like the plague

galaxyLogic 5y ago

Right, the flaw in this argument: > Anything else is probably misuse, and a sign you may not understand the cascade properly. is that it assumes the cost of changing the "whole cascade" is minimal. And that it would be easy to design an initial cascade which works perfectly for your needs without any changes needed as the design evolves. In other words it assumes the classical waterfall method where the spec and design are complete and never-changing once the "implementation" phase begins. The suggestion is that there is nothing wrong with CSS, only in developers who can not come up with a perfect CSS-design before they start coding. A big problem with CSS in my view is precisely its cascading nature. When you change anything anywhere it can break things in many other places, and there is no good tool as far as I know that would tell you what all can change because of any given change in a single CSS-rule. It is assumed that developers should have such a tool in their brain, and if you don't you are not a worthy developer. :-)

willseth 5y ago
Having a good justification for misuse doesn't make it not misuse. And bad tooling and hard-to-understand CSS design might be reasonable excuses to not understand cascades, but the point is valid -- even more valid.
- bryans 5y ago
  > Having a good justification for misuse doesn't make it not misuse. If there is a good justification for misuse, that would logically mean the original intent isn't applicable to real world scenarios -- which doesn't make the intent incorrect, but it does betray short-sightedness. To claim misuse strictly because it's outside of that extremely narrow original vision, is completely disregarding the actual logistics of front-end development.
  - galaxyLogic 5y ago
    It's a bold claim to say that "anything else is misuse". To prove a claim like that you would have to show how every possible use of !important is "misuse", except when it is for font-size problems. Now maybe it is possible to show that every conceivable other use is misuse, but until we see such a proof we shouldn't just take for granted just because somebody makes such a claim. A better claim would be "I don't see any good reason to use it". Just because one person doesn't see any good reason to use it doesn't mean there isn't one, or two, or three, or more. It is always very hard to prove a negative ("There isn't any such that ...")

MatthiasPortzel 5y ago

One place where I end up using !important very frequently is writing user-styles/extensions for websites. Obviously not a common use case, but it makes me glad that CSS has `!important`. If you're explicitly trying to overwrite another rule that you do not control, `!important` is more idiomatic than the alternative. (If you've lucky enough to have never had to do this, the alternative is adding otherwise pointless qualifiers to your selector, since CSS gives higher priority to "more specific" selectors. e.g `html > body > div {...}` takes precedence over `div {}`)

lolinder 5y ago
You can make the qualifiers less silly looking by matching the qualifier you're trying to override exactly. This makes it more obvious what exactly it is that you are overriding, and has the added benefit of only applying in that one place. If you explicitly want to change one element in every place, though, !important comes in handy.

dheera 5y ago

I use !important all the time to get rid of fucking GDPR popups and things like that.

dorgo 5y ago
What do you do if you encounter GDPR popups with !important directive? I think we need !!important...
- dheera 5y ago
  I think if your CSS comes after theirs in the DOM yours will take priority.

DonHopkins 5y ago

Speaking of working with what you've actually got, CSS source code so looks dull and boring, all in the same font and style and format. I want to be able to mark up my CSS sources with HTML tags, and style it with CSS, so it's beautiful self documenting literate code! Imagine how easy and pleasurable to read and understand CSS would be you could simply use CSS in your CSS to format "font-weight: bold" in bold, and "font-style: italic" in italic!

3np 5y ago
Xzibit Style; Pimp my sheetz

underwater 5y ago

That's hacking (or coding), not engineering.

grishka 5y ago

Also, "!important" is a blessing when you're writing a user stylesheet to apply to someone else's website.

More-nitors 5y ago

hm maybe we need "important levels"? !important-10 > !important-9 > ... we need more important stuff!

raxxorrax 5y ago

I agree that you often need to be pragmatic. Not that the keyword is the definition of grace in any way. If you have to overwrite something later you can append it as the last !important gets precedence. I am no web developer and I honestly don't like html/css, even if I use it nearly exclusively for visualization by now. There is so much baggage that you basically have to know to be able to create efficient solutions. Wanted to visualize some data where you basically color small cells in a larger table. I used a HTML table tag and styled it with CSS. Big mistake! It was incredibly slow for something very simple, I had perhaps 50,000 cells. Little did I know about the background calculation of html table cells and I also did not know why no browser version of Excel derivative uses that tag to implement their grid. Of course you can say that everyone knows this. Doesn't change the fact of the severe baggage.

epolanski 5y ago

> Engineering is doing what you can with what you've actually got. Well said. There's also no mention about !important having that specific purpose in the CSS spec, nor the tweet discusses why other already existing solutions would've not fit that use case.