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.
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.
In my career, I've gone from Waterfall, to XP, to Agile/Scrum methodologies.I've also spent some time doing V-Model. Personally, I'm looking forward to the switch to the "Screw It, This Works"™ methodology. Looking forward to the Addison-Wesley book series!
Edit: I've just founded the "Screw It, This Works"™ Alliance. Sign up today to become a certified SITW Master.
I work in a rather small company, but we are 100% WFH and we span quite a few timezones (From South America to South East Asia). Just yesterday I was summoned at 22:00 to un-fix a small previous fix that had been introduced earlier in the day and was affecting the production site... And the fix was meant "only" for test domains.
The way you earn the certificate is by making it yourself in MS Paint, from one of your other certs and a screenshot of the logo you take from the website.
> So “screw it, this works” seems to be an entirely justifiable methodology.
I've become more aware over the years that some developers, especially very senior ones, are under the fatally mistaken assumption that the problems start when the complaining starts, when it's closer to the truth to say that the real problems start when the complaining ends.
There can be bad developers on any team of course, but there are many developers who know or suspect what they are considering doing is wrong, and discover that asking someone about it is far more trouble than its worth. They either get yelled at or saddled with a bunch of homework because they've drawn attention to a can of worms and are being deputized to fix four things instead of the one they knew about.
Every project has problems. Even the ones that are making millionaires out of relatively new team members. If you aren't hearing about those problems, that's entirely, 100% your fault.
> when it's closer to the truth to say that the real problems start when the complaining ends
Oh, no, when the complaining ends, the problems didn't just start, they reached the magnitude where they are unsolvable long enough ago that no one even harbors any glimmer of hope of fixing or even meaningfully mitigating them.
... yeah... that's a whole row of ice cream flavors of its own. There's depressed despair, betrayed despair (chocolate and vanilla), cold disdain (mint) and red-hots (if I think about this I will get so angry that I will do something career limiting, so I cannot think about it anymore).
I'm still trying to work out how I communicate to someone that the things I have stopped mentioning might still be bothering me, and so fixing the two things I'm actually harping on won't magically make me happy. Maybe that's just something people are supposed to work out for themselves. Mostly I seem to have figured out how to do this when three or more people are involved (basically hand all of my fodder to someone who is still engaged, and let them run with it), but not when it's one on one. Conversations with people who can't 'look at things' can be exhausting, and that seems to hold no matter which party you are.
I really like this quote, and I'm gonna reuse it in a slightly rewritten fashion. In SE teams, indeed, the amount of complacency is directly related to the amount of increasing technical debt.
You know you can acknowledge a problem and that doesn't mean you have to solve it this very instant, right? It's not a matter of either dropping everything or gaslighting people^W^W dismissing the issue as trivial. There are other choices. Many other choices.
If you don't think the problems people are bringing you have merit, then they won't bring you any problems at all, even when they have merit. Suck it up and realize that you're going to have to allocate a little bit of time on "good problems to have" (if this is our biggest problem right now, things are going very well) or you'll either introduce latency into your early warning system or shut it down entirely.
> if the problem boils down to "this architecture isn't pure enough"
Then the problem is that your coworkers think that purity is a magic shield that will protect them from all ills, which is a bigger problem. You still need to hear it, even if you don't like it.
Honestly though a lot of times when I find myself at odds with someone they try to dismiss my concerns as matters of purity when what I'm really complaining about is the smoke that's coming out of the machine (or the team's ears) because they're riding it too hard. Sharpening the saw isn't aesthetics. Preventing wear and tear isn't some white tower bullshit. It's about keeping something in the tank for the next problem we don't know we have yet. People who don't believe in burnout are doomed to create it, usually in others.
Targets of opportunity are problems that have a distinct value in being solved which is less than the naive cost of fixing it.
Not the actual cost of fixing it, the 'drop everything and work on it now' cost, adjusted for Murphy's law. These are often the sort of 'nice to haves' that come out to 3 months of work, which nobody is going to approve unless a customer is actively yelling in their face about it. And sometimes not even then.
Refactoring is Make the Change Easy, Then Make the Easy Change. If you don't know what your targets of opportunity are, because you have some misguided notion that you can't [have an adult conversation about the state of things](https://www.jimcollins.com/concepts/confront-the-brutal-fact...) without tender egos being hurt, then instead of moving toward any of the horizons you'll just sail in a big circle while people keep trying to get you to venture farther afield.
The problem I often see is in the evaluation of the naive cost of fixing it versus the actual probability your target of opportunity will become a legitimate design consideration. The naive cost almost always is large but the probability your target of opportunity will be necessary is often small or miniscule. It's easy to try to cover all your bases and write something in an unnecessarily flexible way when a concrete implementation would have solved the immediate requirements succinctly and very likely may not to be touched again for years (if ever again).
The point of the post isn't that all problems should be given equal credence, but that all problems should be at least acknowledged. Im the end would you rather a Jr. dev who's been working on the project for 6 months be the one who decided whether the problem is important enough to be solved or the Sr/project lead?
> They either get yelled at or saddled with a bunch of homework because they've drawn attention to a can of worms and are being deputized to fix four things instead of the one they knew about.
There is a gradient I've seen with IT workers in general, that is doing IT as a passion and doing IT for a job. Disciplining someone for not knowing enough though is a bit much.
> real problems start when the complaining ends
By this point no one cares anymore and the technical debt is beyond fixing.
I dunno. I know of a project that lingered in this spot for a couple of years before enough people who cared had left to make it a truly lost cause. But there was no leadership to speak of to motivate any of those people, and most of them left. There were points right up until the end where these people were sprinkled across enough of the organization to be a beach head for doing something, but then they lost people on two teams in as many months and from then on it is destined to be status quo. Or at least until they decide to binge on a tech stack update, hire too many people but not for long enough and end up back where they are now. From what I understand they've done that a couple times already.
The big problem is knowing all the places which could be displaying incorrectly when you make a change. This is a fundamental design issue with the cascade: unbounded silent failure because rule activation is implicit.
In addition, there is the difficulty of inspecting those sites which you can identify to verify that display is correct, which is hard to achieve programmatically.
It's not inevitable. I love Svelte partly because it solves the problem by compartmentalizing CSS to the UI component I'm working on. It feels natural that if I write CSS in a file for a component it shouldn't be seen by other components in general.
Even without Svelte, most of the problems people have with CSS go away if you do the following:
- Avoid cascading (i.e. no nested selectors except when there's "no other way")
- Implement separate selectors for styling and page/component layout (separation of concerns)
- Using a good naming convention and stick with it
The first point can also be achieved with using style attributes if that floats your boat, although Svelte kind of gives you the best of both worlds just by compartmentalizing the CSS, not necessarily by preventing cascading.
I can't remember the last time I ever had to use !important except when I had to work with some ridiculous CSS "framework" my predecessors chose to use. At least !important was understandable back in the days when it was really hard to achieve some things with CSS, but these days I believe there's little to no excuse.
Mind telling a bit more on this second part "Implement separate selectors for styling and page/component layout (separation of concerns)"? Are you referring to classes (for styles) and probably id's for Javascript?
Thanks, it looks great. I'm happy that they didn't rush it. They don't talk much about compatibility with current web frameworks, I think they should. I really hope that it will be featureful enough to support being a target for compiling Svelte components (or even maybe React / Vue components) to HTML modules to be imported at some point, but still stay simple enough to be useful.
> I can't remember the last time I ever had to use !important except when I had to work with some ridiculous CSS "framework" my predecessors chose to use. At least !important was understandable back in the days when it was really hard to achieve some things with CSS, but these days I believe there's little to no excuse.
Yep. I find of the usage of !important I see daily is failure of the programmer to understand precedence rules, which, as you pointed towards, is mostly due to cascading.
On the other hand, I find Svelte's handling of this half-baked, as there's no way to pass scoped classes to a component, only to a HTML element. [1] In fact, I find this so frustrating that I have actually given up on Svelte's CSS scoping entirely and I use Tailwind instead, which also solves the same problem by almost [2] completely disregarding the cascade altogether.
[1] Why would you want to do this? Well, what about layout? And what if you have a component that wraps or otherwise behaves like an HTML element?
[2] Of course Tailwind supports modifiers, which do cascade, but everything is still local to a single element.
One of the questions for passing scoped classes to a component is why you want to do it. If you have complex selectors, it would effect the implementation of the component, so I think that would be an anti-pattern. Just modifying the root would be great, but in Svelte I believe one component can translate to multiple root nodes, so all of them would need to get the styles, which again would increase the coupling between the component usage and implementation. I think there's just no clean way to do what you want.
> Why would you want to do this? Well, what about layout? And what if you have a component that wraps or otherwise behaves like an HTML element?
Yes, it's nothing something you'd want to do willy-nilly or all the time, but there are perfectly valid use cases. This issue has been one of the single most-commented in the Svelte repos with tons of back and forth and a lot of demand so this isn't just an obscure complaint either.
As for how to resolve it, there are plenty of clean ways to do it. Svelte's style scoping is done via a unique class per component. It suffices to simply provide some way to pass this class from a parent to a child, for example, and let the child component decide what to do with it. There are many possible variations on this theme. The obstacle to resolving this problem isn't technical infeasibility, it's that to date the maintainers just haven't cared.
> It suffices to simply provide some way to pass this class from a parent to a child, for example, and let the child component decide what to do with it.
Again, the child component can't decide what to do with a class, as it can't know specifics about the parent. It would break the modularity.
I checked the most commented issue, it's about the reactivity system doing only one round of checking in topological ordering, which could be fixed, but could cause infinite loop, and again the problem is not implementation, but deciding on the best design:
Over a lengthy career writing code, I feel like I've gotten pretty good at writing clean, maintainable, legible, changeable code. Especially in the languages I have the most experience in.
I don't feel like I have any idea how to write maintainable legible changeable CSS. Like, it's not just that I can't afford the time -- I just don't know how to do it, despite all my efforts the CSS becomes monstrous, always.
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.
I've come to the conclusion that writing CSS is an anti pattern
I don't think this is true. The biggest problem is people who write CSS do it as if they want CSS to be something else and are trying to force it to be that.
Writing CSS using ITCSS (Inverted Triangle CSS) [1]
solves so many of the issues devs complain about it. It's simple: create layers in specificity order. Don't fight the cascade; make it work for you.
Writing good CSS isn't about getting the syntax right; it's about getting the architecture right [2].
Harry Robert's video does a great job of describing all the pain points ITCSS solves [3].
It must be CSS in the end, but you should create/use a component library, that has the right set of primitives (and less-primitives) that lets end feature developers create the UIs without having to resort to manually write CSS.
THis is made significantly easier when you have designers working with this "design library" mindset also.
Unless something major has happened to it since I used it, Ant uses a giant ball of SCSS with complex selectors that make it ridiculously hard to customize without hacking the source.
Hacking is exactly what we are trying to avoid. Just change the variables to suit your branding and compile the SCSS yourself, just like Bootstrap (which was using LESS but otherwise the same idea).
I think utility-first frameworks like Tailwind are becoming popular because they allow frontend teams to say "screw it" without descending into total anarchy.
I used to work with 3 versions of a whole css system co-existed. To unfuck css debt is like to do surgery, make it done quick or you have vein spaghetti bleeding .. while is also running service.
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!).
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 {}`)
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.
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. :-)
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.
> 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.
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 ...")
Pemberton is one of the OG designers of the spec. He explained the motivation for the feature when it was designed in committee. It's a much bolder claim to say that because you find it useful in some other way, it's not misuse.
If you have a specific case where you think it shouldn't be considered misuse, I'm sure he'd be happy to explain to you how it should be avoided. He's a friendly guy. But you did not design CSS. He did, so you fundamentally misunderstand that the burden is on you to prove there are cases where !important cannot reasonably be avoided, not the other way around.
When anybody says "Everything else is misuse" that is a very large claim because "everything else" includes very many things. Thus the burden is on them, or you, to give evidence to such a broad claim, if you want us to believe that the validity of such a claim.
I don't have a burden to prove anything since I'm making no claims except saying that whoever makes a broad claim should offer some evidence for it. The broader the claim, more evidence is needed, to convince your readers.
The evidence is that he was one of the designers. You seem to be missing the very simple fact that CSS is has not always existed, and it was not suddenly discovered by programmer explorers, whose prerogative it is to define its usage by their usage. It was designed by a standards body. Of designers. The designers designed the usage, and it's the designers' prerogative to define mis-use.
That's not what it means at all. It just means you find it easier to work outside of the spec's design. He's very clearly saying that if you are doing that, it's always possible to avoid it and work within the intent of the spec instead. If you're happier working outside of that, good for you. The "logistics" of you needing to get your work done has no bearing on what the designers of the tools you're using intended.
> He's very clearly saying that if you are doing that, it's always possible to avoid it and work within the intent of the spec instead.
No, he very plainly (almost literally) said that if the tool isn't used exclusively in the way that he imagined, then you don't understand what you're doing. It was a blatant attempt at belittling a community which has been forced to tirelessly work around CSS's terrible spec for decades.
> The "logistics" of you needing to get your work done has no bearing on what the designers of the tools you're using intended.
You have this completely backward, and you may think you're defending Pemberton, but you're actually making him look more elitist and foolish by highlighting why the real world is different from the spec.
Implementations of CSS have been an absolute disaster since day one, and that is largely because of early design mistakes that did not account for countless scenarios and necessary functionality, making interfaces extremely difficult to both build and test, and forcing browser developers to create their own solutions over decades. A lot of those have been "fixed" by adding completely new methods (flex, etc) to replace the broken concepts, but that doesn't automagically make the original bad spec any better, which to this day still makes everything in CSS more difficult than it needs to be.
If a designer is not factoring in those real-world elements, then they have completely failed at their task, because the real world is the part that actually matters -- everything else is an ideological theory.
I second that. Well said. Trying to get something look like you want with CSS takes too much time. If you know what you want it should be easy but it takes a lot of trial and error. Because of that we now have Flexbox and Grid. The problem with all the new add-ons is the amount of stuff you must learn and remember about how they work and how they work together, or don't, to get the results you want.
Then to hear from someone that the problem is "You don't understand the cascade" is annoying. The question is why don't I understand the cascade? The answer is because it is complicated, and it's not only about understanding it in principle but about then understanding its effects on your (current state of) application, and how you should or could change the cascading elements and or where they are defined to make your app look like you want.
And then the answer is perhaps: "Clearly you don't understand it but it is really easy" -- implying it is difficult for you because you are dumb or lazy and not a very good developer in general. Give me a break :-)
I wonder if it would help if the !important -feature should in fact be extended so you could have !important2, !important3, etc. with increasing levels of importance. That might make things easier, in practice. Or even better make it work like "z-index" does. If z-index can take on any numeric value including negative ones, why not have the same with "importance"?
That would mean that instead of having to calculate the "specificity" in your head, correctly, to understand what is happening with your app, you could just choose the specificity you want and make it part of any rule whose impact you want to differ from the default.
> The question is why don't I understand the cascade? The answer is because it is complicated ...
This is exactly his point! You think it should be correct usage because "CSS is too complicated." Great, good point, most of us would agree that CSS is too complicated. But that does not make it correct usage! It only means CSS is so complicated most people don't use it correctly. A majority of people misusing something doesn't make it correct.
I would have assumed with the level of pedantry that is standard on HN, more people would understand this. But I think in this case the power of fragile egos has overwhelmed pedantic instincts.
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.
"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.
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.
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.
Wow, I've been doing CSS for a very long time, and had no idea about repeating the selector to increase specificity. That'll come in very handy, thank you!
But that only works if you only need to increase "class-level" specificity. If you're trying to overwrite a style set with IDs, you're gonna need to either use IDs yourself or use !important. Sometimes you may not want to use IDs.
Right—you can do the same thing with ID selectors, they just always have a higher specificity because they are in bucket A[0], whereas virtually all the other selectors are in bucket B.
If you really have to select that element by ID for some reason, you can use an attribute selector instead—`[id=foo]`—and then it’s also in bucket B and can be controlled in the normal way.
Basically, you should consider ID selectors (and element selectors) an antipattern and never use them.
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
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
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.
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.
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...
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
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.
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!
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.
> 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.
I think one concept that's slowly coming into focus for me is just how many engineers want you to experience _their_ experience and spend your time reveling at how clever _their_ stuff is. As if they think you wake up and want to do CSS work. CSS is not the goal. The website I'm building isn't even the goal. The goal is to solve some problem.
Everything that I have to do to solve that problem is an unfortunate (but inevitable) reality. But let's be clear: the goal is to minimize as close to zero, how much time you have to spend doing these things.
CSS, like all code, is a total liability. I want to spend as little time designing and writing it as possible. Which is why I hate CSS: it demands you know the exact current and future (hahahaha) structure of your webpage. `!important` is not some panacea, but I cackle at the ignorance of suggesting that the user is wrong for misusing it.
Boy this is exactly how it felt to me as a junior. I was just sure it was the fault of everyone else’s configuration that was the problem, not mine. The hardest lesson a junior has to learn is that the customer is always right. No one cares if your program runs perfectly on your machine, because of course it does, it has to run perfectly on every machine.
but you also have instrumental goals, like you don't want to relearn how to reinvent the wheel every time. you don't want to figure out from first principles every time how to transmit style information next to HTML in a concise way, to apply that to the DOM, etc.
hence the tools of the trade.
and there's an endless iteration of this problem. that's why every new version of each tool helps to do certain things faster, in an easier way, with less code. usually tools focus on trendy things, and as a consequence other things usually become harder to accomplish with the tools (simply because the tools become more complex, their documentation becomes bigger, etc)
there are certain abstractions that are very powerful, work well, sort of simple to grasp and compose (Turing machines, loops, map-reduce, structural pattern matching, types / interfaces, distance vector routing & IP addresses)
and the cascade is somewhere along the spectrum of tools.
sure, it's far from perfect, but learning the basics is okay, it gets the job done, so it's a quite expressive tool.
The problem is that people don't treat css as code. If you use styled components or css in js you'll treat it as code.
Nobody would change private properties in a js class from outside that class. Same to css, you should not change css attributes from parents. Those are private to their component they are rendering.
If you need that, provide a public attribute to the component and he'll change it's design.
What's the source for this, I do see they're the CSS co-designer, was this requirement originally written somewhere? I'm looking at the description of important, and I don't see this intention carried through.
If the intention is indeed as described, then the CSS designers failed to communicate it properly, and not "a sign you may not understand the cascade properly."
> or a pompous person trying to make other devs feel inferior
This is how I felt reading it as well. IMO Steven should exercise a little humility.
It was bad design on his team's part. How is anyone supposed to know that there was only one super secret reason for "!important" to exist? Why not call it something like "!break-cascade-override"? They put an emphasize on making the language look "clean" over real world usability and this is the outcome.
For the same reason we call it "accessible entrance" and not "government-mandated alternative door with ramp." Making the phrase more general is just good design.
But nobody is saying that accessible entrances should only be used for disabled persons and nothing else.
Here, the author is asserting that there is only one valid use case of !important, and that it shouldn’t be used in the general case. If it shouldn’t be used generally, having a general name is bad design.
When you say "If the intention is indeed as described," are you referring to the tweet in the submission? Because it looks like the intention is indeed so described in the links you give:
> This CSS feature improves accessibility of documents by giving users with special requirements (large fonts, color combinations, etc.) control over presentation.
Yeah, I seem to recall it was added in Firefox to solve some browser chrome styling issues, or something like that. Anyone any idea where I got that idea from?
I wasn't there, but putting myself in the headspace of someone who was and may have had to comply with that law: There are things outside of the individual control of the designer that can override everything except !important. The most obvious example is non-!important rules in user stylesheets.
Today it's obvious that overriding a font-size with a user stylesheet is a bit of an extraordinary measure. You're unlikely to have any legal issues based on somebody shrinking your text using one. This may not have been obvious in the meetings in which CSS was being designed: it's plausible that I might think user stylesheets would be all over the place and have unpredictable effects, including shrinking disclaimers or whatever. On the other hand, putting !important in a user stylesheet could've seemed like an extraordinary measure even then.
But again, I wasn't there. I'm just making semi-educated guesses.
Still, it doesn’t make sense why US law makes it necessary to have this feature, but any other business or design requirement wouldn’t make this feature necessary. Surely if the CEO or designer says “this text must be 24px” that’s not any different from the implementer’s perspective as a law which says the same thing. This whole thing doesn’t really add up.
It's different from the implementer's perspective because the implementer can go back to the CEO (maybe indirectly) saying "I can make that work 80% of the time, but it just can't be done for the 20% of users who have expressed a preference to the contrary". In your example the CEO gets the option to say "OK, make it work most of the time". In a compliance situation, the CEO is legally obligated to can the whole project, find someone willing to put the text in a JPEG with the attendant accessibility issues, or some other draconian maneuver.
If you send me a government mandated form, and I scrible on it, you aren't liable for anything. The only potential concern is if the content is deployed through a framework like Wordpress that might add CSS.
If the originally purported intent had carried through to the specifications, it adds up in a sense. If !important overrides indicated an explicitly set formatting/sizing for compliance/legal reasons, implementers touching it without any historical context would know at a glance what it signified and that it shouldn't be touched lightly without explicit approval. And when the implementer updates the stylesheets to use 24px text on a page based on direction from the CEO/designer and the element with an !important override stays at 26px, the implementer can point to the !important override as the cause and confirm if the person requesting the change has confirmed legal/compliance approval to change that one as well. Even if the parties involved in the change (the designer, CEO, or implementer) aren't familiar with the compliance reason for the override's origins, the fact that it's there is a known flag that changes can lead to potential violations and costs/fines and need to be properly vetted for approval.
It would also make it easier to go in and update the stylesheets to comply with changes in compliance/legal requirements, as you can easily search through the styles for !important flags and find all the spots that need reviewed for potential change needs.
That said, its use in practice is completely different than this purported rationale for the flag's existence, and !important is sprinkled so cavalierly in existing codebases to crudely but effectively get a desired effect that the above situation is impossible at this point and the original rationale is moot.
> You're unlikely to have any legal issues based on somebody shrinking your text using one. This may not have been obvious in the meetings in which CSS was being designed: it's plausible that I might think user stylesheets would be all over the place and have unpredictable effects.
Someone predicting "stylesheets all over the place" would have been exactly right, though - practically every single news page on the Internet has questionably-sourced ads, Facebook like buttons, Twitter embeds, and chat/discussion/engagement widgets, all of which have custom stylesheets. The only saving graces come from frequent use of iframes for isolated embeds (which will become less common now with cookie restrictions!), stylesheets well-engineered by well-funded corporations to have every rule prefixed by a custom and dedicated class name for compatibility, and preprocessors and CSS-in-JS that would make that latter approach viable.
Now imagine a world where you're a site operator, !important doesn't exist, and you cannot trust that a site component provider will not install a global CSS rule that will break your legal or branding requirements, with no real way for you to work around it if they do, without unmaintainable specificity boosters for your own components. You simply won't use that site component provider unless it's well-vetted. Which means that there's significantly less innovation on the Internet, because "nobody ever got fired for embedding IBM CSS" becomes an actual thing to think about. !important becomes the escape hatch that the web needs.
>The most obvious example is non-!important rules in user stylesheets.
You are fundamentally unable to force the user to render the text you send them in a particular font size, !important or not. What if they use a text browser and small font size in the terminal?
There is no law for the designer of CSS system. Only the developers who build UI have any liability to comply with the law. As long as CSS allowed them to render the required font-sizes there was no reason for them build breaks to the cascading to "comply with law", perhaps it makes it easier for developers with this feature to comply to the law, but there was no requirement to make it easy .
I don't doubt the explanation but agree it doesn't totally make sense: an !important-set font-size is not really any more "guaranteed" than another one, as it can just be overridden with another more-specific or later-appearing !important style. So you still have to look at all the styles to be sure you're complying, and if you're going to do that then you might as well just not use !important at all.
Though I'll admit that once you have your "mandatory" size style as !important you'd only have to look at the other !important ones to be sure, so there's something to it.
Of course there's lots of perfectly reasonable uses of !important now: dealing with other peoples' uses of !important.
It's hard for me to imagine a website actually managing to comply with such a requirement. Even if you set a font to "12 points" or whatever in CSS, and the browser respects it, will it actually turn up on every screen at exactly 4.2336 millimetres? I don't know if the law actually requires a particular point size, or uses some other definition.
Well, my !important story - at the beginning of 2014 I joined a project that was being done for the Danish government, the JavaScript implementation of NemID which unless you're in Denmark you probably don't know what it is.
Styling in this project was done with a sass compilation to CSS, and it had hundreds if not thousands of !important declarations inside it. It seems the guy who was there before me had set up the import order of the Sass files incorrectly from more specific to less specific to some really super specific couple things on top of it all (most of the code base was in Java using GWT to compile to JavaScript, so as a consequence most of the programmers were Java guys and did not notice this), basically I cut 800kb of CSS out of the build in the first few weeks by restructuring and getting rid of !important declarations (for anyone who knows NemID you can probably see how this was definitely way too much CSS for what you need to render!)
It was my first time consulting, I sometimes thought, man if I could find the guy who did this (who was I'm told a pretty good designer) I could just follow him around and make money cleaning this stuff up! But alas, I ended up having to work for a living.
I mean what I see when I use MitID at my bank is basically 2 screens, I can't remember how many screens we had to make for NemID, I think 16 (at the most) and of course they had to be responsive and support Danish, English, and Inuit (Greenlandic) and work the same across a wider number of platforms than most applications.
So I doubt it has too many CSS issues in comparison? But haven't looked.
on edit: also lots of accessibility requirements of course.
This confirms my suspicion that CSS was designed in an ivory tower.
Despite being a "good developer" cut my teeth in C++ etc always had difficulties with CSS. The mental hurdles required to understand various concepts bore no relation to anything else I had encountered in CS.
I'm sure a notable percentage of my grey hairs are attributable directly to its incredible user-unfriendliness.
I've also lost count of the number of systems/backend guys on this website who hate the frontend world even though they've... Never really done it professionally.
I think because frontend has a reputation for being easier, there's this assumption that if you can do the 'harder' thing, you should be able to pick up JS and CSS pretty easily.
But the truth is, what separates a great frontend engineer from an ok one is mostly knowledge of the history and the ecosystem. The web is a big stack of compromises. Knowing why things are the way they are is one of the only ways to make sense of the frontend. That and just actually doing it.
> what separates a great frontend engineer from an ok one is mostly knowledge of the history and the ecosystem
And here I thought it was related to getting the best result (most value for the user/customer) in a set of constraints such as requirements, team and time...
Exactly. CSS is doing too much. All the decisions seemed to make sense at the time but it all ends up being a clusterfuck. Part of it has to do with everyone having to rebuild HTML/CSS parsers from scratch and the ever changing and evolving nature of the markup.
Just when you think everything is going to be OK you are faced with feeding your document into another parser that isn't at parity with the browsers. A lot of people struggle to build PDFs from HTML where the parser (itext) only understands a certain subset. That nice grid layout you designed? ...throw that out. You need page breaks with common headers and footers? Get ready to commit some really dirty hacks. Should this data be in a div table or a semantic table? Better predict the future.
Why do you need to rebuild parsers from scratch? You can just use Chromium. Want to build a PDF form an HTML page? You can launch chromium in headless mode and tell it to print your HTML. Guaranteed that you will have a good result. I don't understand where you have this problem these days.
Also, nobody really asks you to do complex things with CSS. Unless you use a huge framework (that I tend to avoid, I prefer writing everything from scratch) you don't need too much rules to make a page look good. In 200 lines of CSS you can get a good style for your site.
The problem is that people:
- think that frontend development is easy and have less dignity than other kind of software development
- don't want to spend time learning CSS since it should be simple
- don't know CSS and don't understand it
- use a framework like Bootstrap because they don't want to learn CSS
- complain that CSS is shit because they have to use a ton of !important to make things work
CSS is easy if you dedicate enough time to learn the basics of it, and start to make some stylesheets from scratch without Bootstrap or other shit.
Nobody wants to ship Chromium with their pdf library or application. How do I get a print preview? If I do convince myself to lug around chromium, do I invoke Chromium each time for 1000 PDFs in a batch? Do I want to pay to invoke chromium on a EC2 instance or lambda?
Every document production library that handles HTML (a very popular feature) has had to implement HTML/CSS parsing.
I and many others are using HTML and CSS to declaratively lay out complex , dynamic documents (or trying to at least). Seems to make sense but we have ten more years to go before it's fully solved. Right now it costs serious coin to do it (unless you are releasing FOSS) and it ain't fun.
I find the hardest thing with css is getting it right the first time. If I'm on a project and I can care about css I find I'll end up refactoring classes a couple time before I'm happy.
it's not programming, it's markup for a renderer. it's just a different skillset--people who fiddle with shaders in a blender GUI are better prepared to work with CSS than most programmers. i was great at css when i was 12 but wasn't a half-decent programmer until i was 25
I don't think that's the part that is "ivory tower." It's the attitude of "you should never use this feature that you rely on unless you are doing one very specific thing that necessitates it" as opposed to just saying "let's design it in a way that such things can be done easily and without violating the spirit of the language."
I think it’s fair to say at this point that the “semantic classes with reusable cascading CSS” experiment has lost to local, component-based solutions. Overuse of !important is just another sign of that.
Having “clean” CSS doesn’t have the same benefits as clean, well structured code in other areas. The underlying assumption that you can change the visuals without major surgery to the HTML is basically never true, so if you do put the time in to structure the CSS perfectly it’s often wasted when the design changes a little.
Also (as someone said in another comment) the lifetime of CSS is short compared to other application code and certainly compared to backend data structures and business logic, meaning the technical debt isn’t a huge issue. Iteration speed is often more important.
" The underlying assumption that you can change the visuals without major surgery to the HTML is basically never true,"
I would disagree. I think an amazing amount can be done with CSS alone, but developers never take the time to really leverage the power of CSS.
I think perhaps it's worth making a distinction between web app development, and content, (e.g. marketing, articles, weblogs, personal websites). While there is often crossover between the two I think that CSS was originally designed for styling content, which was the primary use of the web at the time. It fits less well at styling complex interactive component based web applications.
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.
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
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.
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.
> 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
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").
> 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.
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".
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.
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?
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
To be fair, I find many of those replies (by other people, that is) painful to read. Completely missing his point. I'd probably also get a bit annoyed after the fifth person pointed out something because they completely misunderstood what I said.
What is his point? It just reads as blame-shifting. Introduction of an unidiomatic feature into the standard for a particular use case is an acknowledgment of deficiency or incompleteness of the whole standard.
I read his point being that !important used for anything but the original intent is "code smell", and I'm fully behind that. He doesn't imply that you mustn't use it for anything but its designed purpose, I'm sure he is enough of an engineer to know that sometimes you cannot stick to your ideals. He's probably well aware that some people have to rely on frameworks which already use !important, so they have to work around that by using !important as well. None of that contradicts what he says, but it's still a misuse of the feature.
> I read his point being that !important used for anything but the original intent is "code smell", and I'm fully behind that.
It doesn't explain why using !important for the original intent isn't equally a "code smell".
Unless that is smelly too, in which case there are even more questions to answer about why this is the workaround and why you're supposed to use it for the original intent despite that.
We're only hearing about the "original intent" now, via a smug tweet in 2022. It doesn't say much about someone who insinuates people "don't understand the cascade" if they don't follow an undisclosed design spec.
And if they wanted it to be for font size only, they should have made it work only for fonts rather than any property.
the point is it should never been in css in first place. and css works better without it. I think he is frustrated because nobody takes the time to understand the cascade
Unless I'm missing some context it seems like this guy tweeted something intentionally cryptic, inflammatory, and baiting for no apparent reason then got mad when people took the bait?
I would be annoyed as well, however if I tweet this instead of say write a well thought out article/blog with some references then I should expect low quality responses.
How many hours did humanity lose trying to center things in CSS?
How many hours did humanity lose trying to understand if the size of a box is set by the parent or the child?
Why not admit that CSS has been a giant shit show since inception, and that !important is just another crappy band-aid feature in that mess of a toolbox?
I have been designing APIs for 15 years and I know people misuse them all the time. And I know it’s frustrating. I also know when I have been wrong, and if I were in the man’s shoes, I’d rather be sorry that I created that monstrous piece of technology rather than blaming the millions of developers who just didn’t find any other effing way than to set !important on a random property.
The only problem with CSS is that a lot of people use it without understanding the basic rules of the cascade.
!important is just one thing another thing is that you shouldn't use ids as in id="myId" for styling because an id has too much weight compared to tags or classes. The only way to override a styled id is with another id - and at this point everybody should realize that no thing should have two identification-tags!
CSS is beautiful and extremely logical. I can very much recommend the book "CSS in depth" by Keith J. Grant - by reading this you go from asking CSS questions on Stackoverflow to answering them.
edit: just to make clear I made the same mistakes for years.
I think in this scenario it is supposed to match all div.legal elements. The styles are then applied with the highest priority, thus overriding other rules.
That gives you a specificity that should override everything else. Would only be a problem if some other rule has 3 or more IDs, in which case you can add more here.
I don’t understand the sentiment. If there is a functional requirement that can only be reliably achieved with that hack, doesn’t it suggest that there are other possible functional requirements that can only be reliably achieved with that hack?
After blocking popups on some sites, the scrollbar is dtill hidden, making it impossible to scroll (like on twitter, for example). With the help of !important, the scroll bar can be forcibly turned on by adding uBlock cosmetic filters. Works on per-site basis, but can be added globally, though some sites break a bit, like the top header on Wikipedia starts behaving strangely.
Zapper is a special feature, entirely unrelated to cosmetic filtering. When you zap an element, the element is removed from the DOM, and the zapper code will also look at the DOM to find out if any of the parent elements are scroll-locked, and if so will defuse it with an inline style using `!important`.[1]
As for cosmetic filtering, it's is the hiding of elements using `display: none !important`, so `!important` is also key to ensure page styles are overridden.[2]
Anyone have an idea of which part of US Code would require this? I have a hard time imagining it's that prescriptive about font sizes (especially given that different fonts have different glyph sizes, DPI on monitors results in different physical rendering sizes etc.) Only thing that comes to mind is that Apple court case many years back where the judge told them they had to have a disclaimer on their page in a certain size and color as part of the judgement.
The times I use important is generally to override a framework that is taking precedent, even though the sheet I'm editting is loaded after the framework css. That is 90% of my useage of !important. It may not have been intended for this, but a lot of things in CSS and HTML were never intended for certain use cases that they are now used for. That doesn't mean it is now misused, it just means things have evolved.
The most common use for !important is to override something else marked !important. It’s an interesting situation when getting rid of a feature simultaneously removes most of the need for it.
Sometimes a tool has been invented to do X but people end up using it for Y because it’s so useful. I think "!important" is a good example. Like duct tape being used for much more than attaching ducts.
The ironic thing here is that traditional duct tape should _not_ be used for attaching HVAC ducts together. The adhesive doesn't withstand the temperature extremes, and it has undesirable properties if it catches on fire. UL-listed foil tapes are used for this instead.
It seems like cloth-backed tape started as "duck" tape (as in duck cloth), somehow turned into "duct" tape, and then turned back to "duck" for marketing purposes. It has quite an odd history.
CSS Cascade Layers are now supported by all major browsers and provide a good, standard alternative to !important in cases where you need to override CSS that you can’t easily modify, like stylesheets from a third party CMS or framework, or inherited spaghetti code from an earlier version:
Now supported by the latest version of all major browsers. Seriously, only one version of Safari, Edge, and Android Chrome support it. Expect to use it in a few years when the older iPhones are no longer relevant.
I have the feeling that a lot of these people who are very smart and design things sometimes live outside of the world and don't know mere mortals issues, I might be understanding cascading and important (I don't like to use it either and avoid it), but we need to make sure that we know that we work with some legacy code, as part of a team, some decisions made before us, tight deadlines and pushy managers, I won't use !important, I might understand cascade, but I also don't want to refactor everything everytime I can't use a shortcut, when its simple changes it's fine, when it's not maybe !important + a ticket to refactor in an allocated time is a better approach
The same thing can be said for a lot of things with CSS…
The @media rule was added for one reason only: provide different styles for different media types. It wasn’t intended to be used to make responsive websites. Is using it to make responsive websites an incorrect usage?
That tweet is ridiculous. The World Wide Web was created for one purpose only...serve formatted documents across a network for scientists. Using !important beyond it's intended purpose is called hacking, and has been around since before there were computers. People found use beyond the main purpose of !important, and that's ok...it was a dead end, but that's beside the point.
Never use !important in your production css at all costs. In development, experiment with it all you want...maybe you'll uncover something amazing...in this case, probably not...but better to hack on things than accept what you're given.
The important statement is also useful is you're creating something to slap on some other code you have no control over. Examples of this from my experience are:
- debug tools that hijack the pages style
- quickly testing styles on the browser while coding
- widgets that are injected into client's websites; client's websites can be a mess, and might contain important statements themselves...
- browser themes or custom styles
Sometimes it really doesn't matter that! Important is bad practice, if the alternative would be 5x more verbose and confusing. And honestly I don't care what the father of CSS thinks.
It works nicely if you are debugging CSS via the inspector. But if you start slapping important all over the place you eventually converge towards a code base where a majority (or large number) of classes are using important which takes you back to square one.
Yes, it's by far the most common use of "!" in programming (though newer languages are increasingly using it for various flavours of null/nothing checking too). Javascript just seems particularly relevant here.
I don't do any frontend development other than sometimes tweaking custom stylesheets for sites for use with the Stylish extension. I use `!important` all the time when doing this; a surprising number of sites I try to modify end up having some stuff with in-line CSS on HTML attributes, and that's the easiest way to override it. I don't pretend to think this is an intended use case of `!important`, but I think being able to customize the way sites look in ways that I personally prefer is at least in the spirit of the open web.
Seriously tho, it comes down to dollars and cents and the fact that !important is an option (and not just for font-size).
A client says they’ll pay for 30 minutes, the boss won’t let you go over 15, it’s not like there’s enough time to actually wiggle your way through a CRM to drop the proper CSS, so a little !important in the override inline CSS is what happens time and time again.
Good developers would love to take the time to do things right, but we don’t always have control over these situations and it stinks.
Damn, there are still people believing that you can just express what the intent behind an engineering tool was, and people will only ever use it if it matches that intent?
That would be crazy naive and I hope this person doesn't imply that.
Everybody is on a schedule. People reach for whatever is available. Doesn't matter what was the reason `!important` was added, at all. If it solves a real problem -- especially quickly -- then people will use and abuse it.
CSS !Important is a nice fail safe or safety valve for emergencies. It is good design to have safety valves in a system. Sure, you should not be encouraged to use it under normal circumstances. As with other fail safe features, it is meant for extreme scenarios you can sometimes predict, but more importantly for reasons you CANNOT predict. So this tweet arguing that it is meant for one reason is invalidating why it is good design.
This is how I read it in my head. This also confirms to me that the CSS designers made at least one very obvious error, not appreciating that ! means negation to anyone with a moderate amount of coding experience, and undermines my confidence in the whole language.
Twitter had decided some time ago that it would show me one notification each time I open the website or app. Probably so I feel like there's something happening. It's always a completely random tweet from an account I don't follow and it is so annoying I'm soon going to log out and just live without the few interactions I do at the site.
Cascading only works as intended if you don't have third party styles and if the styling requirements of your application never change. What's funny is that CSS itself is subject to the same problems. It was created to help people add emphasis and layout customizations to text-based technical documents. Now it's used for everything from interactive maps to control interfaces on spaceships.
I get why people hate CSS, but I think the underlying issue is that it's impossible to create software that can gracefully do whatever has been asked of it and will be asked of it in the future. It relates to the whole culture of continuous deployment and rapid iteration... a few people are talking about the downsides, but we haven't really reckoned with them as an industry yet.
Can anyone give an ELI5 to us curious non-webdevs about why !important seems to be A Thing? (As a sysadmin I'll probably never have a practical need for this, but it's always fun learning about the various niches in 'tech'.)
CSS stands for Cascading Style Sheets. The cascading part refers to the fact that when you have a HTML element which is targeted by multiple style rules (e.g. browser defaults, style sheets, inline `style=""` attributes, inherited from a parent element's rules, etc.), there's a well defined priority order which decides which style "wins" and is in effect.
For example, you might define that all body text is black, but then also have a rule that says that if it's a link (an `<a>` element), it's blue. Suppose you want other links to be blue, but the links in your navigation bar should also be black. Can do, just specify `nav a { color: black }` - now rest of the links are blue, except inside your navbar.
This is neat, because with relatively concise notation, you can specify styles for the majority of your site, but can also easily specialize styles when you need to. Compare that to manually setting `style=""` attributes on every single HTML element!
So what's the problem with !important then? !important is #1 in the priority order I mentioned previously, so when you add !important to a CSS declaration, you throw out the first C from CSS. You're saying "I don't care what any other stylesheet or style rule says - ignore them and use this rule". To beat !important, you need to also add !important, and additionally make your CSS rule more "specific" than the other, e.g. `nav a { color: black }` beats `a { color: black }` because it's more specific - "target <a> inside a <nav>".
This becomes very problematic if e.g. a third party component uses !important in its rules. Let's say that third party component's stylesheet overrides all <a> elements to be red. Great! Every single link is now red - including the ones in your navbar. You'll now need to go back to your own rules and add !important there - meaning now you need to use !important in every single declaration to get the C back into CSS.
Not a webdev by profession, but hand-coded a few hobby sites - !important is used as a duct-tape "just do the dang thing" hack if you need to overrule a bunch of the current styling rules and don't want to think too hard about it.
If this was the intention, it's a bit curious the creators of CSS waited a quarter century to share this information. I wait with bated breath for the true purpose of text-decoration to be revealed.
I actually remember it from the time. It was part of the discussion why the page's stylesheet would "win" over a user specified stylesheet when there were conflicts... sometimes things needed to be that way for legal reasons.
Are you referring to "window" the JavaScript object? If so, bear in mind that JavaScript is not a requirement for CSS to work on a page, and CSS creating a dependency on JS would break a lot of things.
IMHO, there is another valid usage: client side css, when a rule is as specific as it can be the !important attribute might be the only way to locally override it.
Tweets like this proves why CSS is so badly designed. It is a bad idea to add a feature only to satisfy random government mandate. The committee should have reflected more and abstracted out and implemented something that was more general and widely usable. Instead they implemented hacks and then required people to do more hacks on the top to get things done.
If you find yourself reaching for `!important`, try doubling up the selector instead:
.someclassname.someclassname {
That will make it one level more specific than just .someclassname, which is usually enough to override styles with a higher specificity, or the same specificity but were loaded afterwards. If it's still not working, add another one!
It's a hack for sure, but definitely the lesser evil.
I feel slightly annoyed TBH. If it was supposed to be used only for fonts why does the system allow using it for (almost?) everything else.
I'd say people understand CSS very well, but sometimes have deadlines and legacy code and don't have time for redoing the system perfectly (just as Steven and his CSS yeah did not)
One nice feature modern frontend frameworks have nowadays is automatic component specific css rules
IIRC in Vue, <style scoped> allows each element of the component to have an data-{id} attribute and every CSS rule is appended with [data={id}] selector so you're guaranteed no CSS rule leaks out and is contained in the same file
Do keep in mind that this does come with a performance cost, especially in larger applications, as attribute selectors are slower than pure CSS classes, at least last time I ran some benchmarks.
> important was added for one reason only: laws in the US that require certain text to be in a given font-size. !important stops the cascade from changing it.
But it doesn't. !important begets more !importants.
Nice to hear the reasoning behind it, but it's a PITA and should never have been added.
To honest, I don't have the time to become a CSS expert so I do what works and I don't worry much about it.
I use "!important" quite a bit because I let users made some choices in the color schemes of the app and using "!important" makes that easy for me to do.
Please, put an id on the HTML element, and a CSS rule targeting that id, rather than use !important. !important really was a mistake and should only be used to counteract other uses of !important you don't have control over.
By default I use that, but I also let users select a CSS file to override that with a color they chose from a list of "themes" I've made.
My themes only change a small bit of what Bootstrap CSS has described in their themes. It wouldn't make any sense for me to do anything more than that because it works works and it's easy for me to implement the change.
What? no, you can override !important many ways, for example # rules take precedence over . rules, so even if you have important in your . it could get overridden. If you obviously add inline style that will also override it, etc.
Recently had to unify looks of pagination rendered by 2 incompatible approaches. There is a chance it could be done in more sane ways but I ended up just spamming some very important css rules and be done with it.
That's fine. It's really not that important what a designer of CSS thinks about how any part of CSS is being used. A guitar player does not confer with the guitar builder about how to play the guitar.
If you are working within another framework such as Wordpress, the !important tag is a lifesaver that allows you override styles you simply cannot change without a lot of effort and understanding.
Is that reason to randomly put it somewhere while under a deadline, find it works, put a //TODO to remind future you to change it later and then forget about it for a year or so?
oh i understand the cascade, but i also have 25k lines of css to deal with and deadlines. Yes, I can track down the full cascade and craft a selector that will specify a rule for just this or that element, or I can slam a !important on there and move on with my life
I don’t know if I’m just stupid. I might be below average. I’ve got a PhD in CS, in a fairly easy area. I’d say I’m about an 8/10 coder. I definitely have a very bad memory and I don’t like big languages as I forget their syntax. Things like C++, Scala.
But… I’ve been writing CSS on an almost daily basis for three years now, after coming to it cold. And it is without doubt what I spent most time on during frontend dev. I use Vue. Occasionally I Google to check some Vue syntax I haven’t used for a while. But I am endlessly googling CSS.
The first thing I look for in a language (probably due to my goldfish memory, or because I’m actually a bit stupid compared to other coders) is a really small set of rules that I need to know to write any program. Lisp or Python easily fall into this bracket. But with CSS, it just seems endless.
There are so many many ways to do the same thing, I find myself making arbitrary choices all the time.
Without doubt though, the cascading precedence part of the design causes the biggest problems. A single component can have its styling defined across many an unlimited number of files. And each bit of styling might be defined with a different selector, meaning when I change something the specificity rule I use might “work” for some properties and not others. The often subtle interactions between parent and child properties are maddening.
Lots of folks might say - well you’re using it wrong, but most decisions are not made by me but rather other people designing frameworks, and given that these problems seem to be everywhere, it seems no one understands how you’re supposed to use CSS correctly. And if that’s the case - well, it has to be a failure to design a good language.
In other places in CS (eg some configuration file systems) where similar specificity and overriding mechanism can be found, the exact same confusion, mistakes, frustration, and time wasting occur. Anyone who has spent a lot of time working with those sort of mechanisms would have said - no, this doesn’t work, we have to simplify this or it will lead to a big mess.
For a long time I gave CSS the benefit of the doubt and assumed I was a complete idiot. After three years, I’m still spending a lot of time “debugging” CSS in Chrome’s dev tools and whilst I may not be super smart I’m fairly sure that the language has failed me. I’ve learnt some tricks, like only use flex box, and delegate absolutely everything you possibly can to a framework, but I’m not much wiser than day one.
I’d love to see someone who really understands PL design to write a replacement for CSS. An elegant design system language. I’m not a PL expert but the sort of characteristics I’d expect would be: concise, not spreading definitions across many files, a very simple or no precedence hierarchy, more akin to a programming language than a configuration syntax, with a type system that enables excellent dev tools and in particular a debugger and sandbox. One telling feature would be that adding new features would almost never mean extending the language, which would remain stable.
The !important syntax is either a bad joke or a tell, because no one with any serious background in language design would choose that syntax.
It's a stylesheet, it was supposed to replace adding styles directly to HTML and using stuff like <font> tags and <center> tags (yes, those were a thing). That's where the cascade is useful, you can put a coat of paint on your existing HTML page without modifying the HTML itself (like https://www.w3.org/StyleSheets/Core/Overview or http://www.csszengarden.com). I don't think people were thinking about components in HTML back then, there was server-side templating with PHP and stuff, but nothing on the frontend.
css "co" designer. that explains a lot. horse by committee.
i find many uses. sometimes you need to override a style coming from an external or to apply a rule globally, you can just use !important and know that it will work regardless of individual specificity in all instances of that selector.
yes, you could override it with specificity but why bother, a hack is a hack
Bragging about "designing CSS" is a bit like bragging you captained the Titanic. I mean, I guess it's impressive, sure, but it's also pretty embarrassing. I've used `!important` many times, as I'm sure many folks did, because CSS just absolutely sucks and it's a huge pain the butt to get it to do what you want. Using `!important` is the equivalent of throwing your hands up in the air and saying "screw it, I wanted to go home 3 hours ago, I'm done."
On a side note, CSS3 being accidentally Turing complete is probably one of the funniest (read: dumbest) things out there.
