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. (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.
Related
May I ask you how to make rails web design more efficient?
Is compass plus blueprint the perfect match?
Is the current version of compass support rails3.1
Are there any other frameworks that will make rails web deign easier?
Thanks
Definitely a framework like compass is awesome, it includes a lot of helpers, and provides a good solid base.
For form-styling I would recommend using a gem like [formtastic][1], which not only greatly simplifies making forms, but also provides a standard css file. So all needed tags are then known (and can be overwritten if needed).
There a few alternatives to kickstart your application's layout:
twitter-bootstrap: it is plainly awesome and provides a great start (it does not play nice with formtastic, but works perfectly well with simple_form).
web-app-theme provides generators, and a set of templates to style your application quickly
activo is a template that is contained in web-app-theme, but can also be used standalone
Hope this helps.
Which framework do you use in Rails 3.1?
I basically want to have a standard set of mixins like gradient and rounded corner etc, but maybe there are other advantages of certain frameworks that I am not aware of.
Can you please recommend a framework to use with Rails 3.1 to cover most of what I will need to simplify and standardize my stylesheet development
Bourbon - a set of Sass mixins using SCSS syntax, is a popular (500+ watchers) tool made by thoughtbot.
The purpose of Bourbon Sass Mixins is to provide a comprehensive library of sass mixins that are designed to be as vanilla as possible, meaning they should not deter from the original CSS syntax. The mixins contain vendor specific prefixes for all CSS3 properties for support amongst modern browsers. The prefixes also ensure graceful degradation for older browsers that support only CSS3 prefixed properties. Bourbon uses SCSS syntax.
It can help with use:
Animation
Background-image
Border Radius
Box Shadow
Box Sizing
and other
See the readme on the official page on github
I think that any current CSS framework can accomplish what you want.
Have you give LESS a look? I believe it meets all your criteria.
I haven't personally tried out compass, but it's been generating alot of buzz, so it is certainly worth a look.
Twitter also released Bootstrap which I've been trying out and I've been fairly impressed so far!
For me, a framework doesn't seem to be to be considered here. You can easaly do it yourself.
For my part, I use sass and I write a _macros.scss with all the appropriate mixins and default variables, and I put an #import "macros" at the beginning of each main scss files.
Note: This question refers to a Rails project with Sass & Compass.
Using the Rails Asset Pipeline? Then have a look at this question.
We are developing a big application with many use cases and many individually styled pages, partly for multiple contexts. Which simply means a lot of style information.
With the newest section of our application, we have broken Internet Explorer's limit of 4095 selectors per stylesheet. (Want a proof of this limitation? http://marc.baffl.co.uk/browser_bugs/css-selector-limit/)
Okay. So, why do we not simply split the application style sheet into multiple ones by design?
Well, mixins and selector inheritance will not work across multiple Sass files (not partials), right?
I'd say the quality of the stylesheets is rather good, we cannot optimize away the exceeding amount of selectors. (There is rather more to come.)
I also believe that minimizing the amount of selectors should not be our primary optimization goal. The Sass core team advises to use selector inheritance instead of mixins where applicable in order to save CSS file size. By doing so, the number of selectors tends to grow though.
So what should I do?
I am thinking about writing a script that generates additional css files, partitioning my big application.css file. These would only be loaded in IE then (so that I don't have multiple requests in modern browsers).
I would need a simple css parser for that in order to cut the application.css file after max. 4095 selectors at a valid position.
And I would need an compass compile - after hook so that developers don't need to generate the IE files by hand in order to test it.
Please, tell me, that you got a better idea!
Best,
Christian
Mixins are usable across multiple files. However, it is logically not possible that #extend may work with multiple files. It is the purpose of this directive to result in a single rule
(which should not be duplicated across multiple files). Therefore, I cannot split up files.
Thus, I implemented a splitter: https://gist.github.com/1131536
After these two commits have found their way into Sass and Compass, you can use the following hook in your Rails config/compass.rb in order to automatically create the additional stylesheets for IE:
on_stylesheet_saved do |filename|
if File.exists?(filename)
CssSplitter.split(filename)
end
end
Update:
The CssSplitter mentionend above has been release as a gem: https://github.com/zweilove/css_splitter
If you can't reduce the number of selectors, there is no choice other than to split the CSS file.
Your proposed solution for doing so already sounds optimal, if a little complicated to implement.
An easy way to do it is http://blesscss.com/.
Simply :
install node.js
Execute npm install bless -g
blessc source.css output.css
For a rails CSS framework for an existing app, which one do you prefer - LESS or COMPASS?
Less and Compass are not really direct competitors.
LESS is a CSS engine. Compass is more a toolbox around SASS/SCSS and Blueprint CSS framewok. So if you want to use Blueprint in your project, use Compass.
You should take a look at LESS syntax and SCSS syntax and choose the one your prefer. But they both are now a superset of CSS 3 and they have more or less the same features.
Another thing to know is that SCSS/SASS is still included in HAML gem. So if you want to use HAML...
I'm currently experimenting with symfony, SASS, and Compass.
I use sfSassyCssPlugin to automatically compile my .scss files.
If I want to use Compass with this plugin, do I need to modify it to use another compiler (Compass instead of SASS)?
What's the best way to use Compass with symfony projects?
I've never used the sfSassyCSSPlugin, but, after looking it up, Compass seems like a much simpler use case to me; I'd probably use it in lieu of the plugin. That said, I've never been a fan of Symfony so my judgment may be clouded. Compass doesn't worry about your app's runtime. You edit, you compile, you run. No Symfony config files to mess with, no operational changes between different environments, etc.
Compass will also "watch" for changes and just compile each time one of your .scss or, my preference, .sass files changes. You don't have to give it a second thought.
sfSassyCSSPlugin looks like an extra layer of complexity wrapped around Compass. That plug-in is for symfony 1.x, with which you're better off using Compass directly.
Navigate to the project directory and issue the following command to set things up:
compass create web --css-dir=css
And then run next command, which will watch the project and compile the CSS whenever there's a change to the Sass:
compass watch web
But if you've moved up to Symfony2 and have CSS spread out across multiple bundles, then this: https://stackoverflow.com/a/11324725/1090474 answer, using Assetic, is a better solution.