Pros And Cons Of 3 Popular CSS Meta Frameworks

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.

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.

Author: admin

Howdie stranger!
If you want to participate in our photoshop and photography contests, just:

LOGIN HERE or REGISTER FOR FREE

22 Responses:

SM says:
Nice collection. Thanks
( 2 years and 4665 days ago )
Nathan Weizenbaum says:
Hi, lead developer of Sass here. I wanted to make a few clarifications. First, I want to emphasize that we recognize that the indentation-based syntax is not everyone’s cup of tea, and we’ve got a CSS-extension syntax in the work. It can be used right now from http://github.com/nex3/haml/commits/scss. Once the next version of Sass is released, this will be the syntax we’ll suggest for most beginners to use.

Second, we’re also making every effort to make the compilation process as easy as possible. We’ve added a way to automatically recompile CSS files (http://nex-3.com/posts/90-auto-compile-sass-files-with-sass-2-4), so you’ll only have to set up the compiler once, rather than run it each time you change something. We’re also planning on creating a graphical user interface so people don’t have to use the command line.

Finally, I have a few disagreements about your presentation of Less. I wouldn’t say it has “practically all of the features” of Sass. Sass is a very powerful, expressive language, enabling in particular frameworks like Compass (http://compass-style.org), which would be flatly impossible in Less.

We also very consciously chose to avoid using @ as the character for variables, precisely because it’s already used in CSS. The thing is, when it’s used in CSS, it doesn’t mean “variable”, it means “directive”, like @media or @font-face or @import. To use it as a character indicating variables, and moreover to use the variable’s name in place of the directive name, is both highly inconsistent with CSS and liable to break badly if CSS introduces a directive with the same name as a variable someone’s using.
( 2 years and 4665 days ago )
Brandon Corbin says:
imsky, I would be interested in knowing if you have used any of these frameworks in a larger project? I conceptually agree that the features of each would make CSS’ing easier – but wonder how well these frameworks hold up once a project is completed and has to be maintained by other individuals.
( 2 years and 4664 days ago )
Simon Foust says:
Just wanted to thank you for this overview. It’s nice to see a well-written article on this topic.

As a front-end developer, I’m always curious how people feel about css metaframeworks and blueprints. I’m actually planning my own article about it; when I publish it, I’ll definitely link to this post for recommended reading.

Cool to see Nathan from Saas post here in the comments too, so we can hear things from the horses mouth, so to speak. 🙂
( 2 years and 4664 days ago )
Just Johnny says:
CSScaffold by Anthony Short is a nice php based css framework that works like SASS, check it out: http://github.com/anthonyshort/csscaffold
( 2 years and 4664 days ago )
Joshua says:
I’ve used SASS in a few large projects now. Frankly, I won’t write CSS without SASS at this point.

I’m actually disappointed that SASS is moving to add brackets to their syntax. Brackets make no sense in a non-logic based language. In a programming language brackets have their place as they define scope, but in a language like CSS, the use of brackets is just weird and always felt wrong to me. Indentation is much more appropriate for CSS since the primary “logic” is nesting.

Introducing the brackets to SASS i think will be the beginning of it’s downfall. Yes, it’s optional but when you add multiple ways to do the same thing syntactically in a language, you muck up the water and cause more confusion for beginners that will see tutorials in both if they look. To me it’s as silly as PHP allowing the ASP short tags.

To speak to SASS in it’s current state… I use it every day. If you’re using a decent editor with bindable commands, it’s not even a second thought. In textmate, there is a ruby-sass bundle… so when i save the file i simpley cmd-s cmd-r and it recompiles it.

An added benifit to these tools, or at least SASS, it the abililty to control how it’s compiled. verbose with debug comments or compressed to a single line and options in between.
( 2 years and 4664 days ago )
imsky says:
@Nathan, SASS is indeed more powerful than Less, but there is far more investment needed in SASS to grasp it in its entirety, with some of its features having limited uses outside of corner cases (if/for/while, interpolation, etc.) The majority of use cases for any CSS metaframework won’t include rulesets so complex they require iteration. As to your other points, automatic recompilation is a welcome development, but it should be expressed somewhere on the page as it’s a major selling point.

@Brandon, in my experience, frameworks are only useful on a certain type of site. Maintenance after initial development hindered only be the designers’ knowledge of the framework used, otherwise a small and concise metaframework-driven stylesheet is preferable to the spaghetti CSS that appears in large, content-driven sites with frequent styling exceptions and accommodations for integrated scripts, etc.
( 2 years and 4664 days ago )
deltacubed says:
Nice write up, thanks. I wasn’t aware of any of these “metaframeworks” but they certainly look like something to explore. The concept of DRY (don’t repeat yourself) is one that should be encouraged in CSS – it’s far too easy in a large stylesheet to create unecessary elements.
( 2 years and 4663 days ago )
Jon Roberts says:
Something that hasn’t been mentioned yet is that Sass is usually recompiled automatically, as long as you’re using a Ruby framework like Rails or Sinatra. There’s a Drupal module that does this as well.

I write my stylesheets in Sass daily — please don’t remove the indentation-based nesting! It’s one of the reasons it’s so much faster to write and easier to read than plain old CSS.

xCSS and Less are kind of interesting, but those nested braces and required semicolons make both of them really unattractive.
( 2 years and 4663 days ago )
Martin says:
Why not just set your stylesheets to be parsed by PHP (or whatever server side language you use) and then you can do all of this anyways (variables, constants, equations) without any framework in the middle?
( 2 years and 4663 days ago )
Cedric Dugas says:
@Martin : because it would be slow as hell,

One of the advantage is that all these framework pre-compile the css. I used xcss in the past, and you can also minimized it on the fly

Personally, if I had a framework with zero installation hassle I would use one.

It really depends what kind of clients you have. If you are not going to do the maintenance for a site using these, the next guy will be wondering what the hell is going on in there….
( 2 years and 4663 days ago )
Joshua says:
@Martin

That only gets you partially there. It really only gives you variables and operators, it doesn’t add the semantic structure that these frameworks do – mainly the nesting and “mixins”.

Also, simply turning on parsing for a file that is nearly completely static is a waste of resources and you need to write a small caching scheme for it at least.

In one of my “custom” php frameworks from the past I actually did php parsing on all javascript and css files – with caching built in. That does work well enough for what it is, it just doesn’t provide the more important things provided by the frameworks
( 2 years and 4663 days ago )
LESS says:
[…] thirty times throughout the code, what you wished you had, was a a CSS meta framework. There are a few of them already, and LESS seems to be the easiest […]
( 2 years and 4663 days ago )
Catherine Azzarello says:
I’ve been following meta frameworks for months. As a designer who does my own HTML and CSS coding, I am excited about variables and mix-ins. But I simply do no understand the Ruby part or the PHP part or simply–how to get started using a meta framework. Seems like all the sites (Less and Compass included) assume a higher level of programming knowledge.

When I asked other designers about it on DCTH (design chat Twitter hours) no one knew what I was talking about.

Looks like there’s a need for a plain-speaking geek to bridge the gap between design and CSS development! 😉
( 2 years and 4663 days ago )
Mark says:
LESS seems to be pretty cool
( 2 years and 4661 days ago )
Matt says:
@Catherine – It’s not as complicated as it seems, although the lack of details doesn’t help. I use SASS and Compass (with the 960.gs CSS framework plugin) for all my projects, first with Ruby on Rails and in the last few months with PHP.

1. The first thing is to get Ruby installed. On Mac you’ll probably already have Ruby installed (open a Terminal and type ‘ruby -v’), on Linux you’ll need to install it from your package manager (best do a search on Google for ‘installing ruby on ubuntu’ or whatever).

For Windows, go to the Ruby website and download the One-Click Windows install (http://www.ruby-lang.org/en/downloads/). Open up a commandline (Start Menu > Run > type ‘cmd’) and ‘ruby -v’ to check it’s installed.

2. After that you need to install RubyGems. Gems are like plugins for Ruby. So download RubyGems (http://rubyforge.org/frs/?group_id=126), the .zip if you’re on Windows, .tar on Mac/Linux.

On Windows, extract the zip to somewhere easy to find (i.e. C:\rubygems). Then go back to the commandline and type ‘cd C:\rubygems’ (cd = change directory). Then type ‘ruby setup.rb’.

On Mac/Linux, open up a Terminal, then type ‘tar zxvf’ then drag the file you downloaded on the terminal window to get the path. Type ‘cd rubygems-1.3.5’ then ‘sudo ruby setup.rb’.

Done.

3. Now you’ve got Ruby and RubyGems installed you can install SASS: ‘gem install haml’. SASS is part of HAML, an alternative markup language for Ruby.

4. Install Compass if you want to use Frameworks.
‘gem install compass’

5. To create a new project using Compass from scratch use a command like:
compass -f blueprint project-name

Blueprint is the CSS framework, take a look at the Compass website for the other frameworks that are usable.

6. The SASS files (by default) are placed in the src folder, these are the ones you edit.

7. So you don’t need to keep re-compiling your stylesheets, switch to your project directory (‘cd project-name’) and run the command ‘compass -w’ (the -w is for watch). Now it’ll automatically update your style sheets.
( 2 years and 4660 days ago )
Mario Fischer says:
LessCSS + Mac:

Hi – very good article!

One addition to LessCSS, if you use a Mac: There’s a very good free GUI tool called “Less.app” which automatically watches folders and recompiles on changes:

http://incident57.com/less/

mario
( 2 years and 4660 days ago )
You are now listed on FAQPAL says:
Pros And Cons Of 3 Popular CSS Meta Frameworks…

We’re going to look at the big three metaframeworks that exist right now: xCSS, SASS, and Less….
( 2 years and 4659 days ago )
This Weeks Twitter Design News Roundup N.25 - Speckyboy Design Magazine says:
[…] Pros And Cons Of 3 Popular CSS Meta Frameworks […]
( 2 years and 4655 days ago )
Rob says:
@Martin,@Cedric Dugas,@Joshua

The notion that it would be “slow as hell” is incorrect, yes slower than native CSS but a simple PHP script for variables and operators etc. wouldn’t, in most modern web applications, be the bottle neck. There almost certainly would be better targets for performance optimisation. If microscopic performance improvements do it for you then don’t use any frameworks for anything, they’re always slower, but they make life easier.

And it could give you much more than just variables and operators depending on your implementation but do you really need the other stuff? CSS has an inheritance model anyway (and let’s face it, not that hard) and the final compiled result is still a traditional CSS file with the big long selectors etc. Sure compiling is great and a brief look-up of output buffering would show you a very simple but effective way of achieving this. More efficient and clever methods could be easily built with just a little more effort.

Let’s remember that these frameworks are for rapid development, I think we’re in danger of implementing so many frameworks that the benefits are lost.
( 2 years and 4603 days ago )
Ken Newman says:
Thanks for this article, was just what I was looking for. Seems xCSS would be best for a CMS like WordPress as it’d handle the hoops for you 🙂
( 2 years and 4558 days ago )
http://livesexcams24.net/ says:
What a data of un-ambiguity and preserveness of precious experience on
the topic of unexpected emotions.
( 2 years and 3297 days ago )

Pros And Cons Of 3 Popular CSS Meta Frameworks

xCSS

SASS

Less

Conclusion

Pxleyes

Latest blog posts