I work with front-end designers that give me a bunch of HTML & CSS files. There are some things that are very straight forward - like CSS for Twitter Bootstrap or any other framework.
But when the designer has created a bunch of other stylesheets, should I just include them in the stylesheets directory or should I just copy all the styles to the main application.css file?
Is this just a matter of style or does my approach really (or not) matter with the asset pipeline?
Thanks.
The approach doesn't usually matter, but it can matter if you do not want to include everything in one stylesheet link on the final page. I'd strongly recommend keeping the stylesheets separated for the same reason you keep code separated. Easier maintenance, less conceptual overhead per file, and easier to find where to make the change you need to make.
Even though they get combined by the asset pipeline, I tend to do one stylesheet per controller, or component, with certain shared styles (navigation, forms, common UI forms) in their own file. I haven't found the perfect solution yet (I still struggle with wanting "DRYer" stylesheets), but this works pretty well.
application.css is ment to organize css file, i remember there are comments on the top of the application.css telling not to directly write css file inside it. You should create a new css file for those style-sheet content your front-end guy gave you. And as application.css will include all the files under the stylestheet folder automatically. It will work.
Related
I'm working on a Grails app with client-side Backbone views that use Handlebars templates. Right now the views in .js files and the templates are in .html files. The .js files are rolled up together into an application bundle file, which can be compressed, cached, etc. The .html files are inlined using the Include plugin and show up directly in the generated HTML source.
This has a couple of annoyances.
for ease of development, I'd like to get these into a single file, so you don't have to find and open two files every time you want to work on a view, and you don't risk loading the .js but not including the .html or vice versa.
I'd like the templates themselves to have the benefit of compression, caching and so on rather than being repeated every time we generate HTML.
I can see some ways to do (1) -- e.g., wrap the .js in a <script> tag and embed it directly in the .html -- but they lose the benefits of (2). I can see some ways to do (2) -- e.g., precompile the Handlebars templates with the Handlebars-Resources plugin and treat them like any other Javascript -- but that doesn't get you to (1).
I guess ideally I'd have the HTML embedded in the .js files. But I don't want inline strings; I want it to be clear to my IDE that the HTML is HTML, with all the completion and error-checking benefits that entails. Is there a clean way to do that? Or another alternative I haven't thought of?
From a code maintainability point of view embedding your view code into <script> tags would be a nightmare, and I doubt it would even work. Embedding HTML in a code file is even more horrifying. Even if you could hack together some setup with grep and duct tape, I'm pretty sure there's no IDE that would understand it and give you the syntax hightlighting you want.
Just arrange your IDE windows/tabs next to each other and don't overthink it.
Use the Handlebars precompilation support. It's great.
I purchased a nice-looking Twitter Bootstrap them online that is going to spice up my Rails 3.2.8 application. The package contains the following directories:
/css
/img
/js
Of course these files will have relative links to each other in them. Is there a standard way of integrating this type of stuff into the asset pipeline, or is it still a standard practice to put it under public?
You'll want to use the asset pipeline. Everything is moving that direction and it's really not any harder (except when it is). Your files will go in the /app/assets/ directory.
For the css, you should be able to drop it right into app/assets/stylesheets/, just be sure that bootstrap is included first. There are several gems that make it easy to include bootstrap's files. I use bootstrap-sass, but you might also try twitter-bootstrap-rails (depends on if you want sass support or not). With either one, look at the readmes that I linked to as they include some useful details you'll want to know for each gem.
For the javascript, it should be about the same thing. In your application.js file, be sure that bootstrap is include before //= require_tree . in case the theme adds any custom javascript. Both of the gems I listed before also include the javascript files for bootstrap. You can read their documentation to see the details (it's almost exactly the same as normal for both gems).
As far as images are concerned, put them in the app/assets/images/ directory and you'll have to change the stylesheets a bit for it to work. When an image is declared in the stylesheet, like background: url('./images/bg.jpg');, you'll need to use the image_path helper instead, so it would look like background: url(image_path('bg.jpg'));. Notice I just included the name of the image. The asset pipeline will automatically parse this to the correct path for you.
If the theme includes any custom fonts, you'll do the same as images except using the asset_path helper like so in your #font-face declaration:
url(asset-path('museo700.ttf', font));
There are also type-specific helpers you can use, such as font-path, image-path, etc. Either asset-path with a type declared or the type-specific helper will work, just be consistent with which one you use so as not to produce confusion.
You can place custom fonts in a directory something like app/assets/fonts/. The asset pipeline will automatically find them, since they're in the assets directory.
I'm just learning the new asset pipeline in Rails 3.1. One particular problem I'm having is with the way Sprockets just mashes all the found CSS stylesheets into one massive stylesheet. I understand why this is advantageous over manually merging stylesheets and minifying for production. But I want to be able to selectively cascade stylesheets instead of having all rules all mashed together. For instance, I want:
master.css
to be loaded by all pages in the Rails app, but I want
admin.css only to be loaded by pages/views within the admin section/namespace.
How can I take advantage of the great way that Rails 3.1 combines stylesheets and minifies them for production, but also have the former flexibility of being able to load only certain stylesheet combinations per layout?
Or should this be done by adding a class to body tags in layouts-
body class="admin"
And then target style rules as appropriate. Using SASS scoped selectors this might be a reasonable solution.
This is how i solved the styling issue: (excuse the Haml)
%div{:id => "#{params[:controller].parameterize} #{params[:view]}"}
= yield
This way i start all the page specific .css.sass files with:
#post
/* Controller specific code here */
&#index
/* View specific code here */
&#new
&#edit
&#show
This way you can easily avoid any clashes.
Hope this helped some.
I have a post about this on my website:
Leveraging Rails 3.1, SCSS, and the assets pipeline to differentiate your stylesheets
And check out this answer to another question: Using Rails 3.1 assets pipeline to conditionally use certain css
Hope this helps.
Best regards,
Lasse
#nathanvda: sure...
We make use of multiple layout files. So in our app/views/layouts, instead of having just application.html.haml (we use HAML), we actually ignore the application layout and use 3 custom layouts:
admin.html.haml (admin section views only)
registered.html.haml (registered/signed in users views only)
unregistered.html.haml (unregistered/unsigned in users views only)
So at the top of my admin.html.haml file I will have my stylesheet link tags to a separate admin.scss (we use SCSS) manifest. That manifest will load any necessary sub-stylesheets just for the admin section. This allows us to specify rules just for the admin section while also making use of common styles. For instance, we use jquery-ui throughout the site, so the styles associated with jquery-ui sit in their own stylesheet and we include them in the manifests for all 3 css manifest files.
This solution doesn't give you a single CSS file that can be cached, but it ends up giving you 3 CSS files, each of which can be cached. This allows a tradeoff between performance and some flexibility in organizing CSS rules so we don't have to worry about CSS rule collisions.
The way I've been doing it so far is to have two seperate folders a/ and u/ where a/ is for the admin view and u/ is for the user view. Then in the layout I point to the appropriate application.css with assets/u/application.css(js). Bit of a pain having to move the auto generated files each time but a lot less than having to require each file individually in the manifest.
I use something like
application.html.erb
">
show.html.erb
content_for :body_id do
page_specific_body_id
end
I understand that partials in compass do not create a separate .css file. But I don't understand when/why would I ever want to use this?
Mostly just for organization and separation of logical pieces of CSS. For example, I keep a _reset.scss that I can paste into any project, then have things like _layout.sass, _homepage.sass, etc. They all get shoved into a single compiled CSS file (so I don't have to deal with multiple HTTP requests), but I can get to the styles for any given piece of a project quickly and easily.
I would like to know what are the best ways to organise CSS code in Rails project?
I'm interested in how you do it and why.
If you would like to break up your css into multiple files during development you can add cache => true to stylesheet_link_tag and rails will automatically concatenate them into a single file in production. This also works for javascript_include_tag.
http://guides.rubyonrails.org/layouts_and_rendering.html#linking-to-javascript-files-with-javascript_include_tag
Generally, you should not have the client download a massive amount of CSS snippets, but pack them into a single file on the server to avoid rendering latencies. So you have the tradeoff of having functionality divided up into multiple files put wanting to send only one file to the client.
You could use SASS to have each piece of code inside a single include file and just include all of them together. This gives you the added advantage of mixins (kind of like macros) and variables among other awesome things.
Another possibility would be to use plain CSS and use something like Jammit to pack the stuff up to send to the client.
Regarding actual setups, I tend to have one file resetting the styles to a known default, a file for the basic layout (columns, default spaces, ...), and one file each for each area of concern for your specific design (headers, buttons, ...)
James and Holger's answers are very good.
Besides organizing CSS in my projects, I also had to change colour schemes a couple of times..
Trying to do consistent changes throughout many CSS files can be pretty painful (results may vary).
I ended up extending the Rails start-up procedure a little, to include a custom module "site_settings.rb"
through which I can define variable for colors and other CSS attributes, which I can then use throughout my CSS input files.
Whenever Rails starts up, and one of the input files has changed, it auto-generates the CSS files.
http://unixgods.org/~tilo/Ruby/Using_Variables_in_CSS_Files_with_Ruby_on_Rails.html
Since Rails 3.1 is out and sprockets replaced Jammit, here an excerpt form the Rails guides concerning the asset organization:
Asset Organization
Assets can be placed inside an application in one of three locations: app/assets, lib/assets or vendor/assets.
app/assets is for assets that are owned by the application, such as custom images, JavaScript files or stylesheets.
lib/assets is for your own libraries’ code that doesn’t really fit into the scope of the application or those libraries which are shared across applications.
vendor/assets is for assets that are owned by outside entities, such as code for JavaScript plugins.