Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

January 21 2014


Working With LESS and the Chrome DevTools

This is a complete tutorial to using LESS with Chrome’s DevTools. If you’ve already used Sass with Chrome’s DevTools, you’ll most likely already be familiar with the concepts introduced here.

The Tl;dr

  • LESS has very recently added support for Source Maps, so this is new and exciting!
  • DevTools mapping means you can view LESS styles for all your relevant CSS.
  • Edit LESS source files within DevTools and have them save to disk.
  • Source Map adoption is improving with Sass, CoffeeScript, UglifyJS2 and more.


Not too long ago, the Chrome DevTools added a number of IDE-like features (and continues to do so), one of which is the ability to understand the mapping between a compiled file and its corresponding source file. This is made possible thanks to Source Maps.


What This Tutorial Will Cover

  • How to generate Source Maps from LESS files.
  • Debugging LESS code through the DevTools.
  • Authoring LESS code in the DevTools and seeing changes immediately via Workspaces and Grunt.

Everything mentioned here is available in Chrome Canary.

Configuring LESS for Source Maps

First thing’s first, install the latest (1.5.1 at the time of this writing) version of LESS through NPM (Source Maps arrived in 1.5.0):

$ npm install -g less
$ lessc -v
lessc 1.5.1 (LESS Compiler) [JavaScript]

At this point, you can run the LESS compiler in your terminal using the lessc command.


Create a new LESS file, for demonstration purposes, it’ll be kept short and simple.

@color: #4D926F;
#header {
  color: @color;

To turn the LESS file into a CSS file, it’s a simple case of running:

lessc header.less header.css

We now need a Source Map file. Create it with the -source-map flag.

lessc header.less header.css

Using the LESS code shown above, running this command produces a Source Map file with the following contents:


Using DevTools to Map to LESS Source Files

In a world without Source Maps, DevTools would display styles originating from the compiled CSS. Line numbering would not be useful due to a mismatch between compiled CSS and the source CSS. With Source Maps, when inspecting a DOM node on the page, DevTools will automatically show the styles originating from the LESS source file.

Viewing a web page which references the previously mentioned header.css is now inspectable in a more meaningful way.


While holding Command (Ctrl on Windows), click any property, value or selector to jump to the line of code in the corresponding LESS source file within the Sources Panel.

Authoring Workflow With DevTools & LESS

Viewing LESS code in the DevTools is certainly useful, but integrating an authoring workflow can speed up your iteration cycle. The next step is to tell DevTools how the resources on a web page map to files on a file system. Enter: Workspaces.

Note: Workspaces are suitable for many projects, not just those using CSS preprocessors.


You might already be familiar with the Sources panel from an editing perspective. The general idea is that you have a file navigator in the sidebar where each file is typically a stylesheet, script or HTML resource that the web page has loaded.


Clicking on a resource displays the contents in the main panel, you may notice the similarity this has with the Resources panel, however there is at least one major difference: the Sources panel contains a live editor. Changes you make to stylesheets are applied to the page instantly and changes you make to scripts are injected back into the V8 engine and evaluated immediately. Not only does this work for remotely hosted files, but also for local ones with the added benefit of persisting your changes to a file.

Note: To make use of Workspaces, the following steps are only required once per project.

Step 1.

Open up a local webpage and add its corresponding folder on your file system to the workspace by Right-Clicking in the Sources panel sidebar and selecting Add folder to Workspace.


Step 2.

Allow DevTools access to the folder you’ve just added.


Step 3.

Your newly added folder will appear in the sidebar navigation.


Right-click on a file within a network resourced folder in the Sources Panel (make sure it has an obvious mapping to a file on your file system) and select Map to File System Resource.


Step 4.

The first suggestion provided by DevTools is the correct one. It has noticed that the file on my file system (/Users/.../bootstrap.css) has the same name as a network resource file (http://localhost/.../bootstrap.css). Verify the mapping by selecting the correct resource.


DevTools now understands the mapping between filesystem resources and network resources. When you Cmd/Ctrl-Click a selector from the Styles pane and end in the Sources Panel, you’re now being shown your actual LESS source file. You can edit a file in the Sources panel and those changes will persist to disk when you Command/Control+S.

We’ve come all this way, so let’s complete this workflow by using a Grunt watch task to watch for changes made to the LESS files and then automatically compile our CSS and make a corresponding Source Map file.

Using Grunt to Watch & Compile LESS

With Workspaces set up, configure Grunt (or another tool of your choice) to watch for changes to LESS source files and compile a new CSS file (with a Source Map). DevTools will pick up this change automatically and apply any new styles to the page.

Note: Enable the Auto-reload generated CSS flag in the Settings panel to use this workflow.


Here is an outline of the automated steps which will occur:

  1. You save a change to a LESS file via DevTools.
  2. A watch task monitors LESS files for changes and then runs a LESS task.
  3. The LESS task compiles a new CSS file plus a Source Map file.
  4. DevTools injects the new CSS file onto the current page without a page refresh.

Here’s a simplified Gruntfile:

module.exports = function(grunt) {
    'use strict';


        less: {
            dev: {
                options: {
                    sourceMap: true,
                    sourceMapFilename: ''
                files: {
                    'less/bootstrap.css': 'less/bootstrap.less'
        watch: {
            all: {
                files: ['less/**/*.less'],
                tasks: ['less'],

    grunt.registerTask('default', ['less', 'watch']);

Note: The code snippet above comes from the demo repository.

After an npm install, running grunt in your terminal should show a watch task running.


DevTools already has write access to your development folder (through Workspaces). Cmd/Ctrl+S your changes in the Sources Panel to have DevTools overwrite the source LESS file with your new change, Grunt compiles a new CSS file which DevTools pulls in and applies to the page.


  • During development and debugging, looking at your source file (rather than the compiled file) will almost always be more useful to you.
  • For DevTools to understand source file mappings, it needs to be compatible with the Source Map v3 proposal which is up to the compilation tool to implement.
  • Tools adopting Source Maps are improving, we have Sass, Compass, LESS, autoprefixer, UglifyJS2, CoffeeScript and more. There are grunt-contrib-* tasks for most of these tools (Sass, Compass, LESS, autoprefixr, UglifyJS2, CoffeeScript) which tie in nicely with a livereload workflow.
  • Viewing LESS files will work out of the box with DevTools. To actually edit files, try out Workspaces which gives you the ability to persist changes to disk.

Further Reading

Source Maps


Chrome DevTools

June 20 2013


Developing With Sass and Chrome DevTools

In this article we’ll take a look at how we can better integrate Chrome DevTools into our Sass development workflow.

Tutorial Sneak Peek!

Here’s a peek of what we’ll be doing in this tutorial via an animated GIF:


On the left is a terminal and the Sublime text editor, and on the right is Chrome. Changes to the .scss file are being persisted to disk, which is reflected in Sublime, the Sass watch command is generating a new version of a CSS file when it detects changes to the Sass file, which is in turn picked up by DevTools and reflected onto the page.

The Need for a Better Workflow

So what are we trying to solve here? Why would we want a better workflow? Well, let’s review an example of debugging some Sass-generated CSS, given the following .scss file, which contains:

$myColor: green;

body {
	.box {
		color: $myColor;

And now the CSS, which is generated by the above Sass file, would look like this:

body .box {
  color: green; }

Now we just need a little bit of HTML to apply our styling to:

<div class="box">Hello</div>

Ok, so far so good. Now we want to start designing and developing our page using Chrome DevTools. First we inspect the div with a class of box by right clicking on it and selecting Inspect Element. Then we can check out the styles pane, which shows a green value for the color property, a note on the filename it’s contained within, along with the line number that the selector appears on. Now here’s where the problem lies – the processed CSS does not follow, line for line, what the source .scss file looks like, which can have a negative impact on our development workflow.


In the image above, the left pane shows a source .scss file and the right side shows the processed version. (Note I’m using the SCSS bundle for syntax highlighting in Sublime Text)


DevTools then provides a link to the file and line number of the selector, highlighted in red above, which unsurprisingly links to the processed file (image below). This now acts as a limitation for editing the file within DevTools as we can’t benefit from file saving. For example, if we persist changes to the processed file, they’ll just be overwritten when Sass next runs.

In fact, we don’t even have a clear indication of what the corresponding line number is – of course, practically speaking, our above example is very simple and we can very quickly understand what line maps to what, by looking at the code. However in a larger .scss file, things can get trickier.


As you can see above, DevTools has no understanding of our .scss file, we can address this however by utilizing a DevTools and Sass workflow, which is what we’ll be looking at in this tutorial. To summarize, a lack of Sass support in the DevTools could mean:

  • We don’t immediately know the line number a selector and/or CSS property exists on, within our source file.
  • Persisting our CSS changes to the file system is pretty much out of the question.
  • Even simply viewing the .scss file in the sources panel is difficult as DevTools doesn’t recognize the extension as one which should be viewed.

Preparing for Sass Support


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.

Now let’s navigate to about:flags in the omnibox, then find Enable Developer Tools experiments, enable it and restart Chrome.


The image below shows an experiments panel, you can reach this by clicking on the cogwheel at the bottom right corner of DevTools and clicking ‘Experiments‘, then check the box for Support for Sass.


After closing and opening DevTools, you can now 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.



This tutorial uses the latest version of Sass (3.3.0 at the current time of this writing) as there is some initial support for source maps. Here’s how you can install Sass using Rubygems:

gem install sass --pre

We now need to tell Sass to compile our .scss files, using the following command:

sass --watch --scss --sourcemap styles.scss:styles.css

From above, the styles.scss is your source file and the styles.css is the processed file, which your HTML page would use. Here’s how you would link in the processed .css file:

<link rel="stylesheet" type="text/css" href="styles.css">

If you see something similar to the image below in your terminal:


…and you see a generated .map file, then, congratulations: Sass debugging is working! Here’s what those other command options are doing from the previous compile command:

  • --watch: Will watch for changes to the source .scss file and compile it as soon as it has detected a change.
  • --scss: Will display what style of Sass we are using.
  • --sourcemap: Will generate corresponding source map files.

Now, having an understanding of source maps isn’t critical to follow along, however it’s certainly something worth reading about as it’s intended to help the development process. See below for a few resources on source maps:

From Elements to Sources


Assuming all went well, opening up your page where Sass support is enabled in DevTools should allow for Sass debugging. The first thing to note is that the filename will show the corresponding .scss source file, which is useful, in addition to that, 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: You now have a viewable Sass file right in your browser with syntax highlighting!


Ok, so finding the corresponding CSS selector from the Elements panel is cool, but what about CSS properties?

In the screenshot below, the Sources panel has highlighted the CSS property I was interested in, to get there I had Command-Clicked 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 very powerful!


Note: Navigating to a CSS property in the sources panel from command clicking the property in the Elements panel is not specific to Sass, it can be achieved with regular CSS too.

Sass Editing With Persistent Changes

Editing a Sass file is not much different than editing a regular CSS file, one thing we will need to do however is ensure DevTools knows where the .scss file is located at on the file system. From within the Sources panel, the left hand sidebar should have a Sources pane which displays the .scss file, right click it 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, changes are made pretty quickly and the DevTools are able to show us those changes.

Even mixins work as expected, pasting the following, in an almost empty .scss file within the sources panel results in the correct CSS being generated, which DevTools is able to reload from within a second.

@mixin button {
    border: 2px solid green;
    display: inline-block;
    padding: 10px;
    border-radius: 4px;    

.box {
    @include button;   

As you can see in the image above, the left hand side shows the .scss source file, which is what we would make changes to, the right hand side shows the generated .css file which DevTools has picked up changes from (almost immediately thanks to the watch flag in the terminal)

Sass Debugging at Fluent Conf

Paul Irish gave a great talk at Fluent which had lots of juicy information on the Chrome DevTools, but also the use of Sass. Skip ahead to 5:30 for the Sass information.


Let’s go over some of the main points discussed in this tutorial:

  • Sass capabilities in Chrome DevTools are a great way to view and modify Sass resources, although don’t forget to enable it in both about:flags and in the settings panel.
  • When using Sass and the Chrome DevTools in a project, you’re likely to have a more efficient workflow with viewing/editing the source file, rather than the generated 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 will take you to the relevant portion in the sources panel.
  • Utilize the Sources panel’s editing capabilities by doing a ‘Save as‘ on the .scss file, future saves (Command+S) should overwrite the file.
  • Chrome Canary and the latest version of Sass 3.3.0 (due to Source maps) were used in this tutorial, be sure to try them out!

Interesting links

As you can see, the development workflow with Sass is not perfect, but it’s definitely a lot better than what it used to be. As time goes on, DevTools will provide a more streamlined workflow for editing CSS files and bugs will be fixed! Any issues you do find can be raised as a bug at

Thanks for reading this article!

March 25 2013


Mandatory for Web Developers: Free Video Tutorials on Chrome DevTools by Code School


Are there web developers who have never heard of Chrome DevTools? I don't know of one single example. Chrome DevTools are a developer's friend. Directly implemented into the browser, they deliver tools that are inescapable when it comes to web programming, especially the debugging part of it. Getting started with DevTools is not exactly complicated, but - as always - any help in accomplishing a faster start is greatly appreciated and lowers the inhibition threshold for newcomers. It is exactly such an entrance (and more) that the free video tutorial "Explore and Master Chrome DevTools" offers you.

Older posts are this way If this message doesn't go away, click anywhere on the page to continue loading posts.
Could not load more posts
Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
Just a second, loading more posts...
You've reached the end.
No Soup for you

Don't be the product, buy the product!

YES, I want to SOUP ●UP for ...