On CSS preprocessors

Lately there has been a rise in the usage of CSS preprocessors such as LESS and SASS, which makes sense given the simultaneous increase of CSS3 usage. I’ve frequently argued with fellow front-end web developers about whether they should be used or not and I decided to finally put my thoughts in writing.

To start, I can fully understand the advantage of using such preprocessors over vanilla CSS3. I hate listing all the vendor prefixes, and not being able to use variables, mixins or nesting just like the next web developer. All this syntactic sugar can simplify your workflow by a great deal and make writing CSS3 incredibly fun. However, I still refrain from using them, and I’ll explain why below.

Losing track of CSS filesize

When I’m writing CSS, I try to keep the filesize as small as possible. I’m not a filesize hypochondriac, I try to balance filesize and readability and I prefer to err on the side of the latter. I’m not one of those people that will use #000 instead of black just to save a byte and I use lots of indents and newlines (later minification takes care of that). However, in cases when the readability impact is small and the filesize impact is large (and minification won’t help), I will do the optimization.

For example, consider the following case: Let’s suppose you have 3 rules (#foo, #bar and #baz) that will both use the same CSS rotate transformation, among other CSS declarations. Using a mixin is simple (using the LESS syntax in this example):

.rotate (@degrees: 10deg) {
  -moz-transform: rotate(@degrees);
  -ms-transform: rotate(@degrees);
  -o-transform: rotate(@degrees);
  -webkit-transform: rotate(@degrees);
  transform: rotate(@degrees);
}

#foo {
  font-size: 150%;
  .rotate(40deg);
}

#bar {
  background: silver;
  .rotate(40deg);
}

#baz {
  background: white;
  .rotate(40deg);
}

Sweet, huh? And only 370 bytes. However, what the end user downloads is this beast:

#foo {
  font-size: 150%;
  -moz-transform: rotate(40deg);
  -ms-transform: rotate(40deg);
  -o-transform: rotate(40deg);
  -webkit-transform: rotate(40deg);
  transform: rotate(40deg);
}

#bar {
  background: silver;
  -moz-transform: rotate(40deg);
  -ms-transform: rotate(40deg);
  -o-transform: rotate(40deg);
  -webkit-transform: rotate(40deg);
  transform: rotate(40deg);
}

#baz {
  background: white;
  -moz-transform: rotate(40deg);
  -ms-transform: rotate(40deg);
  -o-transform: rotate(40deg);
  -webkit-transform: rotate(40deg);
  transform: rotate(40deg);
}

which is almost double the filesize (600 bytes). It could have easily been this:

#foo, #bar, #baz {
  -moz-transform: rotate(40deg);
  -ms-transform: rotate(40deg);
  -o-transform: rotate(40deg);
  -webkit-transform: rotate(40deg);
  transform: rotate(40deg);
}

#foo {
  font-size: 150%;
}

#bar {
  background: silver;
}

#baz {
  background: white;
}

which at 290 bytes, is even smaller than the first one. The differences would be even bigger if you had to specify a different transform-origin.

Of course you can still do such optimizations when using CSS preprocessors, but since you don’t have the ugliness in front of you and the file you’re working with remains small, it’s easy to forget and just do what’s easy. You lose sight of the big picture. But it’s the big picture (or big file, in this case ;)) that your users eventually download.

Same goes for nesting: Instead of actually putting some thought into the selectors you choose, you can just nest and let the preprocessor sort it out, usually in the straightforward but unavoidably verbose way.

LESS is better in this aspect, since it also offers a client-side version, so the user downloads the small file you wrote, and all the expansion is done in their machine. However, this has the (big, IMO) disadvantage that all your CSS becomes dependent on JavaScript to work and that your users have to download the LESS code, which isn’t that small: 33KB minified which is way larger than most stylesheets (granted, if you gzip, it will be smaller, but this is true for stylesheets as well).

Maintenance woes

Eventually, CSS will start supporting all this sweetness. Tab Atkins has already drafted a proposal and soon Webkit nightlies will implement the functionality. After that, I think it’s safe to assume that within 2 years Firefox and Opera will also implement the (by then) standard and within 1-2 more even IE. Then we’ll need another 2-3 years to be able to start using it (adoption rates of new browser versions will have increased too). This means that in as little as 6 years, we might be able to use CSS variables, mixins and nesting in vanilla CSS. All the code written for today’s preprocessors will eventually have to be rewritten. Maybe even sooner, since when a standard is published, I think it’s safe to assume (or hope) that the new versions of CSS preprocessors will deprecate their old syntax and start supporting and recommending the standard way, effectively becoming polyfills (which I definitely support). So, coding for a CSS preprocessor today feels a bit like building castles on sand.

Debugging woes (thanks to Jesper Ek)

Preprocessors make debugging CSS harder, since the CSS you see in Web Inspectors like Firebug or Dragonfly is not the CSS you wrote. The line numbers don’t match any more and the CSS itself is different. A lighter form of the same problem also occurs with minifiers, but you can delay using them until you’re done with the site. With CSS preprocessors, you have to use them from the beginning if you want to really take advantage of them.

Also, when I develop my CSS, I want to be able to instantly preview the changes in the file by just refreshing the browser. With preprocessors this becomes harder (although not impossible).

Generic concerns with such abstractions

With every new syntax, comes more effort required by someone to start working on our code. We either have to only collaborate with people proficient in the CSS preprocessor of our choice, or teach them its syntax. So we are either restricted in our choice of collaborators or need to spend extra time for training, both of which are nuisances.

Also, what happens if the preprocessor stops being updated? Granted, most (if not all) are open source, but the community’s interest might shift to something else. Many open source projects have eventually died due to lack of interest. And let’s not forget the law of leaky abstractions

Yes, both concerns are valid for every framework, in every language, but at least PHP frameworks or JavaScript libraries are more needed than CSS preprocessors, so it’s a tradeoff is that’s worth it. For CSS preprocessors, I’m not so sure.

Conclusion & disclaimer

I have to admit that even though I’ve read quite a bit on CSS preprocessors and talked with fellow web developers about them, I don’t have hands-on experience with them. Maybe I will change my mind if I actually do so. Besides, I think that if someone uses a CSS preprocessor carefully, with knowledge of the points mentioned above, it can actually turn out to be beneficial. However personally, I prefer to wait at least until they start supporting the (future) standard syntax, whenever that happens.

  • http://twitter.com/flurin Flurin Egger

    I agree very much on the point that it’s hard in collaboration. You need someone to learn another language. And let’s not forget the bugs that a preprocessor might have, debugging becomes a lot more complicated.

  • http://www.facebook.com/people/Jesper-Ek/547281786 Jesper Ek

    Nice article!

    I did try LESS for a big project I was working on, and it wasnt exactly painless. One thing that bugged me most, was that debugging became much more cumbersome. What you see in firebug is not what you’ve written in your stylesheet, not to mention that line-numbers no longer match. Also, at the time I was using LESS it had some problems with advanced selectors (attribute selector and sibling selectors iirc), however that was a while ago so that may be fixed by now.

    Another thing that bugged me was the extra layer of converting .less to .css, yes there are tools to help you with this but those may not be available on all development environments.

    Should probably point out that I do love the ideas of SASS/LESS, variables, mixins, nesting and inheritance – Give it to me now! :)

    • http://leaverou.me Lea Verou

      Great points, I had also thought about the extra conversion layer issue and forgot to write it, but not about the debugging issue. I’ll update the article and give you credit.

  • http://blog.niccai.com/ NICCAI

    Very happy to see this article. I’ve had this conversation many times with my team on why not to use them. For ajax heavy applications, I also prefer to reload only the CSS using Paul Irish’s Refresh CSS bookmarklet. Without this ability to make rapid tweaks, I would go…

    http://paulirish.com/2008/how-to-iterate-quickly-when-debugging-css/

  • http://chris.hamant.net/ Chris Hamant

    Less and the SCSS syntax of Sass are pretty much the same – they both look quite a bit like regular CSS. I’ve seen decent web devs pick up and apply the new features in a matter of minutes…

    The argument about the ‘hand optimizations’ is also kind of a straw man as nothing is stopping you from doing the same thing in less/sass. Once the size of your css files get beyond a certain size I’ll wager that you’d miss places where you could combine selectors and end up with duplicated rules throughout. In this case a smarter preprocessor could potentially do an even better job at combining similar rules. (to an extent – only so much optimization is possible without violating cascade semantics)

    The debugging argument is actually quite a valid concern, but sass/scss at least will include the ‘real’ line# that generated the output as a comment making it easy to track down – https://addons.mozilla.org/en-US/firefox/addon/firesass-for-firebug/ – uses these comments to assist with this problem. Sass,less and compass all have a –watch option that will continually recompile on changes allowing you to nearly immediately refresh the browser to see results (nearly, you’d have to refresh superfast to beat the compiler).

    You are also correct about the slow adoption/uptake of the native versions of these features – but I’ll be happily utilizing less/sass all the while…

    imho these are all valid concerns – but all are outweighed by my ability to use variables (I like to define a _base.scss that defines typography, color variables and mixins used throughout a site), make new patterns and abstractions that I can easily reuse and share with mixins/imports.

    Count me as one of the masses that is sold on the concept. (but maybe I’m just lazy :)

    • http://leaverou.me Lea Verou

      Nice comment, some of the counter-arguments are quite valid.
      As for the hand optimizations, if you read the post more carefully you’ll see I have already replied to what you’re saying.

  • http://twitter.com/molily molily

    You’re totally right in this regard: A preprocessor can’t help you to properly build modular styles. Preprocessor mixins just duplicate your code. Modularization should be the opposite of repeating code. Preprocessors try to implement code reuse on the CSS side. Unfortunately, it’s repeated code after compilation.

    In contrast, efforts like OOCSS try to implement code code reuse on the HTML side with multiple classes. That’s fine as long as you define semantic classes. A naive approach for reusing this code would be a class “rotate40deg” which is used by #a, #b and #c. Of course, this is a purely presentational and violates the separation of semantic markup and styling. So the best approach would be to find a meaningful class name like e.g. .remark given that #a, #b and #c are all side notes.

    A preprocessor won’t help you with these considerations, you need to build a proper module system without using preprocessor mixins extensively.

    Your example is quite simple and it can be solved in a simple way. In reality, the code for #a, #b and #c may be scattered across different CSS files. Probably these modules are not related to each other so you can’t just define a common base module. Of course you could move the shared code of all these modules to one place, but this would foil the whole modularization.

    The Clearfix (Aslett/Gallant et. al.) is such an example. In theory, you should not repeat it over and over again, but define it once:

    .module-a:after, .module-b div:after, .module-c .body:after, … /* thousand selectors */ { content: ” “; clear: both; … }
    .module-a, .module-b .head, .module-c .body, … /* thousand selectors */ { zoom: 1 }

    In practice, you cannot and should not define the code for completely different modules in one single place.

    Some advocate to just use a “clearfix” class in the HTML, but that’s again the separation principle in my opinion. So I’m using the Clearfix as a mixin in SASS.

    // module-a.sass
    .module-a
    +pie-clearfix

    // module-b.sass
    .module-b
    .head
    +pie-clearfix

    Of course this will lead to redundant code eventually. SASS cannot merge these rules into one because this would change the order of the rules and therefore change the cascade.

    Concerning your other points:

    - Maintenance woes

    Well, when time has come, it should be rather easy to write a parser which transforms SASS/SCSS code into CSS with native mixins and variables.

    But writing code for preprocessors is not building castles in the sand. The lifetime of the site is two or three years at most. By the time native mixins are supported, the site will have undergone several redesigns anyway.

    - Debugging woes

    This is probably the most severe drawback. However, preprocessors try to address this issue. As said before, SASS inserts a comment before each rule pointing the the original file and line, and there are browser addons.

    A better solution could be the module files aren’t combined and minified in development mode. But this may introduce inconsistencies between development and production mode.

    - Generic concerns with such abstractions

    I think you overestimate the problem of learning and mastering a CSS meta language. For example, the SCSS syntax is plain CSS but with some additions you don’t have to be familiar with. Mixins and variables are very straight-forward. Not everyone in our company is familiar with different computer languages and formats, but we haven’t experienced any learning problems after switching to SASS. The rules of SASS are very simple and clear.

    - “Wait till there is a standard syntax”

    Even if there is a standard some day, abstractions with different approaches may still arise so developers can chose the most capable tool for their specific goals.

    • http://leaverou.me Lea Verou

      I pretty much disagree about the lifetime of a website being 2-3 years. Maybe in our personal websites, but many clients just pay once and keep the design for a long time, since they can’t afford redesigns.

      As for the standard syntax, I’m pretty sure there will be one in less than a year. Once discussions heat up in the CSS WG, they usually reach a consensus eventually, and in this case we’ll already have an implementation too. And when a standard exists, I find it pretty stupid to use a slightly different syntax just because it feels more convenient and ignore the native functionality implemented.

      Nice comment though, hence the like. :)

      • http://twitter.com/bbttxu Adam Krawiec

        To follow up on Chris Eppstein’s comment with the example you used in this post.

        This SASS: https://gist.github.com/869719 produces this CSS: https://gist.github.com/869721, which aside from the extra .rotate selector, is exactly the same as your optimized version. The CSS also demonstrates another feature of Compass which is generated code can be easily tracked down to the source file when in development environment.

        Like all tools, they’re only useful when you know how to use them correctly…

    • http://twitter.com/chriseppstein Chris Eppstein

      The Sass @extend directive is like a mixin without the code duplication. it re-writes selectors just as you’ve demonstrated here. Here’s a blog post I wrote on the subject: http://chriseppstein.github.com/blog/2010/08/02/sass-extend-challenge/

    • http://twitter.com/theophani Tiffany Conroy

      Mostly I agree entirely with @molily. But please allow me to belabour and illustrate his point about modularity, since I think is it important:

      Regarding: “Of course you can still do such optimizations when using CSS preprocessors, but since you don’t have the ugliness in front of you and the file you’re working with remains small, it’s easy to forget and just do what’s easy”

      True: one should be wary of mixins. If you find yourself using a mixin, you should stop and ask: “What styles do these items share? Why do they share them? i.e. can I label that similarity semantically?” One should ask this regardless of whether one is using a preprocessor or not.

      If #foo, #bar, and #baz have so much in common visually, then perhaps they have much in common semantically. In which case, I would give that common trait a semantic label, and use it as a class name, which I would attach to the item in the mark-up. If you always approach your code this way, the CSS (or SASS et. al.) would always stay slim.

      An example: perhaps #foo, #bar, and #baz are all “remarks” (as suggested by @molily). Then I would put all the shared styles in the class “remark” and have this:

      /* shared styles among all remarks */
      .remark {
      .rotate(40deg);
      }

      /* differentiations between remarks */
      #foo {
      font-size: 150%;
      }
      #bar {
      background: silver;
      }
      #baz {
      background: white;
      }

      and the mark-up would of course be this:



      This approach might make mixins seem almost useless. The benefit one gains from SASS et. al. comes when different semantic items share the same visual vocabulary.* For example, perhaps both “teasers” and “profile images” are to be rotated 40 degrees. THAT is what one should use a mixin for. A mixin allows semantically unconnected items to share a visual vocabulary.

      * or in the case of this specific example, as a shorthand for a rotation of x degrees, which avoids hand-writing all those prefixes, and keeps the code-snippet in one place, for when the syntax changes.

  • Anonymous

    I have an open draft of a post about us using less for our sites, and I agree to most of the above concerns. One thing I would like to add is the inefficiency of the generated CSS. In LESS code like this

    .main_index {
    ul {
    #last {
    font-weight:bold;
    }
    }
    }

    generates

    .main_index ul #last {
    font-weight: bold;
    }

    which is very inefficient code since right to left evaluation should stop after the ID selector.

    • http://leaverou.me Lea Verou

      In that case, why would you nest though?

      • Anonymous

        Clean Code. We start with a controller_action class and nest everything in there. In that case if after some time I come back and need to redesign this particular page I know that every style is in this context. Not sure if it is a bad habit but for 5k+ LOC Less files it keeps things a bit more sane.. :)

        • http://leaverou.me Lea Verou

          I don’t think it’s wrong for the preprocessor to work this way, because #last is not really equivalent to .main_index ul #last and there’s no way for the preprocessor to know if the first would work just as well in your pages.

        • Anonymous

          Haven’t looked at the source of LESS but it should be able to determine if the document has any more specific selectors and work with this information in order to provide as efficient as possible CSS.

        • http://leaverou.me Lea Verou

          In principle, I agree with you that preprocessors should be “smarter”. However, in this particular case, the optimization you want is impossible unless the preprocessor could also look at the HTML (which isn’t really feasible, since it’s usually dynamic). You might be using nesting as a kind of filter (= if #last is not inside .main_index ul, then I don’t care about it) which is quite legitimate or #last would also be fine with you. However, the preprocessor can’t read your mind.

        • Anonymous

          Yes I think I get your point. There is a chance that the pure id selector would be less specific then some other code while the whole expression (.main_index ul #last) would be not…

        • http://www.kaelig.fr/ Kaelig

          Make preprocessors too smart and the developer won’t be able to predict the output at all, making the code unmaintainable.

          See the dilemma?

  • http://www.alsacreations.fr Felipe

    If you don’t use #000 instead of black because minification takes care of that then I don’t see where the problem is with 3 nearly identical rules : minification will also take care of that and create a 4th rule #a, #b, #c { /*lot of things*/ } if there is a loss of weight doing that (?).

    • http://leaverou.me Lea Verou

      I’ve never seen a CSS minifier that does that.

  • Pingback: xhtml css templates – On CSS preprocessors | Lea Verou | XHTML CSS - Style sheet and html programming tutorial and guides

  • http://twitter.com/Vagelis_tj Vagelis Liaskas

    Just popping in to say +1. Couldn’t put it in a better way.

  • evo

    hmm.. not sure I agree that people need to see the ugliness to optimise it. Using preprocessor’s should be something you do after years of using plain css, once you truly know how to optimise css and it comes as second nature then you will always write your css in the most optimised way, regardless of if it’s SASS or normal css.

    In the end I really don’t think people who cannot write extremely optimised css naturally should be using preprocessors at all.

  • Pingback: In defence of CSS preprocessors :: Aaron Russell

  • http://benalman.com/ “Cowboy” Ben Alman

    Why wouldn’t you just define the mixin and then do this?

    #foo, #bar, #baz {
    .rotate(40deg);
    }

    I’m new to SASS/LESS so maybe I’ve missed something obvious.

    • http://leaverou.me Lea Verou

      Hi Ben,
      You didn’t miss anything about LESS/SASS but you did indeed miss a paragraph from my article :)
      I wrote: “Of course you can still do such optimizations when using CSS preprocessors, but since you don’t have the ugliness in front of you and the file you’re working with remains small, it’s easy to forget and just do what’s easy. You lose sight of the big picture. But it’s the big picture (or big file, in this case) that your users eventually download.”

      • http://benalman.com/ “Cowboy” Ben Alman

        Oops! In that case, I’d argue that, as with any tool, people should understand what’s being done for them before using that tool. Knowing that, they can then make smart choices.

        For example, even though the code duplication in the SASS/LESS mixin approach is far less obvious than when the same code is written in plain CSS, it’s still clear that the code is not DRY, because the exact same mixin line is repeated three times. In this case, a suggestion to the coder that they should not use a CSS preprocessor is what should absolutely not be done.

        Why? Because if you start by explaining that any duplication of effort is generally bad, then show how even minor redundancies can be exacerbated with mixins, and support that statement with a look at the resulting “compiled” CSS code, the user will not only have the information they need to avoid this problem in the future, but they might also come away with better understanding of a tool that might save them a ton of development and maintenance time.

        Honestly (and I know this is somewhat subjective), the approach I generally like to see is something like, “You not only CAN but SHOULD use a CSS preprocessor, because it will help you write more maintainable code, faster. That being said, you NEED to be responsible, and understand what’s being done under the hood. Above all, keep your code DRY, and don’t be afraid to look at the generated CSS!”

        Maybe with a word on general attention to detail as well, as that’s something a lot of people don’t quite seem to understand.

        They say “knowledge is power.” They might be onto something!

        • http://leaverou.me Lea Verou

          Hi Ben,
          You make some pretty valid points. However, I didn’t only mention one reason I’m not too fond of them. And I did write that “Besides, I think that if someone uses a CSS preprocessor carefully, with knowledge of the points mentioned above, it can actually turn out to be beneficial.” towards the end, which is essentially what you’re saying ;)

  • http://twitter.com/iPaintCode Mark Learst

    I have been debating switching to LESS for months and this article really convinced me to stay with my current conventions. Perhaps if the LESS compilers would use: “#foo, #bar, #baz {” instead of breaking it all out into their own blocks it may be a much easier decision to take advantage of LESS.

    • http://leaverou.me Lea Verou

      To be fair, they will use #foo, #bar, #baz if *you* write #foo, #bar, #baz. They just won’t do it themselves.

      • http://twitter.com/iPaintCode Mark Learst

        I just wish there was more deep, down and dirty tricks that shed light on CSS preprocessers and their quirkiness. But moving forward I’m going to defiantly bookmark this post for later reference.

  • http://twitter.com/iPaintCode Mark Learst

    Maybe if the preprocessers would rethink how they compile LESS -> CSS and be a little smarter like the: “#foo, #bar, #baz {” example. Though I’m sure it’s not an easy task but I bet it could be done. With that said, I 110% agree with this article, I was on the fence and was debating using LESS for a long time but this makes my decision cake. Thanks!!!

  • Presentation Player

    En of the day CSS preprocessors suck ….. go on the less homepage and turn your javascript off in browser

    • moonunit7

      use lessPHP

  • http://twitter.com/screwlewse screwlewse

    Yeah.. I was in the same boat as you:
    1. This will cause code bloat and I wont see it happening
    2. I wont know where my issues are coming from when checking in Firebug / dragonfly

    However, I did start using Compass / SASS and I found something out.
    1. if you have an issue, talk to the developer of the preprocessor. (likely they are working on a solution)
    2. As you use it.. you find ways around issue 1 and 2

    I am a big fan of OOCSS and SASS seemed so opposite of that frame of mind. ie.. create a mixin, smatter it all over the place and you get repeated code everywhere in the end product.
    However, they were working on a way around that; namely @extend
    @extend comma separates the selectors for one ruleset. ( I wont go further, as Chris’s link goes into detail)
    There are other powerful features of SASS that really bring to light that cliche: “with great power, comes great responisiblity” and I think it really boils down to that.

    SASS is very powerful and it’s up to us, as developers to be responsible and understand what SASS is doing and prevent abusing that power. It’s definitely do-able.

    regarding issue 2:
    I think you will find that having much more readable code means that it’s also easier to maintain and troubleshoot.
    - Syntax problems are a moot point now because the preprocessor catches them during compilation
    - Preprocessors have different compiling formats.. in developer mode it’s verbose, so you can find your problem in Firefox and go to the source very easily. (each rule comes comment and a line number to track in the source file)
    - you may also find that it’s far easier to find problems because SASS code simplifies your work

    As I said, I was very hesitant at first, I was worried about giving over control, to a program that promotes css bloat, but I was definately wrong about that. It gives us more power.

    (I almost passed out when I tried using it’s sprite feature the first time — it sprites the images into one, and creates the background-positions all for you! )

    • http://leaverou.me Lea Verou

      Hi screwlewse!

      All very valid points indeed! As I said at the end, I’m not againist preprocessors per se, as long as they are used responsibly.

      • http://twitter.com/screwlewse screwlewse

        Yep.. and I think that is exactly it! Well, that and the knowledge of how to use them correctly. Because they sure do make it alot easier to create alot of bloat, if yer not carefeul.

    • Craig

      “OOCSS” is a bullshit misnomer.The are no “objects” in CSS.

      • fred

        I understand that Objects are not there in comparison to a fully fledged OO language such as Java, but bare in mind that objects can be theoretical ones which can also have properties and “methods” link:click, link:hover etc.

      • http://www.rauenzahner.com/ Zahnster

        This is because you’re thinking like a classically trained CS major.

        OOCSS isn’t about programing Objects, but more like physical, real world Objects. Like Legos. The goal of OOCSS is to create UI components that can stand on their own and be consistent under any implementation.

  • http://twitter.com/mkoistinen Martin Koistinen

    Hi Lea,
    I have great respect for your work, but I generally disagree with this article.  Mostly because all the skill one requires to make awesome CSS like you, could easily be tweaked slightly in a LESS/SASS environment to overcome ALL of the weakness you are talking about (and more).  But the result would be that this skilled person would have a great deal more power in creating good, efficient CSS more quickly than the non-LESS/SASS-skilled person.When I started using LESS, I probably did all the things you point out above, but very quickly, I realised that I wasn’t thinking about CSS properly in this environment, I needed to rethink some things and now my CSS avoids these without much thought.I use the Less.app for my Mac, so all the conversion to CSS happens at development time–avoiding the issues with the JS client-side runtime–and is done as soon as I press “Save”.  I can immediately see the results in my local browser.  And, since I am freed from being now concerned with how many files I would be sending the end-user,  I can spread my CSS work into logical, discreet files as required, but I still create one, minified CSS file (which even includes my reset.css too).  Or, as I often do, I use the same set of files to create different output CSS files for the different sections of the project I am working on, if their styles vary enough that it doesn’t make sense to plunk it all into one big stylesheet.  All that flexibility is here, just like using (at)imports in your css, but without the drawbacks of extra server requests from each client.And yes, it can be easy to create very inefficient CSS via silly nesting practices, but the beautiful thing is, you don’t HAVE to use nesting, you can still write straight CSS and only use the features of LESS that make sense.The beautiful thing to me is, when I come back to a project after a few months, I’ll actually be able to read my LESS files clearly, with as many comments as I require and get on with the changes I need to make.  Looking back at even older projects and their flat CSS files gets me lost very quickly.My bet is that if you were to adopt LESS or SASS for a short while, you would retract this very article (as you suggest in your conclusion & disclaimer =)  In fact, I’ll bet you’d be even better at what you do after a short while. =)

    • http://leaverou.me Lea Verou

      Hi Martin,

      I didn’t know about LESS.app when I wrote this. I found out about it about a month ago, and I plan to use it too. I think it’s a great idea and it does waive most of the disadvantages I mentioned above if used carefully.

  • http://twitter.com/gestalterblog Marcos Sandrini

    Hi Lea, I know this is a rather old article, but I just wanted you to check out my PCSS project: pcss.wiq.com.br
    It has some different stuff on it, especially when it comes to the first example you gave in this article.

    • http://leaverou.me Lea Verou

      I like the idea! Not sure about the syntax though. 

      I hope you cache those files and don’t re-generate them on every request.

      • http://twitter.com/gestalterblog Marcos Sandrini

        Thanks for the feedback. Cache the files is indeed a very important thing to do.
        I’m working to improve my project on several aspects, but I think our CSS files are sometimes result of personal ways of thinking, ways that sometimes may not fit the preprocessors or that can make some syntaxes feel weird or unoptimised, just like I feel about SASS and Turbine, for example – the reason that made me write from scratch my own preprocessor, that in its turn can feel weird to some people too.
        If you have the time to spend in such a way, I’d want you to give a detailed feedback about which aspects you didn’t like on my preprocessor, I guess it would be very valuable to me. So if you feel like, send an e-mail to me at msandrinidesign at gmail com. Thanks again!

  • Pingback: On LESS - Saddam Azad – UI Designer, Front-end Engineer.

  • Pingback: The CSS Hierarchies Module Level 3 | @drublic

  • http://twitter.com/Nico3333fr Nicolas Hoffmann

    One point that I really don’t understand : why learning a CSS preprocessor instead of directly learning how to build high quality/efficiency/performance/light/etc. CSS ?
    Imho, I think that a CSS “jedi” doesn’t need these. Anyway, CSS are used everywhere, preprocessors aren’t.

    Moreother, CSS offers the unique chance to be almost close to the render engines with a quite simple syntax, so I don’t understand why people do want some more (imho unnecessary) abstraction.

    • Kolyan Mambozo

      Amen, brother.

    • netsurfer912

      I’d love to write clean code! I do when I can, but it’s just not always possible. You can’t simply do something like “Make the text of this element the background color of that other one” or “make this element as wide as the other one” or “this color, just slightly darker”. That’s what you need preprocessors for (well, I do, if I don’t want to bloat my HTML)

  • Pingback: On preprocessing | welcomebrand

  • http://twitter.com/silvenon Matija Marohnić

    I think CSS preprocessors are one of those things you have to try out before you make an article about them, because on many places you’re wrong.

    I think you don’t have a good opinion about preprocessors because you haven’t started using them and everybody around you is saying how cool they are, which creates pressure for you to learn ANOTHER new thing (like you don’t already have enough things to learn), and your defense mechanism is to convince yourself that it sucks. I know because I felt that way about some things too, we all did.

    • http://leaverou.me Lea Verou

      Saying “you’re wrong” without any arguments just makes you look religious about the subject. Not liking extra levels of abstraction is very different than not wanting to learn a new thing. I have studied how preprocessors work quite a lot, so I’m sorry, but you guessed wrong. I love learning new things. That doesn’t mean I have to use every single one of them, just to prove I’m hip.

      • http://twitter.com/silvenon Matija Marohnić

        Sorry if I sounded rude. Ok, I’ll give arguments. I’m a Sass user, so I’ll use that preprocessor in my arguments.

        In the first example, you assumed that a typical CSS preprocessor user would include the same mixin with the same arguments three times, instead of just doing “#foo, #bar #baz { .rotate(40deg); }”.

        Also, file size of textual files don’t have a significant impact on page loading, requests do, and preprocessors make it easier to organize style groups as partials, while the output can be a single file (meaning one request). Anyways, I would rather sacrifice file size for less non-semantic markup, because it doesn’t make much difference for the end user, but makes a lot difference for me. Just remember all those vanilla CSS grid systems and the horrible markup they require.

        Also, people who were careful about file size before preprocessors are going to be careful while using them too.

        Also, 6 years is kinda long time to wait. I’ll use preprocessors until then.

        Also, preprocessors make debugging EASIER, not harder. Browsers don’t yell on you if you make a syntax error, they just try to make the best of it, leaving you clueless about where the error might be. Sass reports the exact line and type of the error.

        Also, Sass can watch your files and compile them on each save, meaning you CAN just refresh the browser and see your changes.

        I disagree that preprocessors aren’t that needed. Without them you’re being extremely repetitive, without variables and mixins your code is more difficult to maintain, because instead of changing stuff in a few places, you have to change them through whole files. Preprocessors are extremely popular, especially Sass and Compass, they’re not something that’s just gonna die out like that.

        That’s it from me. Most (if not all) of the things I said have probably already been said. That’s why I didn’t give arguments at first.

      • http://twitter.com/NatIsGleek Nathaniel Higgins

        Also, you said the syntax would change in 6 years when CSS implements it with their own code. No it won’t, as the preprocessors will just change their code so it spits out the css version of variables, mixins, etc. In addition, I’m pretty sure there is no proposal for functions or rule nesting like sass has.

  • Pingback: Adventures in Stylesheeting | Filament Creative

  • Pingback: Adventures in Stylesheeting – Brenna O'Brien

  • Yukulele

    .rotate (@degrees: 10deg) {
    -moz-transform: rotate(@degrees);
    -ms-transform: rotate(@degrees);
    -o-transform: rotate(@degrees);
    -webkit-transform: rotate(@degrees);
    transform: rotate(@degrees);
    }

    #foo,#bar,#baz{
    .rotate(40deg);
    }

    #foo {
    font-size: 150%;
    }

    #bar {
    background: silver;
    }

    #baz {
    background: white;
    }

    • Ricardo Zea

      110% agree. Lea, you wrote your LESS rules in a completely inefficient way and you know it. I’m sorry but your preprocessor code example is completely misleading, you should go back and amend your code.

  • Pingback: Le blog de tonton intégrateur » Les préprocesseurs CSS

  • Pingback: Get started with CSS pre-processing - OxonDigital

  • Pingback: Rethinking WordPress Admin | Noel Tock - WordPress & Web Design

  • Pingback: 开始编写CSS – 斯通麦博 WEDN.NET

  • Pingback: 开始编写CSS | Hey Joejoe

  • Pingback: 开始编写CSS « 有一点爱的空间

  • Pingback: 开始编写CSS | 易资讯

  • Pingback: 开始编写CSS | 乐享weby

  • http://www.cloudways.com/ Fahad M Rafiq

    CSS Preprocesssors are like CSS on steroids. Preprocessors enhances the performance of regular style sheets by making more usuable and manageable.

    Review it: http://www.cloudways.com/blog/css-preprocessors/

  • Pingback: pengembang pajanlom | Stylus + Nib