The workbench: editor, preview and checks

A web developer’s workbench is a file editor, a preview where the browser draws the page, and checks. The browser’s developer tools (F12) show the page’s tree.

Three windows

The practice is laid out the same way in every lesson, and the three windows you’ll see are all you need:

1. The editor. A text field where you write and edit a file. It colors the code to make it easier to read, but otherwise it’s plain text.
2. The preview. Next to it you see how the browser draws your file. A fraction of a second after you stop typing, it updates by itself.
3. The checks. Below the preview is a list of what the task is looking for: “there is a heading”, “it holds your project’s title” and so on. What has worked is checked.

A webmaster works the same way: write, look, adjust. The difference is that here a helper sits next to you and tells you at once what is already in place.

If you get tangled up, there’s a “Reset” button under the editor (it brings back the original text) and a “Show the solution” button (with a confirmation, so you don’t press it by accident). The solution is shown as a difference from your file: you see what to add and what to remove.

Check yourself: what is the working loop in the practice?

You edit the file, the preview updates, the checks read the page, and you see which of them haven’t passed yet.

Files

A site is made of files. While it’s simple, there’s one file: index.html, the page. When styles and scripts join the lessons, two more appear: styles.css for the look and script.js for the behavior. In the editor they will be tabs. The name index.html is no accident: it’s what the main page of any site is called by default.

Your work saves itself, in the browser. Close the tab and come back tomorrow: everything will be there. Each era of the course keeps its own version of the site separately.

Checks read the page, not the letters

The checks don’t compare your text with a model answer. They look at the finished page as the browser built it: is there a heading, what does it say, what color is a block. So the same task can be solved in different ways, and the checks will accept them.

The checks also know your project. If you entered your own title in settings, the task will ask for exactly that. A check doesn’t quarrel with your words: it needs them to be there.

The sandbox

The code you write runs in a “sandbox”: an isolated box. You see the page in its window, but it can’t send anything to the internet and can’t see anything except itself. This isn’t distrust of you. It’s a habit of the web: any code that didn’t come from you is run under restrictions, and code you wrote yourself or copied from a forum can be wrong too. So you can experiment without fear.

Developer tools

Every browser has a built-in toolkit for people who make websites, and yours has it too: there’s nothing to install. You can open it with the F12 key, with Ctrl+Shift+I (Cmd+Option+I on a Mac), or by right-clicking the page and choosing “Inspect”.

Three tabs will be useful first:

• Elements. The page’s tree: which elements it’s made of, and which styles apply to them. If you click an element in the tree, it lights up on the page. And the other way round: you can point at the page and find the element that matches.
• Console. The browser writes the page’s messages and errors here. While the site is simple it’s empty, and that’s a good thing.
• Network. A list of the requests the page made: what was downloaded, how big it was, how long it took. It will be useful in the next part, when we look at how a page travels across the network.

One important property: in the tools you can change the page. Double-click some text in the tree and rewrite it, and the page changes. But you only change your own copy, in your own browser. Reload the page and everything comes back. It’s safe to try: you can’t break anything.

Try it on the diagram: press a line, an element or a tree node, then “forget” the closing tag and see what happens.

Forget the closing tag </h1> Press a line, an element or a node of the tree: it lights up in all three.

File

1. <!doctype html>
2. <html lang="en">
3. <body>
4. <h1>Your project</h1>
5. <p>Who you are and what you do</p>
6. </body>
7. </html>

Preview

Your project Who you are and what you do

Element tree

• html lang="en"
• body
• h1
• p

• ✓ The page has one h1: passed
• ✓ The heading’s text matches the project’s title: passed
• ✓ There is a paragraph with the description, separate from the heading: passed

Check yourself: does an edit in the developer tools change someone else’s site?

No. You only change your own copy in your own browser, and after you reload the page everything comes back.

A short introduction to markup

For the first practice you need exactly one idea. A page is text in which marks show what is important. A mark is written in angle brackets and is called a tag. A top-level heading is wrapped in <h1> and </h1>, and a paragraph in <p> and </p>. The slash in the closing tag says: the element has ended.

<h1>Project title</h1>
<p>One sentence about who you are.</p>

That is everything in these two lines: an opening tag, the text, a closing tag. There’s more in part 2. For now you only need to feel how text becomes a page.

Practice

Below is your first page. It already holds your project’s title and the description from your brief, but as plain text. Mark them up, and the checks will light up. Then open the developer tools, find your heading in the tree and click it.

A hint: the page lives inside the preview window. In the tree, expand the iframe element and, below it, body.