Less/Sass debugging in Chrome Dev Tools/Firebug [closed]

Answer 1

Chrome Developer Tools now supports Sass debugging out-of-the-box.

Updated to include source maps:
Previous versions used inline comment in your css to provide a refernce to the source code (see below how-to). recent versions of sass (3.3+) and chrome (31+) use source maps for that:

1. Make sure you have Sass 3.3.x
2. Compile your Sass with the --sourcemap flag.
3. In Chrome/ium DevTools open settings and click general.
4. Turn on "Enable CSS source maps".

More info is available on the Chrome dev tools blog: https://developers.google.com/chrome-developer-tools/docs/css-preprocessors

Older versions:
1. First, you should compile your Sass with --debug-info turned on.
2. In Chrome/ium go to about:flags
3. Enable Developer Tools experiments
4. In your inspector (F12), open "Settings", then go to the "Experiments" tab and check "Support for SASS".

Answer 2

If you're making a choice as to which you should be using, this article on css-tricks might be of interest to you.

I have come to experience that using LESS or SASS has more advantages than disadvantages. Though this is certainly a disadvantage I can only suggest you structure your files well so any styles you seek are easily found using other references, here are a few things you can do:

• Document areas of your stylesheet; ie /* General */, /* Header */ and /* Footer */
• Use logical and sensible names for classes you can recognize quickly (and don't number them like error1-error10 or something)
• Learn to dissect the class/element/id selectors and think about how/where you would have written them.
• Use CTRL+F, often the precise attribute or one near it is fairly easily found this way

SASS

There is now a way to debug SASS in firefox using an extension that reads and displays the sass files in the firebug inspector. To use, install the extension and enable the respective debug flags.

https://addons.mozilla.org/en-US/firefox/addon/firesass-for-firebug/

Edit: as of 2014-07-06, this plugin is no longer available for download. FireSass has been discontinued.

Chrome/Webkit versions have been popping up around the net and theres a beta feature in chrome to add support for SASS debugging. It's based on the same debugging information used in the firefox version. Haven't been able to judge any of them properly as of yet, nor found something which is publicly accepted as being the plugin for the job as of this writing.

LESS / STYLUS

As this tweet @jaketrent points to explains, there is progress on the debugging side in chrome, but nothing baked in yet and given the state of the LESS github it might still take a while... Both solutions are based on the beta feature for SASS debugging support in chrome, basically adding the same debug information as SASS does.

• https://github.com/cloudhead/less.js/pull/1038
• https://github.com/LearnBoost/stylus/pull/886

Answer 3

Some tips:

• Include both the .sass and the .css files in version control. This way everyone has the most current changes.
• If you organize your stylesheets into logical areas, maintenance is a breeze.
• Also: try to use fewer than three main colors, and then use SASS color functions to modify them and store results in variables that you can reuse throughout your design/theme.

Ex: $chartreuse: #7fff00 $olive: darken($chartreuse, 32%)

That way, you only have to maintain one color. And the rest will be recalculated.

---

Until recently, there were no in-browser SASS debugging tools.

There is now a Firefox plugin called FireSASS (https://addons.mozilla.org/en-US/firefox/addon/firesass-for-firebug/)

In your sass --watch command, add a -g for --debug-info so that it will output the hooks needed for the plugin to run.

Answer 4

I switched from less to sass, because of firesass. With this you get the original sass line in firebug.

install firesass if you use sass

Answer 5

I rarely have issues with maintenance/debugging in LESS -- we always compile on the server end and reference only the CSS file in the HTML page. This makes it so there's always a one-to-one correspondence with the webpage and a file on disc.

And then when I have to edit the LESS file, I find that LESS, since its pretty much CSS+extra markup, it's quite easy to backtrace anything I'm confused about to the originating statement in CSS. If it's a mixin, it's pretty obvious (since I usually use mixins to prevent having to do all the vendor prefix stuff repeatedly), and then it's just a logical hierarchy since we use the class nesting feature, so finding:

div#awesome aside ul

is as easy as finding:

div#awesome{
    aside{
        ul{
            padding: 0;
        }
    }
}

(although we try to not go more than 3 layers deep)

I have no real experience with SASS but I didn't like how far removed from CSS it was when I first looked at it a few years back (and haven't been back since...)