Chrome viewport on left, Element Inspector in the middle, editor (Coda) on right. Note the value of background for the html tag, which changes in all three views, across two different applications, without saving or refreshing.
Part of the Web Dev Tools Reading List

The cycle of most front-end web development goes something like this:

  1. Use an editor to write , and .
  2. Test it in a . Find something that breaks.
  3. Go back to the . Try changing something.
  4. Return to the browser. Refresh to see if the problem is fixed.
  5. Repeat until the problem goes away.

This work process is uni-directional: code changes always go from the editor to the browser, never the other way. An improved process was introduced with Firebug almost a decade ago:

  1. Create HTML, CSS and JavaScript in an editor.
  2. Test the result in a browser. Find something that breaks.
  3. Fix the broken code in Developer Tools, viewing the results live in the browser.
  4. Copy the fixed code from Developer Tools back to the editor.

While the second process is substantially better, it still has that aggravating fourth step: changes made in the browser affect only the live page, not the source, and copying code alterations back to your editor can be both confusing and time-consuming.

Ideally, the browser should be an equal partner in web development, able to write any changes made in the Developer Tools back to your HTML, CSS and JavaScript. Browsers aren’t equipped to do that by default… but that’s exactly what Workspaces are for.

Setting up Workspaces in Chrome takes a few steps, but doing so can dramatically accelerate your web development process, particularly in design changes and bugfixes.

Editing HTML and CSS from Chrome

Let’s say you have a basic site contained in a folder. This folder is typically divided into subfolders, which store the various resources of your site:

Screenshot of site organisation
Figure 1: Typical structure of a small-to-medium sized site

For this example, I’ll make a minimal index page: 

<!doctype html>
<html lang="en">
	<head>
		<meta charset="utf-8">
		<link rel="stylesheet" href="css/styles.css">
		<meta name="viewport" content="width=device-width, initial-scale=1">
		<title>DevTools Roundabout</title>
	</head>
	<body>
		<main>
			<h1>DevTools Roundabout</h1>
		</main>
	</body>
</html>

The stylesheet will be equally minimal: 

html { background: #333; }
body {
	margin: 2rem;
	color: rgba(0,0,0,.9);
	font-family: Avenir, Trebuchet, sans-serif;
}
main { 
	padding: 2rem;
	min-height: 82vh;
	background: #fff;
	width: 80%;
	max-width: 1200px;
	margin: 0 auto;
}
h1 {
	font-weight: 200;
	margin-top: 0;
}

In order to save alterations to your code from the browser, Chrome must be given permission to alter these files.

  1. Open a page from the site in Chrome. You can do this directly (via File / Open) or by using a url to a local server hosting the site.
  2. At the same time, open the site’s stylesheet in the editor of your choice, so we can see changes there.
  3. Right / control-click on the page in Chrome and choose Inspect Element
  4. Click on Sources on the Developer Tools menu bar.
    Add Sources in the Developer Tools
    Figure 2: Adding the site folder to a Chrome Workspace
  5. Right-click / ctrl-click in the Sources window on the left-hand side and choose Add Folder to Workspace
  6. In the dialogue that appears, select the folder that contains your website.
  7. Chrome will ask for write permission on the folder: click Accept.

We’ve directed Chrome to the right folder; now we need to match it to the right files. Before we do that, let’s look at the current situation: open Developer Tools in Chrome again, click on the <html> element, move to the Styles panel, click on the color for the background property for the element, and change its value.

Switch back to Sources. Note that the stylesheet has an asterisk next to it, indicating that it has changed, but is not yet saved: the browser view is different, but the change is not yet a permanent part of the site stylesheet. To do that, we need to map Chrome’s understanding of the site’s CSS to the actual file.

  1. Right / control-click on the styles.css file in the Sources panel of the Developer Tools window and choose Map to File System Resource.
  2. The location and filename of the stylesheet should appear in a new window. Click on the name to confirm that this file maps to the stylesheet for the current page.
  3. Chrome will prompt you to restart Developer Tools. Do so: your existing browser state will be preserved, although a new blank tab may pop up; you can close this tab.
  4. Navigate back to your page in Chrome and choose Inspect Element once more. Change the background of the <html> element again in the Styles panel (or change the value of any property for any other element).
  5. Now for the magic: switch back to your editor, and look at the site stylesheet there. The new value will also be in in that document: it’s now a permanent alteration to the file.

This ability can also extend to other files: return to the Developer Tools in Chrome, click on Sources, choose the index.html file, and edit the HTML for the page in the panel to the right; then right-click or control-click in the window and choose Save. The HTML file will be saved and updated from Chrome just as the stylesheet was.

The New Workflow

The power of Workspaces prompts a very important and interesting question: just where do we create our code now? Is it in the editor, or the browser, our build tools, or somewhere in-between?

While it’s possible to create a web site directly in the browser, at least in principle, for right now the process easiest to initiate in an IDE. So from my perspective the web development process is:

  1. Determine a toolset and build process for the site
  2. Create HTML, CSS and JavaScript in your tools of choice.
  3. Check and modify this code in a Chrome Workspace, checking the results in other browsers as needed.
  4. Return to step 2 when adding significant features.

Conclusion

Workspaces are an immensely useful tool, with settings recalled even after quitting Chrome and restarting, meaning you should only have to do this setup once per site. It can even be extended to CSS generated by , working “backwards” any alterations to the styles from Chrome to the originating .scss document. I’ll show that possibility, and much more, in the next article.

Enjoy this piece? I invite you to follow me at twitter.com/dudleystorey to learn more.