Hacker News Reader

Comment by savanaly | Hacker News Reader

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.

View on HN

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.

OOCSS leads you to technical debt. The bigger you become, the easy you land into techdebt.

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!).

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.

What would you recommend instead of CSS?

Tailwind

… which is a CSS utility class library and thus suffers from some of the same pitfalls.

How about something like Ant Design?

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).

Never been an issue for me. I hear this a lot though, it's probably not for everyone.

> complex selectors that make it ridiculously hard to customize without hacking the source.

This, to me, is a feature. Don’t customise it.

tables

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.

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].

[1]: https://dev.to/carlillo/understanding-itcss-real-case-using-...

[2]: https://www.xfive.co/blog/itcss-scalable-maintainable-css-ar...

[3]: https://www.youtube.com/watch?v=1OKZOV-iLj4

I think the problem is that just not that many people know how to write good css and good JavaScript. So I try and just require them to only know JS.

I think it’s hard to hire lots (…hundreds) of developers who’s going to know CSS well enough to not screw it up.

> Technical debt in CSS seems to be both more inevitable and less problematic than application code

Nicely put. I've stressed over finding unused rules, restructuring, etc. but in the end it never matters as long as it displays correctly.

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.

I believe that Svelte is so natural extension to the current web that - just like with CoffeeScript and ES6 - some of it should be adopted.

Importing HTML files as modules with localized CSS+JS as web components would be one such option for example.

this is called an html module: https://github.com/WICG/webcomponents/blob/gh-pages/proposal...

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.

Points 1 and 2 sound a bit like CSS's new "layer" feature

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?

Layout is the structure of the page, grids, master breakpoints etc. eg. .grid .row .column .banner

Styling is setting colors/fonts/padding etc on a specific component.

eg. .sign-up-form .delete-button .accept-button

> 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.

I already said why in my first comment:

> 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:

https://github.com/sveltejs/svelte/issues?q=is%3Aissue+is%3A...

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.

we call that “fuck it, ship it”

or exceptionally better "Fuck it, we'll do it live"

“Let’s get this working in prod; after that, we’ll back patch it to dev…”

"Git push is prod push"

Brand it FISIcal Project Management.

Deadline Oriented Programming.

I've seen the "it mostly works, ship it and we'll fix it later" approach used. The second part usually doesn't happen of course

Well, do you want a promotion or not?

Followed by "The Production environment is just Big Test"

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.

I like the saying that software isn't released, it's allowed to escape.

> fuck it, ship it

This is a sub-domain of Fuck Users, Ship Excrement, or FUSE-Dev.

It's way better than "Screw it, it probably doesn't work, but we have new projects to work on."

Or my personal favourite: "Screw it, this works, but I'm bored so I'm going to add 3rd party libraries to it until it doesn't work".

> "Screw It, This Works"™ Alliance.

Where is the conference and the website to download a frameable printable "Certified SITW Master" certificate?

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.

I'm a fan of the TFTGAF (too fried to give a fuck) Coding Methodology... Everything else is an anxiety disorder.

If you use "Helps" instead of "Works" (Screw It, This Helps)

Then you can have the SITH Alliance and give out SITH master certifications.

And in 10 years, there would be daily team screwing sessions...

When do we get to write a manifesto?

you are looking at it

It's all fun and games until you drop a decimal and end up in some real trouble fast.

> 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.

Not all problems have to be solved before they become an issue though.

Its often a pointless effort, especially if the problem boils down to "this architecture isn't pure enough"

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?

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.

People think they’re designing a spaceship, when in reality they’re building something closer to IKEA furniture.

YAGNI applies to a lot more than most people think it does.

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).

> real problems start when the complaining ends

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.

Often the complaining ends because the complainer leaves. And now you have two problems.

> 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.

> 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.

That’s fine for your brochureware whatever. Not fine for a line-of-business application meant to be useful for the next decade or more.

I think utility-first frameworks like Tailwind are becoming popular because they allow frontend teams to say "screw it" without descending into total anarchy.

Eh, the successors of those current teams will still curse them and throw it all out when it comes time for a big revision.

Yeah, code written by the people before you is always bad

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.

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.

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.

"Custom Specificity for CSS"

> 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.

The cascade is awesome! See my post further up: https://news.ycombinator.com/item?id=30761462

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.

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

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.

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

I personally like the body:not(#fakeid) trick :-)

You know what I hate about CSS? Having to learn a bunch of "tricks."

So much so that a business with those keywords recently sold for eight figures!

I haven't found that to be the case.

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.

I did not know this, thanks for the tip

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!

This is a really cool tip.

EDIT: Memory was playing tricks on me

no you can't

You are right, should have confirmed that before posting. Old warped memory from ye olden days.

Very cool tip. Do you know if that's an implementation artifact or part of the spec?

It is part of the spec, and is explicitly noted to avoid confusion starting in Selectors Level 3[0]:

> Note: Repeated occurrences of the same simple selector are allowed and do increase specificity.

[0] https://www.w3.org/TR/selectors-3/#specificity

Thanks!

you can also override id selectors with :is

*:is(#a#b, .someclass) {...}

overrides any selector with a single id; you add more ids to override more specific selectors (except inline stiles and !important)

Mind blown. How the hell did I not know this.

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.

[0] https://www.w3.org/TR/selectors-4/#specificity-rules

This, if you understand the CSS rules for specificity, you almost never need to use !important.

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

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

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!

Xzibit Style; Pimp my sheetz

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.

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

hm maybe we need "important levels"?

!important-10 > !important-9 > ...

we need more important stuff!

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

What do you do if you encounter GDPR popups with !important directive? I think we need !!important...

I think if your CSS comes after theirs in the DOM yours will take priority.

Reply on news.ycombinator.com