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.
Related
I am using slim for a project outside rails. I see that slimrb gives options to compile the templates to html from command line.
1) However is there a way to compile a complete view directory to html.
2) Also is it possible to watch for changes and, continuously update the generated html, like what compass does for .scss files.
There are actually two complete solutions to this problem! Both are quite easy to implement:
The Slim Guard plugin
Every Ruby developer should know about Guard. It's the easiest way to automatically transpile files.
There are actually two Slim guards on GitHub, and unfortunately the main one is older and not as good. I would recommend using indrekj/guard-sim (the one I linked to).
The RubyMine IDE by JetBrains
Truly exceptional software, RubyMine is heaven for Rubyists. It has built-in file watchers that you can configure on a per-project basis for transpiling all your typical assets. It's simple to set up a watcher for the Slim files using the slimrb program, and you're provided with a slew of customization options.
In RubyMine, you can import/export file watcher configurations; I host a few here, including one for Slim.
1) To compile all files in a directory from slim to html cd into it and type slimrb * and then hit tab to expand * into all filenames in that directory. Since it is a view directory there should be no other files then *.slim
2) Slim itself doesn't imlement this, but it shouldn't be too hard to write a script which listens for filesystem events and triggers based on which file was changed the slimrb executable.
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
I've seen that certain Rails CMSes (like Radiant) have plugins that essentially compile Sass when a page is accessed. Is there a way to do this in a regular rails app? Is doing so performant? Basically, I'm looking at a way to remove the extra step of running Compass to compile my stylesheets.
I've not used compass specifically but there looks like there's a production flag so files are compiled - I couldn't imagine they'd build it to recompile per request in production, Radiant compiles it's css on Application startup and if you then commit those generated CSS files it doesn't try to generate them again AFAIK.
http://compass-style.org/docs/tutorials/production-css/
Sass and Compass automatically integrate with Rails. If you're using Rails 3, all you have to do is add gem "haml" to your Gemfile and all .sass and .scss files in public/stylesheets/sass will get compiled to .css files in public/stylesheets.
Compile per request? I think it could be a hit for performance. You should definitely use a caching strategy in that case. So that it compiles the stylesheet only if it is not in the cache.
You could create a helper method setup_stylesheet that will take care of setting up the css stylesheet. You call this method on the application layout.
setup_stylesheet will check if the css stylesheet is on the cache, and if it is there then use it. If it is not, then compile it.
Another approach:
You could set up an initialiser that will call Compass to compile your SASS stylesheets when the App is launched.
Is doing so performant?
There will be a massive performance hit when compiling at run-time.
As Nex3 (author of Sass gem) pointed out on another forum, there's no need any need to run compass watch.
I strongly advise putting the following into production.rb: Sass::Plugin.options[:never_update] = true - this is especially important if you're on Heroku. (you could also do this in your rack file, where you can also specify other options
Hmm, good luck
I have a Rails project that is basically a simple web app for a membership-based organization. We've open sourced the code on Github for the web app so that others can use it, but have a licensed design/layout that the original organization is going to use. This layout cannot be open sourced. I was wondering if others have run into the situation where you have an open-source Rails app with a non-OS design.
My initial thought is to put app/views in .gitignore, and to have anyone forking the code add their own views directory, perhaps including an app/views_default directory with a web-app-theme layout or something else to get people running. Is this the best option (realizing that there are other files such as JavaScript, CSS, etc that come with the layout that must also be ignored).
Does anyone have some good thoughts or pointers on this?
Hoopla - svn:externals for Git.
Instead of git:ignore, you can push the non-open-source stuff somewhere else, and your open-source code on github. Use hoopla to manage the externals.
http://6brand.com/git-svn-externals-rails-plugins.html
Rails Theme_Support plugin: http://github.com/aussiegeek/theme_support (There are forks as well). You can create a theme directory with multiple themes, and load the theme programmatically in ApplicationController. This would allow anyone to use the application, and simply supply their own theme in the themes directory, and would allow the project to have a "default" theme which would serve as an example.
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.