4 ms·

“Anything else is probably misuse” is simultaneously true and brushes away all the realities of front end development.

Minor49er 5y ago
A lot of people have been pointing this out in the responses. The author has been defending himself for people misreading his tweet when he should have simply left out that last sentence
rectang 5y ago
It requires discipline beyond the capabilities of many organizations to structure CSS so that it's maintainable. The ubiquity of `!important` is not so much "a sign you may not understand the cascade properly" as a sign that the cascade is a flawed design that falls apart in practice.
- nawgz 5y ago
  Step 1: Write component-based UIs Step 2: Give each component a unique name Step 3: Repeat this principle even for building routes Step 4: your CSS will struggle to clash, no matter how hard you try The cascading is pretty nice actually. Think about using CSS vars... you can dynamically theme apps because of the cascade, by changing just 1 class. there's other nice attributes, and it's true it requires discipline. Just not nearly as much as you imply
  - rectang 5y ago
    When hunting down a function you want to deprecate/remove in your private imperative language codebase, you can probably find all call sites just by grepping — and even if you miss some, in most cases you'll get a hard error of some kind (either compile time or runtime) after removal. But with the cascade, call sites are implicit — and removal, for better and worse, doesn't cause a hard error. All it takes is a single rogue engineer or product manager to mess things up. And then cleaning things up later is difficult because of all the places that have to be inspected.
  - shadowgovt 5y ago
    Step 2 demands there be a way for one developer to control the global namespace. That's completely impractical[0] given inclusion of 3rd-party code and no enforceable standard for imposing step 2 on other developers. (Web components now exist to facilitate this, but of course, web components are relatively recent; most of CSS's history did not support this 4-step process). [0] To be fair, maybe completely is too strong an assertion. I've seen something like it done... A compiler rewrites the CSS selectors and the CSS classes to create a sort of top-level namespace by prepending some garbage per module so that no component can accidentally reference another component. It's not great for debuggability (about as much fun as having to deal with the actual entrypoint names in the binary for constructors and overloads when debugging C++), but it gets the job done.
    - nawgz 5y ago
      > Step 2 demands there be a way for one developer to control the global namespace I mean, I just prepend all my component class names with my library name or a shorthand acronym, so 100% of my styles are like `.NawgzInput {}` or `.NawgzGraphNode {}` I have never seen the limitation to this approach (i.e. the ends of its ability to scale), so long as you don't pick a super generic prefix. So to hear you assert this approach is "completely impractical" to someone who has used it to build their own component library that every application they build is entirely comprised of.. rings hollow
      - shadowgovt 5y ago
        You're basically hand-rolling the prefix-garbage solution the compiler tool I've seen does. That's the best I think we have now. It's not good (i.e. decreases readability), and it's not universal (there are definitely component frameworks out there where the classes are just named "table" and "button").
        nawgz 5y ago
        > You're basically hand-rolling the prefix-garbage solution the compiler tool I've seen does. Except it's incredibly easy to debug and avoids most of your complaints about the solution. Anyways, fair enough, I can confess that there is probably another ideal world that has better viewport styling. But CSS is giving us incredible flexibility, and just like JS, its warts can be worked around very easily and deliver you a powerful, useful, simple set of capabilities.
  - Pxtl 5y ago
    If component-based UIs are such a good idea, maybe the w3c shouldn't have designed literally every piece of the HTML/CSS/JS infrastructure around global namespaces, particularly ones where every declaration is global by default in the case of CSS and HTML IDs. "Global all the things" seems to clash with "component".
BitwiseFool 5y ago
Very few clients care about how "proper" the CSS is behind the scenes. I'd also venture that they would not want to pay for proper CSS (and the expense of expertise that comes with it) when a single attribute would deliver the same end result. !important actually seems like a practical and valuable attribute in this regard.
- datavirtue 5y ago
  It comes in real handy when the css hits about 300k lines. True story.
  - deleted 5y ago
    [deleted]
asjdflakjsdf 5y ago
I hate that the general conversation around !important is simply: "Important is bad. You should never use it". Its more of a belief rather than knowledge at this point. I'd be interested to hearing a good answer as to why one wouldn't use !important on a modifier class such as ".padding-20" or even something like ".full-width". Surely the problem lies with your html composition if either of these classes are being used on an element that does not need them?
- iambateman 5y ago
  It’s a developers version of a “wive’s tale.” Over time, accrued wisdom has turned into a rule of thumb such that Grumpy Old Developers sit around the fire with Young Energetic Developers and say “ya know, child, never use !important, it’s bad design.” The web development industry is getting mature enough to even have this kind of wisdom, which is wonderful, even if (like “wive’s tales”) the principle is overstated.

A lot of people have been pointing this out in the responses. The author has been defending himself for people misreading his tweet when he should have simply left out that last sentence

rectang 5y ago

It requires discipline beyond the capabilities of many organizations to structure CSS so that it's maintainable. The ubiquity of `!important` is not so much "a sign you may not understand the cascade properly" as a sign that the cascade is a flawed design that falls apart in practice.

nawgz 5y ago
Step 1: Write component-based UIs Step 2: Give each component a unique name Step 3: Repeat this principle even for building routes Step 4: your CSS will struggle to clash, no matter how hard you try The cascading is pretty nice actually. Think about using CSS vars... you can dynamically theme apps because of the cascade, by changing just 1 class. there's other nice attributes, and it's true it requires discipline. Just not nearly as much as you imply
- rectang 5y ago
  When hunting down a function you want to deprecate/remove in your private imperative language codebase, you can probably find all call sites just by grepping — and even if you miss some, in most cases you'll get a hard error of some kind (either compile time or runtime) after removal. But with the cascade, call sites are implicit — and removal, for better and worse, doesn't cause a hard error. All it takes is a single rogue engineer or product manager to mess things up. And then cleaning things up later is difficult because of all the places that have to be inspected.
- shadowgovt 5y ago
  Step 2 demands there be a way for one developer to control the global namespace. That's completely impractical[0] given inclusion of 3rd-party code and no enforceable standard for imposing step 2 on other developers. (Web components now exist to facilitate this, but of course, web components are relatively recent; most of CSS's history did not support this 4-step process). [0] To be fair, maybe completely is too strong an assertion. I've seen something like it done... A compiler rewrites the CSS selectors and the CSS classes to create a sort of top-level namespace by prepending some garbage per module so that no component can accidentally reference another component. It's not great for debuggability (about as much fun as having to deal with the actual entrypoint names in the binary for constructors and overloads when debugging C++), but it gets the job done.
  - nawgz 5y ago
    > Step 2 demands there be a way for one developer to control the global namespace I mean, I just prepend all my component class names with my library name or a shorthand acronym, so 100% of my styles are like `.NawgzInput {}` or `.NawgzGraphNode {}` I have never seen the limitation to this approach (i.e. the ends of its ability to scale), so long as you don't pick a super generic prefix. So to hear you assert this approach is "completely impractical" to someone who has used it to build their own component library that every application they build is entirely comprised of.. rings hollow
    - shadowgovt 5y ago
      You're basically hand-rolling the prefix-garbage solution the compiler tool I've seen does. That's the best I think we have now. It's not good (i.e. decreases readability), and it's not universal (there are definitely component frameworks out there where the classes are just named "table" and "button").
      - nawgz 5y ago
        > You're basically hand-rolling the prefix-garbage solution the compiler tool I've seen does. Except it's incredibly easy to debug and avoids most of your complaints about the solution. Anyways, fair enough, I can confess that there is probably another ideal world that has better viewport styling. But CSS is giving us incredible flexibility, and just like JS, its warts can be worked around very easily and deliver you a powerful, useful, simple set of capabilities.
- Pxtl 5y ago
  If component-based UIs are such a good idea, maybe the w3c shouldn't have designed literally every piece of the HTML/CSS/JS infrastructure around global namespaces, particularly ones where every declaration is global by default in the case of CSS and HTML IDs. "Global all the things" seems to clash with "component".

BitwiseFool 5y ago

Very few clients care about how "proper" the CSS is behind the scenes. I'd also venture that they would not want to pay for proper CSS (and the expense of expertise that comes with it) when a single attribute would deliver the same end result. !important actually seems like a practical and valuable attribute in this regard.

datavirtue 5y ago
It comes in real handy when the css hits about 300k lines. True story.
- deleted 5y ago
  [deleted]

asjdflakjsdf 5y ago

I hate that the general conversation around !important is simply: "Important is bad. You should never use it". Its more of a belief rather than knowledge at this point. I'd be interested to hearing a good answer as to why one wouldn't use !important on a modifier class such as ".padding-20" or even something like ".full-width". Surely the problem lies with your html composition if either of these classes are being used on an element that does not need them?

iambateman 5y ago
It’s a developers version of a “wive’s tale.” Over time, accrued wisdom has turned into a rule of thumb such that Grumpy Old Developers sit around the fire with Young Energetic Developers and say “ya know, child, never use !important, it’s bad design.” The web development industry is getting mature enough to even have this kind of wisdom, which is wonderful, even if (like “wive’s tales”) the principle is overstated.