Chrome Developer Tools, integrated into the Chrome browser, offers a wonderful set of tools for debugging web pages. It would not be strange to see a front-end developer knee deep in this panel for a considerable portion of their day.
Considering how regularly Dev Tools gets updated, there’s still some excellent and quite up to date documentation on the official Dev Tools documentation page. I’ve also written a few for Nettuts+, which can be found on my author page.
The Need For Better Workflow
So what exactly are we trying to solve here? Let’s review an example of debugging some Sass-generated CSS. Given the .scss file, which contains:
$myColor: green;body {.box {color: $myColor;}}
The CSS generated by Sass will look similar to this:
body .box { color: green; }
<div class="box">Hello</div>
Okay, so far so good; now I want to begin designing and developing my page using Chrome Dev Tools. I can inspect the div with a class of box by right-clicking on it, and selecting Inspect Element. Check out the styles pane, which shows the green value on the color property and a note on the file name that it’s contained within, along with the line number that the selector appears. Here’s where the problem lies: the processed CSS does not follow line for line what the source .scss file looks like. As you can imagine, this can have a negative impact on our development workflow.
In the screenshot above, the left pane shows a source .scss file, and the right side displays the processed version. (Note: I’m using the SCSS bundle for syntax highlighting in Sublime Text.)
Dev Tools then provides a link to the file and line number of the selector (highlighted in red above), which, unsurprisingly, links to the processed file (see image below). This now serves as a limitation for editing the file, as we can’t benefit from file saving for example (if we persist changes to the processed file, they’ll be overwritten as soon as Sass compiles again).
In fact, we don’t even have a clear indication of what the corresponding line number is. Of course, practically speaking, in the above example, it would be simple for us to work out which line maps to what, by looking at the code; however, in a larger application, things can get much trickier.
As you can see above, Developer Tools has no understanding of our .scss file. (Luckily, we can fix this, as you’ll see shortly.) To summarize, a lack of Sass support in developer tools could mean:
We don’t immediately know the line number a selector and/or CSS property exists on within our source file.
Persisting CSS changes to the file system is out of the question.
Even viewing the .scss file in the sources panel can be difficult, as Developer Tools doesn’t recognize that extension as one that should be viewed.
Preparing for Sass Support
Chrome
Important: Sass support is an experimental feature. Please keep in mind that, while it has been around for a while now, things may change. If they do, we’ll do our best to update this article, accordingly.
Navigate to chrome://flags/ in the omnibox and find “Enable Developer Tools experiments.” Enable it and restart Chrome.
The image below reveals an experiments panel. You can reach this by clicking on the cogwheel at the bottom-right corner of Developer Tools, and clicking “Experiments.” Then, check the box for “Support for Sass.”
Now there’s no need to close the settings window; just go to the General menu item in the left sidebar of the settings window, and navigate to the Sources section. From there, check “Enable source maps” and “Auto-reload CSS upon Sass save.” The timeout can be left at the default value.
Sass
This tutorial uses the latest version of Sass (3.3.0, at the time of this writing), as there is some initial support for source maps. Install it through Rubygems:
gem install sass --pre
We next need to instruct Sass to compile our .scss files. Here’s a command that can be used:
This specifies that styles.scss is your source file, and styles.css is your designated name for the processed file that will be used for production.
<link rel="stylesheet" href="styles.css">
If you see something similar to the image below…
…and you see a generated .map file, along with a bunch of funny looking CSS, then, congratulations: Sass debugging is working! Here’s what those other command options are doing:
–watch: Watch for changes of the source .scss file, and compile, accordingly.
–debug-info: Output debug information to the .css file, for debuggers.
–scss: Specifies the style of Sass that we’re using.
Tip: An understanding of source maps isn’t critical for following along with this tutorial; however, it’s certainly something worth reading about, as it’s intended to help the development process. To learn more, read Introduction to JavaScript Source Maps on HTML5Rocks, and Source Maps 101 on Nettuts+.
From Elements to Sources
Assuming all went as expected, open the page in Dev Tools, where Sass support is enabled, should allow for Sass debugging. The first thing to note is that the filename will show the corresponding .scss source file, which is certainly useful. More importantly, though, the line number correctly reflects the line number in our source file!
Clicking on the filename will take you right to the sources panel with the line corresponding to the selector in question highlighted. Note that you now have a viewable Sass file right in your browser with syntax highlighting!
So finding the corresponding CSS selector from the Elements panel is a welcomed addition, but what about CSS properties?
In the screenshot below, the Sources panel has highlighted the CSS property that I was interested in. To get there, Command + Click on the property from within the Elements panel. The fact that it has taken me to the line where the value was defined (rather than the line: property: $value;) is incredibly powerful!
Please note that navigating to a CSS property in the sources panel, via a command + click, is not specific to Sass. It can be achieved with regular CSS too.
Sass Editing With Persistence
The process of editing Sass files is a bit different from vanilla CSS files. One thing that we’ll need to do is ensure that Dev Tools knows where the .scss file is located on our file system. From within the Sources panel, the left hand sidebar should have a Sources pane that displays the .scss file. Right-click and choose “Save As.” Then, overwrite the existing .scss source file.
Because we checked “Auto-reload CSS upon Sass save,” and because Sass is running in the terminal with the --watch flag, any changes that we make will be reflected in the browser quickly!
Even mixins will work as expected. Pasting the following mixin into a nearly empty .scss file within the sources panel results in the correct CSS being generated. Once compiled, Developer Tools will reload the view instantly.
Not less, as in fewer… Less, as in the stylesheet language! Work has been done to help with Less debugging; Rob Dodson recently published a great article on this very thing. Be sure to give it a read, if LESS is your preference: Debug LESS With Chrome Developer Tools.
Summary
To summarize:
Support is not enabled by default; check the boxes as mentioned above in both chrome://flags/ and Developer Tools.
Chrome Canary and the latest version of Sass (3.3.0) (due to Source maps) were used in this tutorial.
Viewing processed CSS in the Dev Tools isn’t extremely useful, as you can’t benefit from editing capabilities, and the line numbers are unlikely to match the source file.
CSS properties in the elements panel can be command-clicked. The file name displayed to the right of the selector is also clickable. Both direct you to the relevant portion in the sources panel.
Use the Sources panel editing capabilities by doing a “Save as” on the .scss file. Future saves (command + s) should overwrite the file.
Less support is limited, but will hopefully improve soon!
Additional Learning
The development workflow with Sass/Less is not perfect, but it’s certainly a lot better than what it used to be! As time goes on, Dev Tools will provide a more streamlined workflow for editing CSS files, and bugs will of course be fixed. Any issue that you might come across may be raised as a bug at crbug.com.
Tuts+ is a site aimed at web developers and designers offering tutorials and articles on technologies, skills and techniques to improve how you design and build websites.
Tuts+ is a site aimed at web developers and designers offering tutorials and articles on technologies, skills and techniques to improve how you design and build websites.