rails + compass: advantages vs using haml + blueprint directly

I've got some experience using haml (+sass) on rails projects. I recently started using them with blueprintcss - the only thing I did was transform blueprint.css into a sass file, and started coding from there. I even have a rails generator that includes all this by default.

It seems that Compass does what I do, and other things. I'm trying to understand what those other things are - but the documentation/tutorials weren't very clear.

These are my conclusions:

• Compass comes with built-in sass mixins that implement common CSS idioms, such as links with icons or horizontal lists. My solution doesn't provide anything like that. (1 point for Compass).
• Compass has several command-line options: you can create a rails project, but you can also "install" it on an existing rails project. A rails generator could be personalized to do the same thing, I guess.开发者_Python百科 (Tie).
• Compass has two modes of working with blueprint: "basic" and "semantic" usage. I'm not clear about the differences between those. With my rails generator I only have one mode, but it seems enough. (Tie)
• Apparently, Compass is prepared to use other frameworks, besides blueprint (e.g. YUI). I could not find much documentation about this, and I'm not interested on it anyway - blueprint is ok for me (Tie).
• Compass' learning curve seems a bit stiff and the documentation seems sparse. Learning could be a bit difficult. On the other hand, I know the ins and outs of my own system and can use it right away. (1 point for my system).

With this analysis, I'm hesitant to give Compass a try.

Is my analysis correct? Are Am I missing any key points, or have I evaluated any of these points wrongly?

The ideal goal is separation of style and content: it's not always possible 100%, but it can be done reasonably well by using semantic markup. Blueprint and other CSS frameworks utterly fail at this.

The original idea behind Compass was to avoid polluting HTML with the visual markup that Blueprint generates: if you're writing class="column-4" in your markup, then you might as well put style="width:160px" in there instead. Semantically it's the same meaning, and the same amount of repetition to maintain.

Compass turns a Blueprint class like .column-4 into a mixin which you can apply to a meaningful selector:

#sidebar
  +column(4)

This way, you only need to maintain it in the stylesheet, not across a number of templates and HTML files.

Compass is project-aware. It will handle compiling your whole tree of stylesheets, even automatically on save when you run compass watch.

There are some very helpful functions provided by compass, for example:

image_url is a configurable function that can handle relative or absolute paths or even set up rotating asset hosts if you need to.

The CSS3 module takes care of all the browser-specific style rules for rounded corners, shadows, etc.

General utilities provide helpers for the stuff you do all the time, but with less repetition (especially for the cross-browser issues). These are some basic ones I use a lot:

• +clearfix and +pie-clearfix (cross-browser clearing methods)
• +float ensures you don't forget display:inline in front of it for IE... (if the time comes to drop the old IEs, it's one single change.)
• +replace-text hides text and positions an image replacement background.
• +hover-link adds the :hover underline rule to a base link style

You can check these out on the new docs site for Compass.

Then, Compass provides the facilities for a number of other style frameworks in addition to the built-in Blueprint. Do check out Susy for example, which is a Sass-native layout framework, not just a CSS port. It specializes in flexible and fluid grids.

'Semantic mode' refers to the possibility to use more semantic class names than the ones css frameworks ship with: .article vs .grid_1. which i personally think is a big +.

I'm not sure if these resources have only shown up recently, but have you seen the Compass CSS3 helpers and the General utilities - (both well documented in my opinion) - they've really sped up my interface builds a great deal.

Another great resource is the Compass plugins page.

Personally I like to copy these utility Sass files out the rubygem and manually include them in my project's Sass files as it feels pretty weird referencing Sass which is stored out of the project.

Compass looked like a great solution for me as well, but after trying it on a project I didn't really see the great advantage of using it for me. Like you, I'm just fine with blueprint, and I didn't see the need to add yet another layer on top of haml/sass.

I eventually stripped the compass from that project and just go with a sass version of the blueprint CSS files, and go from there. I store any custom/additional styles in a separate sass file and that's it. No need for compass or anything like that if you just want to keep it simple.