FireSass Bridges the Gap Between Sass and Firebug

Posted March 22, 2010

This post has been translated into Belorussian by fatcow.

One of the most common usability issues people have with Sass is integration with existing tools. In particular, a lot of people (myself included) use Firebug and wish it played nicer with Sass.

In general, since Sass compiles to standard CSS, Firebug can deal with it just fine. One of the nicest features of Firebug when doing CSS work, though, is the ability to tell you where all the styles for an element are defined in your CSS.

When using Sass, this feature basically doesn’t work. It tells you where the style was defined in your CSS… which doesn’t really help you figure out where it was in the original Sass.

Firebug without FireSass

Introducing FireSass

On Friday, I became fed up with this and decided to fix it once and for all. The fruit of my effort is the FireSass extension for Firebug. Combined with a new debugging output option for Sass, FireSass is able to tell the user the Sass filename and line number for all the Sass styles.

Firebug with FireSass

Using It

First of all, install the FireSass extension itself, and make sure you’ve got FireBug installed as well. Until the extension gets more reviews and is vetted by the Mozilla editors, it’ll be listed as experimental. The code’s available on Github if you want to make sure it’s not malicious (it’s not).

Once the extension’s installed, you’ll need a recent development version of Sass. The easiest way to get this is to install the haml-edge gem by running gem install haml-edge. You can also install it as the haml gem by downloading it from GitHub and run rake install in the haml directory.

The :debug_info option is now in the most recent release of Sass, so you don’t need a development version anymore.

Next, you’ll need to configure Sass to compile in the necessary debugging information. This just involves setting the :debug_info option. If you’re using Sass with a Ruby web framework, you probably want to do

Sass::Plugin.options[:debug_info] = true

If you’re using Sass from the command line, just pass in the --debug-info flag.

Finally, delete all your existing CSS files to make sure they’ll be regenerated, and you’re good to go!

How It Works

I originally added the :line_numbers option to Sass in hopes of making a plugin like this that could read the line numbers and filenames and display them instead of Firebug’s normal line and filename information. Unfortunately, it turned out that in parsing the CSS file, all comment information was thrown away.

Next, I played around with passing in the information as custom properties. -sass-line-number and -sass-filename properties would have been a nice solution, but alas the browser discards all unknown properties just as thoroughly as it does the comments.

I gave this up for a year and a half, until this Friday night. Being upset at the lack of Firebug support, spurred on by two people in #haml on Freenode, I decided to take another look at the problem. And I came up with an awful, circuitous, but ultimately functional hack.

The trick is media declarations. If a media declaration for an unknown media type is used, all the rules for that declaration are ignored but they’re still available via Javascript. Thus, I packed all the debugging information for each rule into a media declaration like the following:

@media -sass-debug-info { ... }

Even after this, there’s still substantial complexity; if you’re interested, I suggest you read the Sass and FireSass code directly. The upshot, though, is that the data is there, and FireSass can read it.

Of course, adding an extra @media declaration for each rule creates a lot of stylesheet bloat. Thus :debug_info is automatically disabled when using the :compressed output style, which should always be turned on in production

Billy Gray said March 22, 2010:

Go, Nathan! That’s fantastic.

Sharad jain said March 22, 2010:

I get undefined method `rails_env’ for Haml::Util:Module with haml-edge 2.3.175

Sharad jain said March 22, 2010:

Nevermind. Deleting .sass-cache folder and public/stylesheets/compiled folders, and adding haml-edge config.gem dependency did the trick, and I see .sass links.

Clicking on those still jump to .css, which is kind of expected since .sass files aren’t downloaded by browser. So, do I understand it correct that it shows the line in .sass file where it came from but can’t jump to it. This you could achieve by looking at .css file which already had line numbers for .sass location in it (before this plugin).

Or is there some more that I am missing..

Nathan said March 22, 2010:

Sharad: You’re correct that it jumps to the CSS file. If I figure out how to convince Firefox to open the Sass file as plain text, I may make it jump there instead.

kev said March 22, 2010:

I can’t seem to get this working. I am using compass on the project and have sass using—debug-info. It is outputting the css with the correct—debug-info comment lines. I have FF 3.6 with FireBug 1.5.3. and the FireSass Extension. I Have removed the css files and re compiled, also cleared out the .sass-cache. Firebug is still parsing the css as normal.

I have haml-2.2.22 did not use haml-edge

any ideas would be much appreciated

Sean McCleary said March 22, 2010:

@kev, I am in the same boat. Either update to haml-edge or wait patiently, like me, for haml to come out with a release that supports this feature. I you can test your version of sass by doing as the article says and running sass from the command line with “sass --debug-info”. If sass does not support that flag, you have to wait or update to haml-edge.

Aaron Gibralter said May 11, 2010:

Anyone else getting “Invalid file hash” when trying to install the add on?

Yong Bakos said May 12, 2010:

@Aaron Gibralter: yes

Nathan said May 13, 2010:

I’m working on fixing the “invalid hash” thing. It seems to be a bug in the Mozilla site, so I’m waiting to hear back from them about it. For the time being, you can also download it from here.

Aaron Gibralter said May 13, 2010:

Awesome, thank you!

Steven Noble said May 18, 2010:

Your screengrabs show a Layout tab and a Style Tab.

I have installed Firebug and Firesass but I see neither of these tabs.

Any thoughts?


(BTW, at the other end, I have Sass correctly compiling the required debugging info into my stylesheets.)

Nathan said May 18, 2010:

Those tabs only show up if you have the HTML tab selected – they’re views into the style of the selected element.

Steven Noble said May 19, 2010:

Thanks. That worked.

Cris Necochea said May 28, 2010:

have any of you found that the @media queries in the rendered css did odd things to IE? we lost all our font properties in IE6 and IE7. looks like the font-family property in -sass-debug-info wreaked havoc.


@media -sass-debug-info{filename{font-family:file\:\/\/\/Users\/me\/Documents\/Code\/website\/public\/stylesheets\/sass\/shared\/minimal\.sass}line{font-family:\000034}}
body {
  font-size: 100%;
  margin: 0 0 0 0;
  background-color: white;
  font-family: Verdana, helvetica, Sans-Serif;
  *position: relative;
Nathan said May 28, 2010:

Ugh, really? I’ll admit I didn’t test the debug info on IE6/7. I can’t imagine why that would happen, but I wouldn’t put it past IE.

Not sure that the proper workaround here is… any other property that IE recognizes will presumably have the same problematic behavior. Is there some property that takes an arbitrary identifier but is only recognized by modern browsers? It can’t be Mozilla-specific because I’d like the same debug info to be usable by other browsers, including potentially more modern IE versions.

Cris Necochea said May 28, 2010:

what about any of the aural css properties like voice-family, azimuth, pitch and elevation? they’re damned obscure and the voice-family hack is already an established way of punking IE. thanks for being so quick to respond.

here’s some useful info in this direction

Nathan said May 28, 2010:

Unfortunately, I don’t think Firefox supports voice-family either, since it’s not an aural browser. We need a property that Firefox (and other browsers) won’t simply discard. I think there are two potential ways to deal with this. Either we see if we can find a way of specifying the filename and line selectors in such a way that IE won’t see them; or we just bite the bullet and use the content property and decode the string value in Javascript.

Joe said August 11, 2010:

Yeh a little warning that using the debug mode may screw your IE styling would be appreciated – just lost a few hours trying to work out why my styles were out of whack. Finding Sass so much easier to refactor with this though. Great work.

Steven Noble said October 03, 2010:

I’m having a small problem here.

I’m running Rails 3 with Haml 3, Sass 3, Compass and Susy.

In my Gemfile, I have: gem “haml-edge”

The last line of my config/environment.rb is: Sass::Plugin.options[:debug_info] = true

I have installed Firebug and FireSass into Firefox.

As far as I can tell, the only thing non-standard about my installation is that my SCSS files are in public/stylesheets/css, but this is noted correctly in config/compass.rb

I have deleted all previously generated CSS files and the tmp/sass-cache directory before restarting the server and compass watch.

And yet the @media annotations don’t appear in my CSS files, and Firebug references my CSS files not my SCSS files.

What should I try next?

Nathan said October 03, 2010:

Steven: If you’re using Compass, you need to set :debug_info in Compass’s configuration, rather than using Sass::Plugin. The same is true for any other Sass options you need to set with Compass.

Luis Martins said December 01, 2010:

I use this everyday, it is absolutely essential for me. Yesterday i had to uninstall of Firebug because it breaked Firesass. Firebug ppl says it probably is something in the Firesass plugin. Just wondering if the plugin will get any updates soon.


Anonymous said December 06, 2010:


this is what I’ve been waiting for ever since CSS preprocessing came out – but I’ve had various headaches with ruby (just a designer) and moved to lesscss – is there a change that firesass will be extended to work with lesscss? Does it work with scss now?

Thanks very much for taking this on – the lack of firebug support has been the biggest barrier to designers being able to adopt this approach (with the possible exception of ruby..)

Nathan said December 06, 2010:

Luis: I’ll look into incompatibilities with Firebug 1.6 as soon as I can.

Anonymous: No, it won’t support Less, since it’s a competitor to Sass and FireSass is one of our distinguishing features. It does support SCSS, though.

Josh said December 08, 2010:

Is there an alpha version of FireSass that would work with Firefox 4, Firebug 1.7 Apha? Do you have an expected arrival date if not?

Many thanks :)


Nathan said December 08, 2010:

Josh: No, not at the moment. Once I have a chunk of time to devote to it, I’ll do so, but for the time being I’m focused on Sass 3.1. I encourage people who want it sooner to try their hand at upgrading it themselves; it’s not a terribly complex piece of code.

Jesse said October 12, 2011:

Hello I have been struggling with trying to get firesass working with a rails 3.1 project using compass, with firefox6.0.2, firebug 1.9.0a3, Firesass 0.0.7

I am not sure if I am pasting Sass::Plugin.options[:debug_info] = true or sass_options = {:debug_info => true} into the right place(s). Not entirely sure which files are considered the compass configuration files. Have tried with both the files in the application and within the gems/compass directory. Has anyone sucessfully used firesass with a similar configuration and could point me to where the files would be? If this configuration won’t work is it possible to downgrade firebug to the last version compatible with firesass?

M_Brico said December 09, 2011:

If using Compass enter the following line into your projects config.rb:

sass_options = {:debug_info => true}

Then, in terminal, navigate into your project directory and re-compile your files using:

compass compile—force

Make your comments snazzy with Textile!