The cycle of most front-end web development goes something like this:
- Use an editor to write HTML, CSS and JavaScript.
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:
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:
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.
- Click on Sources on the Developer Tools menu bar.
Figure 2: Adding the site folder to a Chrome Workspace
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.
- Navigate back to your page in Chrome and choose Inspect Element once more. Change the
backgroundof the<html>element again in the Styles panel (or change the value of any property for any other element).
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:
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 Sass, 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.
Pro CSS3 Animation, Apress, 2013
Massive Head Canon
The New Defaults
CSSslidy