Here is what worked for me. Obviously change path to work for you and your specific ruby version:
gem install ruby-debug19 -- --with-ruby-include="/Users/scott/.rbenv/versions/1.9.2-p290"
Friday, September 23, 2011
Monday, September 5, 2011
Rails 3.1 require_tree CSS
This is a post about a Rails 3.1 convention and choice used to assemble your application's CSS file. Its not a post about the general idea of the Rails 3.1 asset_pipeline, but assumes familiarity with that. I also offer a simple alternative that might be considered that isn't too far off from the default.
It's a trivial thing that I've griped about a few times, but the choice in Rails 3.1 to link to a application.css manifest file that includes a "require_tree ." directive off of the app/asset/stylesheet root is imho a stupid convention. For one thing, when building a CSS solution for an application, the order of the included CSS matters. And if all of these CSS files are assembled into a single application.css, the order of inclusions still matters. I realize that it is simply the default application.css, and it is very easy to delete the one line that says "require .". But if every real application will need to do this, then I think its a pretty stupid convention.
If your entire application's css file was only ever the assembly of some n controller_name.css files, then this would be a moot point, and the Rails default "require_tree ." would be fine. But I think its a fair statement to suggest that is fairly close to never the case.
I appreciate the idea of making things dead simple for people just getting started. And I get the fact that the default action of a controller generator is to create a controller_name.css.scss file. And I get the fact that this "require_tree ." by default provides a out of the box experience that stitches all these files together to create your application.css.
The problem is that seldom if ever in an application do you create a CSS solution that doesn't involve some hierarchy to its style rules. Often you will include some basic typography rules defined in one or more files, some basic layout rules in another, some basic color rules in yet another, etc. and then apply some hierarchy of granular changes on top of these as necessary. Even if you don't take a typography, layout, color approach to foundation, in any real application you will have some foundation rules, that are then refined in a cascading or granular fashion, where the order of these subsequent granular rules is important.
Additionally, in applications built today, you often have a different set of basic foundation rules applied for different reasons (different section of your application, different media, different browser, different resolution, etc.). In the Rails 3.1 asset approach, all of these styles will need to be defined at some point under app/assets/stylesheets. You would almost never want everything under your stylesheet root to always be included, and especially in a manner where order has no significance!
So, my basic gripe is that seldom (if ever!), will you have a situation that suggests assembling all css under your "root" css directory will make sense. And additionally, this will almost never be a best practice convention that anybody building a real application would be able to use. So, why does Rails 3.1 use this as its out of the box convention?
A fair alternative to the out of the box convention for Rails to follow might be to build all controller_name.css.scss files in a subdirectory off of app/assets/stylesheets, perhaps app/assets/stylesheets/resources (or controllers). And then the default convention in application.css might be to "require resources/." by default.
Then if Rails wanted to promote some additional best practices, they might include some top level foundation css (like typography, layout, color, etc.) or even just a base.css.sass that could be explicitly required in the application.css to give the new developer a convention that is at least built upon some real world best practices to creating CSS solutions.
A default asset pipeline application.css file that looks like this:
/*
* This is a manifest file that'll automatically include all the stylesheets available in the resources directory
* and any sub-directories. You're free to add application-wide styles to this file and they'll appear at
* immediately after your foundation styles, but it's generally better to create a new file per style scope.
* Application foundation styles
*= require 'typography'
*= require 'layout'
*=require 'color'
* Specific styles
*/
or even just this:
/*
* This is a manifest file that'll automatically include all the stylesheets available in this directory
* and any sub-directories. You're free to add application-wide styles to this file and they'll appear at
* the top of the compiled file, but it's generally better to create a new file per style scope.
*= require_self
*= require_tree .
*/
It's a trivial thing that I've griped about a few times, but the choice in Rails 3.1 to link to a application.css manifest file that includes a "require_tree ." directive off of the app/asset/stylesheet root is imho a stupid convention. For one thing, when building a CSS solution for an application, the order of the included CSS matters. And if all of these CSS files are assembled into a single application.css, the order of inclusions still matters. I realize that it is simply the default application.css, and it is very easy to delete the one line that says "require .". But if every real application will need to do this, then I think its a pretty stupid convention.
If your entire application's css file was only ever the assembly of some n controller_name.css files, then this would be a moot point, and the Rails default "require_tree ." would be fine. But I think its a fair statement to suggest that is fairly close to never the case.
I appreciate the idea of making things dead simple for people just getting started. And I get the fact that the default action of a controller generator is to create a controller_name.css.scss file. And I get the fact that this "require_tree ." by default provides a out of the box experience that stitches all these files together to create your application.css.
The problem is that seldom if ever in an application do you create a CSS solution that doesn't involve some hierarchy to its style rules. Often you will include some basic typography rules defined in one or more files, some basic layout rules in another, some basic color rules in yet another, etc. and then apply some hierarchy of granular changes on top of these as necessary. Even if you don't take a typography, layout, color approach to foundation, in any real application you will have some foundation rules, that are then refined in a cascading or granular fashion, where the order of these subsequent granular rules is important.
Additionally, in applications built today, you often have a different set of basic foundation rules applied for different reasons (different section of your application, different media, different browser, different resolution, etc.). In the Rails 3.1 asset approach, all of these styles will need to be defined at some point under app/assets/stylesheets. You would almost never want everything under your stylesheet root to always be included, and especially in a manner where order has no significance!
So, my basic gripe is that seldom (if ever!), will you have a situation that suggests assembling all css under your "root" css directory will make sense. And additionally, this will almost never be a best practice convention that anybody building a real application would be able to use. So, why does Rails 3.1 use this as its out of the box convention?
A fair alternative to the out of the box convention for Rails to follow might be to build all controller_name.css.scss files in a subdirectory off of app/assets/stylesheets, perhaps app/assets/stylesheets/resources (or controllers). And then the default convention in application.css might be to "require resources/." by default.
Then if Rails wanted to promote some additional best practices, they might include some top level foundation css (like typography, layout, color, etc.) or even just a base.css.sass that could be explicitly required in the application.css to give the new developer a convention that is at least built upon some real world best practices to creating CSS solutions.
A default asset pipeline application.css file that looks like this:
/*
* This is a manifest file that'll automatically include all the stylesheets available in the resources directory
* and any sub-directories. You're free to add application-wide styles to this file and they'll appear at
* immediately after your foundation styles, but it's generally better to create a new file per style scope.
* Application foundation styles
*= require 'typography'
*= require 'layout'
*=require 'color'
* Specific styles
*= require_self
*= require_tree resources/.*/
or even just this:
/*
* This is a manifest file that'll automatically include all the stylesheets available in the resources directory
* and any sub-directories. You're free to add application-wide styles to this file and they'll appear at
* the top of the compiled file, but it's generally better to create a new file per style scope.
*= require_self
*= require_tree resources/.
*/
instead of the Rails default of this:
/*
* This is a manifest file that'll automatically include all the stylesheets available in this directory
* and any sub-directories. You're free to add application-wide styles to this file and they'll appear at
* the top of the compiled file, but it's generally better to create a new file per style scope.
*= require_self
*= require_tree .
*/
Subscribe to:
Comments (Atom)