LESS/SASS CSS opposite from minification/optimizations?

I wonder can I say that LESS/SASS CSS "pre-processors(I think they are called?)" is the opposite from optimizations like minification? I wonder if there will be any noticeable performance impact? or do you think easy of development is more important?

I ask this because what LESS CSS generates is something 开发者_Go百科like

body #div1 #div2 p
body #div1 #div2 p a:link, body #div1 #div2 p a:visited
...

and I think it can really bloat up my CSS quite a bit. as you can see, such specificity is not required and it makes reading CSS hard (at least what I see in firebug).

---

In Sass you can control 'specificity bloat' by understanding how nesting works. You don't have to do any nesting at all if you don't want - it's something you can control.

Using the new @extend directive, you can actually reduce redundancy in your CSS by applying the priciples of OOCSS and can thus improve performance. Here's a good article to get you started with @extend. And a few more OOCSS resources:

• http://www.stubbornella.org/content/category/general/geek/css/oocss-css-geek-general/
• http://wiki.github.com/stubbornella/oocss/faq
• http://oocss.org/

The great advantage of @extend in Sass is that it takes the manual effort involved in applying OOCSS and makes it wonderfully painless and easy.

Finally, as Andrea pointed out, Sass has a variety of options for minifying CSS (see the :compressed style), so overall you've actually got a pretty potent toolkit for not only improving your performance as a developer, but also improving the performance of your CSS. For an example of this in action, see how Chris Eppstein, author of Compass and core contributor of Sass, refactors the Digg stylesheet down from 125 lines of code to 85 lines of code (a 32% reduction).

---

You'd be surprised, but gzipped CSS files that have repeated blocks of code shouldn't be too much larger than ones with the shorter selectors.

This is thanks to how the compression algorithm handles duplicate strings in a file. Instead of including the same string twice, it replaces the second occurrence with a reference to the first one, and so that string only appears in the compressed file once. Take a look at how repetitive the selectors in your generated CSS file are - this should make them compress fairly well.

Naturally, the key to this is making sure your CSS files are gzipped - leaving them uncompressed will definitely increase the file size.

---

Depending on the options, SASS can give output in different styles. For production, you will want to set the output style to 'compact'.

---

There is a firebug addon for sass that should make things easier to read. You don't really need to read the output directly anyway.

Sass, less and xCSS will generate more output but I wouldn't call it bloat.

Hand written CSS, with it's many redundancies and duplications will degrade quickly as developers pile name spaces on top of others during the life cycle of the code. One of the symptoms of poorly maintained, designed or written software is bloat. And because CSS has some design deficiencies from the start, even the best CSS coders are effected by this limitation.

So you got to weigh up the initial footprint of your well formatted sass/less file against a hand written CSS file that has been edited a few times over.

Another benefit on sass is that your HTML becomes leaner. You don't need to append class names throughout your code to make up for the flat, global structure of CSS.