6 ms·

> I couldn't disagree more. The more specific you are the less side affects you'll encounter in the rest of your project. When a project gets incredibly large i

> I couldn't disagree more. The more specific you are the less side affects you'll encounter in the rest of your project. When a project gets incredibly large if your styles are NOT specific you're going to run into a lot of unintended consequences. You can handle 99% of use cases for specificity just nesting classes. Using IDs to settle specificity is the same as bringing an ICBM to a Nerf gun fight. When I was doing front-end development, I spent more time fighting back against overly specific CSS, thanks to IDs (and fellow developers who just sprinkled `important!` on everything until it worked), than struggling because I couldn't get specific enough without IDs.

BinaryIdiot 11y ago
> You can handle 99% of use cases for specificity just nesting classes. Nesting classes can get really messy and I'm not sure that really makes sense to do in "99% of use cases" if the goal is to make something specific. Mixing classes allows you to apply multiple styles onto a single element which can be really handy but using that as the way to target a specific, single element means you can't re-use some of those classes in the same way otherwise you run the risk of targeting more than one element in the same way. Specificity should usually be handled through the cascade and / or IDs; that's what they were meant to do. Classes provide buckets of styles as do IDs and both can be used in the same way with IDs targeting only a single element and not a compose-able one. Ultimately you can specifically target in CSS a variety of ways. Outright saying one way is just wrong or "[an] ICBM" kinda ignores the use cases of the various ways to do it to attempt to force a single answer where I do not think a single answer is satisfactory.