Alison Wagner had a good post on Cognition where she outlined the pros and cons of using a CSS preprocessor. What makes her point of view valuable are the months of practice she had before writing it, after a first post where she said preprocessors had drawbacks she wouldn't do with.
It almost won me over, but I’m still sitting in the no-go camp, and haven’t LESSed or SASSed any project yet. The following explains why I don’t feel it would make my current process less of a chore and/or save me that much time, and how some of the benefits promised by css preprocessors are already there in the CSSEdit app. This makes my point of view less valuable than hers, but the comparison of LESS or SASS with CSSEdit has not been discussed elsewhere, as far as I know, so here it is.
Opening a 4000+ lines CSS file in a regular code editor can provide you with a pretty good definition of "plain": even with syntax coloring, it’s the code equivalent of white noise. Scroll along and it goes shhhhhhh...margin...padding...font-size...margin...border...background...margin...padding...margin...margin...shhhhhhh. A CSS document really has no visual hierarchy at first glance, it looks flat, boring and uninviting. As much as I enjoy working with CSS, this is a truth hard to ignore.
From what I understand of CSS preprocessors, their features allow to add structural meaning (nesting rules) and to eliminate all the repetitions (variables and mixins) inherent of the language and the vendor prefixes situation.
I totally relate to this and applaud the efforts of the devs who took upon themselves to add meaning where there was none. Nonetheless (...), pure CSS is still amazing.
The beauty of CSS, from a designer's point of view, lies in its combined nature of being a blueprint medium and a product feature at the same time. Every browser is a little factory to which we send a blueprint made of html, css, js and images. Upon reception, it outputs our intended final product on the users’s screens. Coming from product design where you send technical drawings and material recommendations, and kind of hope for the best when the product comes out of the assembly line, it’s kind of magical to be able to do quality control so far towards the user. It’s also very easy coming from the screen to peak into the blueprint thanks to debug tools like Firebug.
This is WYSIWYG on the dancefloor: WYSIWYGIWYS. What you see (assets) is what you get (screen) is what you see (inspector).
It is a remarkable opportunity to be able to read your own specifications right in the product. Having a layer of abstraction sitting between the two is an opportunity for misinterpretation or doubt, and can feel like a step backward in that regard.
The lack of structural meaning and repetitions in CSS had been identified by some guys in beautiful Belgium, and they provided a solution where your production code is still pure CSS. They used the graphical user interface as a way to extract meaning from the code, and let you manipulate code through these metaphors without changing any of its conventions. The software, CSSEdit, sits along your decisions and your code, but it’s not obfuscating it. It’s presenting it in an easier to work with way.
In order to let you see how preprocessors and CSSEdit overlap, I'm going to run through Allison's article topics and show you how the later handles them.
Nesting reduces repetitions in rule names
The tedious aspect of writing states or children rules never really hit me. In retrospect, it takes me more time to make an opinion about how to style a given element and adjusting it than writing two extra words, so I don’t relate to this argument. Instead of copy and paste, CSSEdit lets you Command + D the rule you want to extend. Now, I get that it's not about laziness but fluidity — the thing is nesting can have its downsides when debugging. As Andy Clarke wrote last year:
Nested rules promote bad practice too. The CSS they produce reeks of over specificity. [...] This is clearly a case where your knowledge of what’s best should override using a tool."
Nesting rules also add overall visual structure
This is where CSSEdit offers one of its best feature, and where preprocessors fall short: the styled rules list. It sits on the left of your code and saves you tens of minutes a day at least. I'll let you search for the reddish list items on the screen shot below. You can search for it in the raw code too, and compare.
On top of that, as you can see above, you can create folders to semantically group your rules, and nest them as much as needed, without caring about indentation levels. It works with comments in your code:
/* @group -- */ to open a folder, and
/* @end */ to close it. I use this list also as a way to control I really have specified my links different states: if I don't see two or three rules with the same name and different typographic features, a little bell rings in my brain.
Variables to store your site's colors hex values
Here, CSSEdit lets you use the Mac's system wide color wheel's palette. It's not often that I come across someone using it, and this is sad because it's very handy, especially when you edit on-screen documents of different nature for the same client: website, Power Point or Keynote presentations, newsletters, pdfs... It can store up to 300 swatches, which should cover your needs. I usually group them based on active projects, and subgroup them by hues. Team work is where preprocessors variables have a clear advantage over CSSEdit: referencing colors by
"blueGreen_4" is more efficient than "fourth blue from the right in the system palette I set you up last week" update. Allison also mentioned how easy it is to distribute a color change on a whole project. I would temper this argument by adding it depends on the project's scale. If you happen to work mainly on small sites, CSSEdit's filtering search box (by style name or style source) lets you update colors in seconds. I've done it on large Magento e-commerce projects with no problems, but if your color change has to be applied to a dozen of stylesheets, you're better off with a nicely named variable no doubt.
In the article quoted above, Andy Clarke wrote about how preprocessors can manipulate color to generate lighter, darker, less saturated instances of a given reference. I feel really bad for publicly disagree with such a noble figure of our trade, but mathematics should stay outside color choices. These decisions should be made based on how colors look and feel rather than on a given value percentage delta. Let's recall here that colors appearing to be the same optically may not have the same hex reference depending on the shape they're applied to, and vice versa. A light orange on a 48px bold Helvetica title will appear more dense than a darker orange applied to a 12px Verdana regular. Keep this in mind when setting up the guide lines of your design system. Above all, trust your judgement: scale this color wheel to the max and "move things around until they feel right".
Another clear win for preprocessors: mixins
They get the love they deserve for gradients or box-shadows, given how tedious it is to write all the vendor specific rules to ensure compatibility. CSSEdit doesn't support CSS3 rules, but its more recent (although partial) incarnation does, and you can visually edit gradients with it. But writing a mixin with two hex values is more efficient for sure.
All that being said
Not being able to switch from the navigator to the stylesheet with a precise number to target is the strongest no-go signal to me. The current version of Web Inspector for Safari 6 doesn't display line numbers, and I tried to work this way for a couple days, to know if it was really important. I lost too much efficiency not being able to aim at a line number in my code. If you encountered the same problem, you can either switch to Chrome and let the eye of Sauron peak in your browsing habits, or you can install Webkit Nightly and select the previous version of Web Inspector from the developer menu. By the way, the new layout is very well done, despite this let's hope temporary lack of line number in the Styles panel.
Just as design decisions, choosing the right tool is also a matter of context. From what I understand – and I might missing something as I haven't tried them sufficiently – preprocessors are great when you're part of a dev team working on a large project like a corporate intranet, and/or if your design sports a great number of gradients and box shadow. Preprocessors are talked about a lot these days, and it can be tempting to add one in your workflow just because it's talked about a lot these days. Consider carefully your situation before your move and ponder if it will really save you time. Just got started with HTML and CSS? You would be better off spending time learning and mastering regular CSS rather than learning a way to write less of it. In the end, browsers parse CSS and you have to have a good understanding of how it works.
On my side, I will follow Allison’s final recommendation and translate the stylesheet of a responsive project I just finished into SASS to get a better feel from it. And maybe switch to it, who knows.
Udpate: Nigel Warren responded to this color topic explaining how you can name colors, switch palettes and share them with your team in a few clicks. Better than what I thought it was.↩