Mastering Sass: Lesson 2

Jeff… I’ve been watching your casts now for… well, probably since you started. You’ve always been good but wow, you’re getting quite polished. Intro was just right. Not too long, and way better than an insert which is often too distracting. Clear, concise and to the point. You must at least do one run-through – I wish others did the same.

Good stuff Jeff. Like the intro. Still Camtasia or what?

Also, SASS + LESS seem to function almost identically. What sets SASS apart other than preference?

Also also, does Compass add a lot to SASS or is it worth bypassing?

Intro rocks, Jeff! Very expressive.

I have been using SASS for a while now and I absolutely love it. The fact you can have a development SCSS file with commenting and spread out as much as you need and then when it is outputted, it can be compressed to a handy small file.
Not to mention the awesome syntax – super easy to remember. Hopefully if CSS variables are introduced, they check out SASS and bring some of the fucntionality over.

I like the idea of saving time, but I wonder how much of this is a transient issue or a half-solved issue. I also wonder if it’s worth, as Lobo states, the added complexity. Let’s take for example the simple idea of child selectors:

ul {
li {

}
}

For starters, is there a way to ensure that perhaps it only applies to direct children? The equivalent of ul and ul > li? Is SASS dumb (smart) enough to not care what the embedded selector is?

ul {
> li {
}
}

If this is the case, then other selectors don’t make as much sense with this syntax:

ul {
+ img {
}
}

A sibling image for example, which you wouldn’t want to be indented, but likely on the same level as the ul, and is syntactically falsely implied to have a child-like relationship.

Then on top of this we add the fact that presumably if someone edits the actual compiled CSS code, you now have disparate rules which are not re-incorporated back into SASS without manual intervention I presume.

For things like variables, mix-ins, and minification it would seem to me these are better handled by traditional pre-processing or snippets. For example, Flourish (http://www.flourishlib.com) already handles minification support in it’s templating. I have recently modified the fork used on inKWell (http://www.github.com/dotink/inkwell) to use output buffering and include statements in this process which now makes the inclusion of PHP code viable in both CSS and Javascript.

Example:

ul {
background-color: ;
;
}

If front-end developers who may not be familiar with more complex programming constructs are taking the time to essentially learn the concepts of variables and functions (not to mention inheritance), the invasion of traditional pre-processing languages is not significantly harder.

The only benefit achieved with not using such a language is the idea that this is a separate component which would work regardless of your language thus making it more portable. This benefit does not seem that grand, however, in the world of CSS, as it’s not as re-usable as other pieces of code.

Hey this really rocks!!

The only think that I’ll not put it in production is that the editors like CSSEdit doesn’t work with it. I’m using CSSEdit as this is really cool for styling and most important you can see the changes instantly !!

Very nice video. May I ask what plugins you are using in macvim to expand the variables etc?

Amazing ! thx Jeff