Code

Preprocess that

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.

LcssVE

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.

A CSSEdit document

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.

CSS 360

If you happen to be reading this post in a resizable window, please do so and play around 1100px wide. You will see how css sprites combined with media queries can play an animation of the header's desk. If you're on a mobile, follow along with your imagination, and come back here when you're on a desktop/laptop for a better demo.

The background image of the h1 a is a sprite where each instance of the desk rotates 10deg clockwise, in perspective. I modeled the desk using the beta version of Rhino3D for mac (which I'm really excited about, by the way), cleaned an .ai wireframe export of each 10deg step in Illustrator, and finally punched the wood texture using the vector paths in Photoshop. No CSS involved in the 3D aspect of this. I could have used image masks to skip the Photoshop step, but I still like it in Photoshop. Anyway. CSS media queries call the appropriate desk's instance of the sprite by repositioning it every 5 pixels intervals of the window's width.

@media only screen and (min-width: 1100px) and (max-width: 1105px) and (min-device-width: 1025px) {
    h1 a { background: url(../img/bureaux.png) no-repeat center 0; }
}

@media only screen and (min-width: 1106px) and (max-width: 1111px) and (min-device-width: 1025px) {
    h1 a { background: url(../img/bureaux.png) no-repeat center -125px; }
}

It's been a long time since I wanted to do this, and I'm really happy to show it now. It's a very stupid thing of course; no one will benefit from this but RWD nuts like you, I'm afraid.

Tweet from @RWD about Herbie Hancock and breakpoints
This tweet from Ethan Marcotte motivated me to finally get to work.

Along the way I found out an interesting thing about Webkit and Gecko (Update: if I had looked closer to my code, I would have realized that this wasn't that much of an interest, see below). If you are viewing this page using a Webkit browser, you probably have a lot of flickering, like in old black and white movies, with the desks going up or down and being horribly sliced. Calling this an animation is a far stretch, you might think. This is not how I planed this idea to happen. Now, load this page in Firefox and see how it behaves now. Better. Simple and sharp, a nice 360.

What seems to happen in Webkit is a rendering of the transition between the states described in CSS contexts. Change the window's width very slowly to see it happen. I tried to replicate the behavior with a simpler background image and change its position between contexts, either with background-position or with margin, but the change was really snappy. I don't know what really triggers this transition rendering, so I will have to test more to find out. There's either an underlying design decision regarding this behavior, or it might just be a collateral effect of css transitions implementations.

If you have a clue about this, let's talk about it on twitter, and I'll publish feedbacks here as an update.

Update: well, it didn't take too long. @unsongeur found out that I had background in my -webkit-transition-property declaration for h1 a. Works great in Webkit now too. Off to a whisky and some sleep.

EMDb

Here is a document I've been building over the past year while working on CSS files based on ems for dimensions.
Let's say you want the text in <div id="foo"> to have a font size of 14px, while its parent div has a font size of 16px. In ems, this translates as (target size)/(context size) = 14 / 16 = 0.875em. What I used to do was reach to the calculator app each time, and copy paste the result in my css.
At some point I realized I was often calculating the same sizes over and over again; storing these recurring sizes in a document allowed me to refer to it for a quicker copy&paste, resulting in a less tedious workflow. Project after project, little by little these tables completed themselves, and here we are today.

a screenshot of the emdb text file

Formating decisions

The value is followed by a semicolon: placing the caret after the colon of the css rule, a simple paste will finish the line, no need to type the semicolon at the end. In the case of replacing an existing value, placing the caret after the colon and hitting command+shift+right arrow followed by command+V proved to be a smooth keyboard ride.

The target and context in pixel sizes in the comments are here for two reasons: it made finding the right value in this reference document quicker(1) and it's easier to get back in the logic of the file when you haven't worked on it for a while — it lowers the em abstraction bar.

The 16px column is the first one, as it is the one I have been refering to the most, given it's the default font size in html documents. The following columns respect the logical order, but only even numbers. Odd font size contexts are not referenced here because I haven't been using them in my designs.

The file is available here on GitHub, so feel free to fill the remaining voids, and improve it whatever way you may find.

Happy em sizing everyone.

(1) the eyes don't have to grab the correct line from the target values in the left column and then follow this line to the adequate context column.