Let’s be honest, CSS frameworks, while meeting the technical definition of a “framework”, are not anything more than a collection of css classes that you can use in your HTML. They are not a framework for writing your stylesheets -- they are a framework for building webpages, and this is the fundamental difference when you use Compass & Sass.
So here’s the list of disadvantages of CSS frameworks from Smashing Magazine, and my response to each with respect to Sass and Compass.You need time to fully understand the framework.
Using external CSS frameworks, you still need a profound understanding of your code. You need to know exactly how your framework is actually built. “By building a site from the ground up, you gain a knowledge of your site’s architecture that can’t be learned through any study or documentation.” [Why I don’t use frameworks]
Yes, you’ll need to know your how your framework works. For example, you’ll need to know that a grid is built using floats and how changes to the element’s box attributes (padding, margins, border) will affect the layout. Your framework should document this, and if it doesn’t you should go read the code and understand it.
You might inherit someone’s bugs or mistakes.
If you use external CSS Frameworks you might get in trouble fixing someone else’s bugs which is far more time-consuming than fixing your own bugs.
Absolutely. This is of course not unique to CSS frameworks, this is a risk you take any time you stand on the shoulders of someone else. Fixing someone else’s bug is slower than fixing your own. But let’s think about this. How many bugs will you make in your attempt to reproduce what the framework gives you? I’m guessing more. But it’s quite likely that you won’t encounter someone else’s bug. But let’s pretend that you do; what is so bad about this? If there’s a community of people sharing a common code-base, once one person finds that bug it’s fixed for everyone. Thanks! You’re a great team player who has been benefiting from the help of others and you’ve just contributed back a small portion of your time savings. As with any build vs. buy decision, you need to consider how widely used the project is, how engaged the maintainer is, etc.
That said, the cost of upgrading a traditional CSS framework is high. The installation is manual and unless you were careful to never make a change to the files provided by your CSS framework, you’ll be stuck trying to manually merge your changes. Worse, some CSS frameworks, in an attempt to make them more customizable, will generate CSS just for you that you can then put into your project. Upgrading will mean regenerating this CSS using the same inputs.
Compass was designed to be upgraded trivially addresses this problem in two ways. It relies on the ruby installation framework called rubygems so upgrading is a simple matter of issuing:
$ sudo gem update chriseppstein-compass
Now, because you’re code is written in Sass instead of CSS, you simply need to recompile your stylesheets and you’re up and running with the latest bug fixes:
$ compass --update myproject
You develop sites upon a framework, not upon the solid knowledge of CSS.
“A big problem with frameworks is when up and coming developers attach themselves to a framework as opposed to the underlying code itself. The knowledge gained in this case surrounds a specific framework, which severely limits the developer.” [Please Do Not Use CSS Frameworks, by Jonathan Christopher]
This argument has been made every time a technology evolves a new layer of abstraction. There’s a certain amount of truth to this argument if you’re speaking about complex code frameworks like rails, MFC, etc. But in the case of CSS frameworks and Compass, I just don’t agree. As we said above you’re going to need to take the time to fully understand the framework. The output and construction of the framework is not hidden from you and you’re fundamentally working with abstractions that you have in CSS anyway.
You get a bloated source code.
This is true. You can degrade the performance of a browser. But did you? I’ve seen this argument before, but I’ve never seen anyone back it up with numbers. But let’s make an aesthetic argument instead: Having a bunch of CSS that is superfluous to your project is ugly. I agree. Compass currently has 4 CSS frameworks that you can use. This ridiculous bloat just doesn’t matter though because you control what ends up in your stylesheets. You can select the non-semantic versions of these frameworks with simple commands like:“Whether it be in a server side language framework or JavaScript library, there is often a large percentage of code that will never be executed. While not a major issue server side, this can greatly degrade the performance of a client side framework such as a JavaScript library.” [Please Do Not Use CSS Frameworks, by Jonathan Christopher]
@import compass/reset.sass, @import compass/reset.sass, blueprint.sass
+blueprint
Or you can be more selective. For example, if you just want blueprint’s grid system:
@import compass/reset.sass, blueprint.sass
+blueprint-grid
CSS can not be framed semantically.
“CSS and (X)HTML go hand in hand. (X)HTML is a language semantic in nature, which is impossible to wrap up in the style of a framework. Each and every project is unique in and of itself, right down to the document structure, classes, and ids. A CSS framework passively removes a great majority of semantic value from the markup of a document and, in my opinion, should be avoided.” [Please Do Not Use CSS Frameworks, by Jonathan Christopher]
Bingo. This is, hands down, my #1 problem with CSS Frameworks. CSS based frameworks have to work within the limitations of the technology. As such, you have to make sure your markup conforms to the framework and violate the best practice of keeping your content and presentation separate. And this is the #1 reason Compass exists. I didn’t want to choose between using a framework and following best practices. I wanted to eat my cake too! Compass, together with the awesome concept in Sass called a “Mixin”, allows you to build semantic stylesheets!
@import blueprint.sass
#page
+container
#sidebar
+column(8)
#content
+column(16, true)
This generates the following CSS:
#page { width: 950px; margin: 0 auto; overflow: auto;
overflow: -moz-scrollbars-none; display: inline-block; }
#page { display: block; }
#page #sidebar { float: left; width: 310px; margin-right: 10px; }
#page #content { float: left; width: 630px; margin-right: 0; }
As you can see, your #page element is a container that has been clear-fixed and set to the appropriate width. The #sidebar is an 8 unit grid column and your #content is a 16 unit grid column with no right margin because the “true” means it is the last column in a row. This is a simple example, but I hope it demonstrates how you can start to think about your stylesheets in a new way and why I say Compass is a real stylesheet framework, not just a collection of classes.
Ignoring the uniqueness of your projects.
Designs should be based upon the content, not upon a standard template you use over and over again.
I don’t know. I’ve never had a framework dictate my design. Our designer would never stand for that. Sometimes the framework informs some basic guidelines surrounding widths, etc. If your framework is dictating a design you don’t want, pick a different one. Compass comes with three (blueprint, yui, and compass-core) and you can install a plugin to get support for 960.gs. Even if you don’t want grids, these frameworks can help you set up your typography and vertical rhythm and perform common styling tasks like making lists lay out horizontally or building a tag cloud. Here’s a demo of some of the compass utilities.
