Is there any disadvantage if using universal * selector in CSS in terms of maintenance ?

[jitendravyas]

Like this * {} and this .class-name * {}

In older browsers, I guess performance was a concern which I think not a concern anymore. Is there any other disadvantage of using * selector from the maintenance point of view?

Should I avoid using it completely in the projects?

Edited

There is a Stylelint rule for this https://github.com/stylelint/stylelint/tree/master/lib/rules/selector-max-universal

I'm not sure if I should add this in my project or not.

[keithjgrant]

Nope. Go for it!

There were some reports of it having poor performance in really old browsers (IE6 in particular), but those days are long past

[KittyGiraudel]

No, all fine.

[jitendravyas]

There is a Stylelint rule for this https://github.com/stylelint/stylelint/tree/master/lib/rules/selector-max-universal

I'm not sure if I should add this in my project or not.

[Heydon]

@jitendravyas I'm not sure I understand the performance concern. It should improve maintenance, because it allows you to change single rules for multiple elements. HTH.

[jitendravyas]

@Heydon Isn't a problem too https://css-tricks.com/strategies-keeping-css-specificity-low/#article-header-id-3 ?

[tadatuta]

The disadvantages of any generic selectors are quite obvious — they may affect things developer don't want to affect actually. And as it's really hard to find out what was initial intent when such selector was added, it's almost impossible to refactor or remove it (developer can't be sure there's no elements which need it anymore).

* selector is just the same as global variables in JS: you may use them in your local piece of code but as soon as you want to reuse some parts on other project it's a pain.

[okonet]

General selectors are awful and should be avoided. @tadatuta nailed it and I'm doubling it. Relying on cascade is fine for simple websites but this technique doesn't scale in case of applications. Avoid using them at any cost by having stylelint rule.

[Heydon]

@okonet I'm not going to get into this heavily because I've heard all of these "the C in CSS is terrible" arguments before. But just to say: if you do not use the cascade or inheritance at all, you are writing extremely inefficient code.

The disadvantages of any generic selectors are quite obvious — they may affect things developer don't want to affect actually

In situations where the developer is not certain what they might effect, they shouldn't use them. Your argument is "this spanner is bad because some people use it as a screwdriver".

The idea that certain aspects of CSS are simply bad may be comforting, but it's rarely true. It's an expressive language and can be used in lots of different ways, depending on your markup and your needs.

[thierryk]

I don't think performance is an issue anymore, at least not if you target modern browsers; but the real question is why do you want to apply a style to everything at once? What do you think you'll gain from that?

In my opinion, if you have to un-style something then it means you didn't really think things through. When it comes to writing CSS, my rule of thumb is not to add stuff because I can, but to remove stuff because I should.

I know box-sizing:border-box is now part of most styles sheet out there, but if you think about it, this style is effective on very few boxes across a page, if at all. So ask yourself if it'd not be better to use a class (as we have been using .clearfix for years) for the few times that styling is needed.

If you're alone working on a project then I'd say do whatever you want because then you'd be expecting such generic styling and have only yourself to blame if things don't go exactly as planned. If many devs work on the project, then I think it's better to have the least amount of opinionated styles for generic elements; because for once, you won't have to document it ;)

I'm not saying you should never ever use the universal selector though. There are cases where it turns to be a valuable tool. For example if you have a component embedded inside a page where many of its children inherit styles (from the page, not from an ancestor) you do not want. In this case, you may end up with the example you listed:

.class-name * {}

but this is usually an exception as it should concern components that do not obey the style guide (i.e. third party widget, etc.).

[Heydon]

I don't think performance is an issue anymore, at least not if you target modern browsers; but the real question is why do you want to apply a style to everything at once? What do you think you'll gain from that?

You will have styled everything at once, which depending on the circumstance can be very useful.

In my opinion, if you have to un-style something then it means you didn't really think things through. When it comes to writing CSS, my rule of thumb is not to add stuff because I can, but to remove stuff because I should.

CSS is exception-based. Styling 100 things, then unstyling one, as an exception, is a hugely efficient way of writing. When you think about it, all CSS styles by the author are _un_styles since they are overrides for the user agent stylesheet.

[thierryk]

You will have styled everything at once, which depending on the circumstance can be very useful.

Everything's useful depending on the circumstances. I think I even said that myself and gave an example that kinda "justifies" the use of ""; but notice that my example is scoped. Using `alone applies styles to everything, which includes elements that are not even visible in a document, so what's the point? To me, it just shows a lack of care. I'd have a different opinion if I saw these styles scoped tobody(or else) but it's never (?) the case. Same thing when I saw Jonathan Neal changing the value of the genericbox-sizingstyle toinherit—that showed an understanding of how elements are styled through cascade and inheritance. In other words, using*` alone is just "laziness" but that's just my personal opinion.

CSS is exception-based. Styling 100 things, then unstyling one, as an exception, is a hugely efficient way of writing.

I see this completely differently. The exception is in what you leave out, not in what you have to un-style. Once again, the goal should not be to un-style but having to style. And I think history proves my point since we moved away from the infamous:

* {
  margin: 0;
  padding: 0;
}

For what it is worth, I wrote something years ago about setting versus resetting. It started with that very rule.

[snookca]

CSS is exception-based.

While CSS is exception-based, each additional exception is handled by increasing system complexity. That's why styling 100 things and creating an exception for 1 thing can be seen as a good thing. You haven't increased complexity by that much. It's easy to understand what's happening. Style 100 things and then have 20 exceptions (each needing to rely on document order or increased selector specificity) and it's no longer as easy to understand (or change)—especially with cross-cutting concerns. (Does changing one exception unknowingly change something that you weren't aware of?)

With an object-oriented (aka modular, aka component-based) approach, we simplify concerns to a limited set of HTML. We can do this with Atomic CSS where we define and change styles at the HTML level or do this with modular CSS where we minimize side-effects through selector design.

In SMACSS, for example, I recommend using child selectors to limit scope. Thus, instead of .class-name *, I'd recommend .class-name > *. (Recognizing that this usage depends entirely on the complexity of your component design.) BEM used to (and maybe still does) recommend limiting selectors to just class selectors.