FireSass Bridges the Gap Between Sass and Firebug
This post has been translated into Belorussian by PC.
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.

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.

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.
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
About Me
Feed
Sass 2.4 will now be Sass 3.0



Go, Nathan! That’s fantastic.
I get undefined method `rails_env’ for Haml::Util:Module with haml-edge 2.3.175
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..
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.
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
@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.Anyone else getting “Invalid file hash” when trying to install the add on?
@Aaron Gibralter: yes
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.
Awesome, thank you!
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?
Thanks.
(BTW, at the other end, I have Sass correctly compiling the required debugging info into my stylesheets.)
Those tabs only show up if you have the HTML tab selected – they’re views into the style of the selected element.
Thanks. That worked.
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.
e.g.,
@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; }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.
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
Unfortunately, I don’t think Firefox supports
voice-familyeither, 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 thefilenameandlineselectors in such a way that IE won’t see them; or we just bite the bullet and use thecontentproperty and decode the string value in Javascript.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.