Gilles Vandenoostende

Hi, I'm Gilles Vandenoostende - designer, illustrator and digital busybody with a love of language, based in Ghent, Belgium.

The problem with CSS pre-processors

Miller Medeiros:

I will try to explain the most common problems I see every time someone shows a code sample or I see a project written using any of these languages/pre-processors.

I’ve documented my love for LESS on this very blog many times, but it’s good to see someone pointing out the potential dangers of using them: excessive code duplication and the performance hit associated with over-specific selectors[1]. Be sure to read the full article first, then come back if you want.

Done? Good. Now I’ll ask you: are these problems with pre-processors, or with how people are using them?

If your only programming experience lies with CSS or HTML, then by all means do yourself a favor and stay away from pre-compilers. I know from experience how easy it is to get carried away with a new language. If you’re not careful you could quickly end up shooting yourself in the foot by overcomplicating things.

But if you have a good grasp of plain CSS, you know some object-oriented programming and you understand how your LESS/SASS code will compile to CSS… Why the hell not? You should never see potential abuses by some as a reason to dismiss an entire concept for everyone. Pre-compilers don’t write bad CSS, bad programmers do!


[1] Although unless you’re writing the next Google, Facebook or some other mammoth web-app, I don’t think over-specificity means all that much for performance unless you’re desperate to eek out a precious few milliseconds, of course. It has its effects certainly, but I see it more as a problem hindering efficient code re-use, than with performance. If you find it helps you organize your code so you can more easily find your way, I think it’s a fair trade-off: After all, CPUs will only become faster, while programmer’s brains are pretty much stuck at where they are now. You can always optimize and refactor afterwards, if need be.


The main issue with the “over-specificity” isn’t about performance but maintainability and authoring itself. It will make rules harder to be reused and it gets very hard to overwrite them if needed.

Check this post for more info and make sure to read the presentation at the end of the post:


Posted by Miller Medeiros at December 21st, 2011 at 1:10 pm.

Thanks for commenting!

This is why I love being a webdeveloper: there are just so many ways to accomplish the same result with different combinations of code, which can lead to *endless* hours of discussion ;)

Personally, I’d favor over-specificity over adding more markup (extra classes) as I’m a stickler for mean, lean and clean HTML. But as always, horses for courses – not every project has the same requirements.

Posted by @gillesv at December 21st, 2011 at 1:24 pm.

[…] was linked to this in the comments of my previous post and a lot of the points in this article rang true to […]

Posted by Our (CSS) best practices are killing us » Gilles Vandenoostende : Musings on the nature of Form and Function at December 21st, 2011 at 1:38 pm.

Back to top