October 02, 2007 @ 04:23 PM

The Scenario

In development, Rails does something that's generally helpful, namely appending a querystring to asset paths (stylesheets, javascript includes, etc.) like so:

/stylesheets/application.css?1190414487

This is useful because some browsers stubbornly cache content regardless of their local modifications or the etags you send them. Even the more modern browsers occasionally just futz things up. So the fact that Rails forces the browser to re-download my assets in development to ensure the most recent changes are always shown is great. However...

I recently started using CSSEdit from MacRabbit software, whose X-Ray feature has proved invaluable a few times recently in solving some complicated layout issues. Another really useful feature of CSSEdit is it's Live Preview, which (I believe) uses the WebKit engine to constantly update a user stylesheet for the page it's embedded browser is viewing, so you can see how your changes affect the page in real time.

The Problem

This really cool feature is also where my problem starts. To achieve this effect, it overrides the entire stylesheet path. Remember this: application.css?1190414487 ? That number in the querystring is the asset's modification time… The other end of the equation in how CSSEdit's override works is in a comment it places at the top of your CSS file ala:

/* @override http://localhost:3000/stylesheets/application.css?1190414487 */

So, as you're editing that file in CSSEdit, it's modification time changes, and the first time you refresh the CSSEdit browser (CSS and HTML edits often go hand-in-hand), the override no longer works, since the stylesheet path is now different than what it's being told to override.

Two Simple Solutions

The "if it hurts, don't do that" solution:

When setting up your Override for CSSEdit's live preview, use the "Extract and Override" option.

This copies the stylesheet in question into a new stylesheet which then overrides the current rendered pages. The key here is that since you're not editing the actual stylesheet linked in the page, the modification time doesn't change and it therefor continues to be overriden when you reload the page.

The "I'm so stubborn it hurts" solution:

If you stubbornly insist on editing the actual file you're overriding (like myself), there's another solution still, but one you'll want to use with a bit of prudence.

Doing a bit of digging into how rails adds that modification time will bring your attention to this private method:

ActionView::Helpers::AssetTagHelper#rewrite_asset_path!

which attempts to use an ENV key named RAILS_ASSET_ID *or* the files modification time. So... throwing:

ENV['RAILS_ASSET_ID'] = ''

in your development.rb effectively turns off the modification querystring, which allows overrides to work as expected without having to worry about updating your override after every refresh.

Alternatively, since CSSEdit uses a slightly modified WebKit UserAgent string:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en) AppleWebKit/419.3 (KHTML, like Gecko) Safari

vs Safari's:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en) AppleWebKit/419.3 (KHTML, like Gecko) Safari/419.3

you could monkey patch that method in development, which would give you the option of doing something like browser sniffing the CSSEdit browser and conditionally stopping Rails from adding the modification time to the assets path. I whipped up a simple plugin: cssedit_asset_id_fix to illustrate this technique (which is coincidentally the method I'm using).

NB: if you choose to use the demonstration plugin, do note that since it uses browser sniffing, it is inherently prone to breakage. Something like this is only acceptable in development, in my opinion.