A lot of perennial attention is given to the use and evangelism of CSS frameworks. By “CSS framework,” we don’t mean Blueprint or 960, but rather SASS, xCSS, and Less. These are also referred to as CSS “metaframeworks,” but the distinction between them and Blueprint lies in the distinction between form and function. Frameworks like 960 and Blueprint focus on how things look and where they are placed on a page. Frameworks like SASS and Less focus on the logical representation of styles and the augmentation of the CSS language.

The most common objection to any CSS framework is that designers usually don’t need it. Opponents of both form and function frameworks propose that the inherent mechanisms of CSS, such as cascading styles and selectors, are sufficient for any desired effect. The extension of that argument is that CSS3 will make most form frameworks simply unnecessary due to its broad scope and modern improvements. Function frameworks will also be affected by CSS3 developments, especially CSS variables.

What, then, is the use of CSS frameworks? Do they encourage less code? Clearer code? Are they useful in very specific cases or general situations? Is their implementation and deployment smooth and can the training cost of them be justified? To answer all of the above, We’re going to look at the big three metaframeworks that exist right now: xCSS, SASS, and Less.

frameworks

xCSS
xCSS is newer than the other two frameworks and takes a somewhat different approach in implementation. To use xCSS, one must have a PHP-enabled server (most of us do) and there are some hoops to jump through when installing. One has to insert a SCRIPT tag into their source, then insert a LINK tag, and then comment out the SCRIPT tag. Something about this process feels more laborious than it should.

The actual syntax of xCSS is interesting. Inspired in part by SASS and Object Oriented CSS, xCSS tries to be very DRY (Don’t Repeat Yourself) when it comes to specifying CSS rules. One of the major features is inheritance:

.photo {
self {margin:5px}
a {color:red}
}

The above is the xCSS version of this code:

.photo {margin:5px}
.photo a {color:red}

Another xCSS feature is variables and math operations:

$vars {
$myvar = 1;
}
.photo {width:[$myvar * 2];}

Right away we can see uses for these features. Inheritance can be used to efficiently specify complex style rules and variables can be used for things like color themes and readability modes. But how useful are these developments really?

The best thing about xCSS’s inheritance is that it reduces the amount of code written for large stylesheets. Things like .class1 .class2 .class3 div followed by .class1 .class2 .class3 span would no longer be necessary. Faster loading times and an easier-to-read stylesheet are both benefits of this feature. Where the feature doesn’t offer much is in stylesheets that don’t use deep cascades or don’t repeat an identifier more than once. Using inheritance there would lead to more bloated code that adds extraneous specifications (and some processing overhead).

Variables and math operations make CSS an almost-Turing-complete language. How many times have you thought to yourself “I really wish I could avoid hardcoding the width/margin/padding/color of this element and make it depend on something else?” With a bit of elbow grease, one could define a couple of color variables and have all the shades of the colors computed instantly. No more messing with color pickers! On the other hand, using variables and math operations forces the designer who maintains the project to constantly look up values. There’s no introspection in xCSS, no way to quickly output what a particular element’s computed style is without either loading the page in a browser or searching through the computed CSS. This disadvantage makes variables and math operations useful tools in rapid prototyping, but not so useful (and perhaps counter-productive) in larger sites.

The final verdict on xCSS? Use it for RAD and sites with lots of repetitive stylesheets, but avoid it for too complex or too simple stylesheets. The setup alone is quirky enough to dissuade a non-technical designer, so a more user-friendly version would be huge improvement.

SASS
SASS (or Sass) is a Ruby-powered CSS compiler. What that means is that a designer has to write the SASS code first, run a compile command like sass style.sass style.css and then link to the resulting CSS file. Bothersome? You bet, but there’s a distinct advantage here over xCSS: the compilation step is done by the developer and the resulting code is plain-jane CSS that doesn’t need PHP or JS to function properly.

SASS separates itself from other frameworks by dispensing with curly braces and semicolons altogether. Each rule gets its own line and has to be indented properly. Python users might approve of this, but the inability to write one-liners seriously hinders the readability of code. SASS includes a lot of the features of xCSS, like inheritance and variables, and these look so similar to each other that it’s not worth the comparison, but one aspect of SASS is particularly powerful.

Mixins are the big selling point of SASS. Mixins allow the designer to use up very little space when defining repetitive styles. Here’s an example:

=mixin-sample
color:#fff
display:block
#abc
+mixin-sample
#xyz
+mixin-sample

The above translates to the somewhat repetitious plain CSS:

#abc {color:#fff; display:block}
#xyz {color:#fff; display:block}

Just like inheritance in xCSS, this feature is killer in large sites with lots of repetitive rules. It’s a bit much on smaller projects or projects that don’t repeat rules a great deal. SASS developers go a bit crazy with the mixins, though, and promote the use of arguments with mixins, which frankly looks like a little too much abstraction for readability’s sake.

The final verdict on SASS is that it’s powerful and easy to use, but a bit draconian when it comes to the syntax (although semicolons and braces may be used if one wishes). The extra step of compilation from Ruby makes the use of SASS a bit top-heavy, what with the setup and familiarization of oneself with the Ruby runtime. However, the speed of development in SASS makes it a very compelling choice.

Less
Less is a newer CSS framework that tries an approach similar in spirit, but not in implementation, to SASS. Less integrates practically all of the features used by xCSS and SASS such as variables, mixins, inheritance, and mathematical operations. The difference is that Less tries to be very visibly user-friendly. Variables are prefixed with @ instead of ! or $ to match present CSS conventions. Variables are also defined outside of a variable block, unlike xCSS, making code easier to read. Unfortunately, Less requires Ruby and an extra compilation step, just like SASS.

As far as frameworks go, Less has hit the sweet spot. It’s full-featured, people use it, and it tries to be as transparent and easy to learn as possible. The syntax is immediately obvious and it seems that care was taken to ensure that designers cautious about adopting a framework would feel immediately at ease. If your project is large, complex, and needs to be optimized you need a framework that doesn’t need complicated explanation and Less is it.

Conclusion
The number of CSS frameworks today is large, but the differences between the frameworks are small. It’s important, then, that you, the designer, pick a framework that you most feel comfortable with. xCSS makes sense for those who don’t feel like recompiling their CSS, SASS makes sense for those averse to standard CSS syntax, and Less makes sense because it’s easy to integrate and doesn’t lack any features. However, one must only use a framework if a framework is really necessary. In most cases, proper understanding of the cascade model, inheritance, and selectors is all a designer needs to write efficient CSS.

from Pxleyes.com