I am using Bootstrap for my Rails 4 app with asset_pipeline. asset_pipeline automatically concatenate all js and css files into one each.
However, the files are quite large (~120K) and take a long time to load. Is there a way to automatically remove css elements and js methods that are not used in my app from the base files?
From the accepted answer on How do I identify and eliminate unused CSS styles from my bloated stylesheet? you could try:
https://addons.mozilla.org/en-US/firefox/addon/10704/
Credit to Steve Fenton
Remember also that you should be gzipping the css & JS files at the server level, so the actual file size will be substantially less than 120 K
Good luck!
Related
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.
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.
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 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.
we are working on a large web application with Rails for quite a while and produced a lot of css for our templates. Stylesheet definitions are organised in a bunch of css files that have grown with the project. As people are not always as disciplined as they should be, it seems to me that a lot of definitions have become deprecated and useless.
Is there an (semi-)automatic way to get rid of this stuff? How do you identify useless css in your project?
You can use the Dust-Me Selectors plugin for Firefox or the CSS redundancy checker.
Both are great tools that I use often and they save you hours of searching and deleting.
Another tool worth making note of also is the CSS Tidy open source project. This minifies your CSS, especially useful in these cases when you have a huge site with a huge CSS file :)
I believe the sourcecode for the CSS Redundancy checker can be found here. Ran it through the JSLint plugin at jsFiddle.net but gave me some errors, saved it for everyone here.
Not exactly a 'rails' solution but you don't always need one. I use the Dust-Me Selectors firefox plugin to find unused selectors. Works for me.
edit: kyle beat me to it
We didn't have a particularly large CSS file (about 3500 lines) and we found it sufficient to grep the codebase for each selector. (Obviously this can be semi-automated with shell pipes, xargs and friends).
Following this process, we ended up deleting a few too many CSS styles, thanks to some of our CSS style names being dynamically generated (a bad idea in retrospect).
For more detail about our workflow and results, I co-wrote a few thousand words about our experience turning the CSS from a Rails 2.x app into an asset pipeline ready, responsive and modular Rails 4.2.x SASS setup.
CSS Refactoring: From append-only to modular CSS