The problem with cesting CSS with Less or SassDecember 18, 2010
I’m a big fan of using http://lesscss.org/ with all my coding projects (be sure to read my other post for more details on it). It saves time by providing me variables, mixins, and of course nesting rules. Sass does the same thing, but for one reason or another I never could get used to it’s syntax. The problem with nesting, and a problem I see in CSS all too often is over-specificity.
Here’s an example of nested rules in Less:
It’s a simpler way to write out your CSS, but does it really pay off? That depends on how you look at it. On the one hand, it streamlines your code and provides an easy way to determine the structure of the markup that it styles. On the other hand, it’s way too specific when Less parses it out as regular ol’ CSS.
Here’s that same block, but as parsed as plain CSS:
This is a bit of an oversimplification, but it’s easy to see what’s going on here. You can easily rewrite that CSS to be less specific, but just as effective. CSS is most effective when it is just specific enough, but doesn’t overdo it.
Here’s that parsed CSS again, but without the inheritance from nesting:
The problem with this is again one of over-specificity and speed. Browsers read CSS right to left, and the most specific you get, the longer it takes for the browsers to parse your CSS. This isn’t an issue on most sights as the difference is in milliseconds, but for certain circumstances, I can see it being problematic.
Either way, nesting without prefacing selectors with it’s parent rule would be outstanding. Nesting is primarily saves on time and readability, so shouldn’t that be reflected in the output of Less and Sass? Perhaps in future iterations.