I'm used to writing my CSS in nested way(using LESS) something like this:
.some {
.very {
.long {
.selector {
.with {
.high {
.specificity { ... }
}
}
}
}
}
}
Which compiles to this:
.some .very .long .selector .with .high .specificity { ... }
I've been advised that having high specificity in CSS makes rendering in browser slow, is this true?
Well yes.
The order in which a browser reads CSS rules is, from Right to Left, so when you have a selector like .menu .submenu a.something, the browser would first look for all a.something elements in the DOM, then it's parent .submenu and then for parent .menu element.
So yes, having high specificity does slow down the rendering performance of the browser. Here's a good read on this topic.
Also, having hight specificity in CSS can lead to a lot of issues with maintainability. You should resort to using things like BEM that help with maintainability and keeping low specificity.
Yes, but in most (not all but most) real world scenarios not in a way your users will ever detect. Repaints are a bigger problem.
A better reason for shorter selectors is maintainability. In many cases what you're describing is just the "nested because my preprocessor makes that easy, not because we needed it" antipattern.
Ozzie Neher
Full Stack Dev
The way the DOM renders your CSS is basically one big recursive function. So, yes, it does slow it down a bit by having to check for all present selectors before applying your styles.
Here's a decent article I found with a few points about keeping selector specificity down
csswizardry.com/2012/05/keep-your-css-selectors-s…