Unit 04
The Working Environment
By the end of this unit your work lives in a real editor, on a real branch, in a repository you can hand in — and you can read code you did not write, including code a machine wrote, and say what is wrong with it.
You have built a page. Now you need somewhere to keep it.
Unit 3 handed you a script tag and no tooling, on purpose, so you could build something on day one. That was the right trade then. It stops being the right trade the moment you have work worth not losing — and Top 6 is that work.
This is the unit students usually tolerate. Sequenced this way it is the unit that makes your site real.
Local development
Two things to install: VS Code, which is the editor, and the Live Server extension, which serves your folder over HTTP so you can see it the way a browser sees it.
That second one deserves a paragraph, because skipping it is the most common way a first project goes strange.
Why file:// is not a website
Double-click an HTML file and it opens. It looks like it worked. It mostly did.
But the address bar says file:///Users/you/Desktop/index.html, and that is not
a web address — it is a path on your disk. There is no server, so there is no
request, no response, and no headers. The browser puts every file:// page in
its own isolated bucket, which means a page loaded that way is not allowed to do
several things a real page does. You will meet the difference the first time
something works for you and not for anyone else.
Add this question to
Loading your meetings…
Your page works when you double-click index.html, but a classmate says the images are broken when they open your folder. What is the most likely cause?
A file:// path is a location on one disk. An HTTP path is a location on a site. Working over HTTP from the start means the paths you write are the paths that will still work once it is published.
Version control
Git A record of every version of every file in a project, and who changed what, when, and why. is not a backup. A backup answers “what did this look like yesterday.” Git answers “what changed, when, and why” — and the why is the part that turns out to matter, usually at 11pm, usually to you.
Three verbs do almost everything:
| Verb | Moves work from | To |
|---|---|---|
| commit | Your files, as they are right now | A saved point in your local history |
| push | Your local history | GitHub, where your teacher and your future self can see it |
| pull | GitHub | Your local copy |
The thing worth memorising: a commit is local. Committing does not put your work anywhere else. Students lose work to this exact gap — a laptop dies with forty commits and zero pushes on it. Commit often, push at least once a session.
Writing a commit message
A commit message is a note to whoever reads this history later, which is usually you, three weeks from now, with no memory of any of it.
| Message | What it tells you later |
|---|---|
update | Nothing. There are now eleven commits called update. |
changed index.html | Git already knew that. It tells you the file, not the point. |
Stack the cards below 640px so the text stays readable | What changed and why — enough to decide whether to keep it. |
Write it · text
Checked on submit · retry as often as you like
You changed your hero button from grey to your accent colour, because in testing nobody could tell it was clickable. Write the commit message.
What changed and why. Git already records which files moved and when — the message is for the one thing it cannot see, which is your reasoning.
Handing work in
Assignments come through GitHub Classroom. Your teacher posts a link, you accept it, and GitHub makes you your own private copy of the starter repository. It is yours: commit to it as much as you like, and whatever is pushed when the deadline passes is what gets read.
There is no “submit” button. Pushed is submitted. That is the whole system, and it is the same one used by every team you will ever join.
Add this question to
Loading your meetings…
It is 11:50pm. You have committed all your work and closed your laptop. Is the assignment in?
Save, commit, push. Three steps, and only the third one leaves your laptop.
Working with other people’s code
Your ThemeStarter is not a blank page. It is a working site, written by someone else, that you are going to change without breaking.
That is a real skill and it has a method: change one thing, look, repeat. The instinct is to open the file and start rewriting. Resist it. A template you have made twelve changes to, three of which broke something, is much harder to recover than a template you changed once.
Write it · html
Renders as you type · nothing leaves your browser
A working section. Change the words, keep the structure.
index.html
Tab indents. Press Esc first to tab out of the box.
Result
- The headline is yours
- The supporting line is yours
- The button says what it does
- The hero structure survived
- Still exactly one primary action
Notice which goals are about your content and which are about the structure. Replacing the words is the assignment. Deleting hero-content because it looked unnecessary is the mistake this exercise is built to catch — the last two goals go out the moment you do.
Working with code a machine wrote
You are going to use AI to write markup. So is everyone you will ever work with. The skill is not avoiding it — the skill is being the person in the room who can tell when it is wrong.
Generated markup is usually plausible. It has the right shape, it uses real class names, and it often does exactly what you literally asked. The failures are specific and they repeat:
| Failure | How to catch it |
|---|---|
div where a landmark belongs | Ask what each block IS. A nav made of divs is a nav that assistive technology cannot find. |
A clickable div | Try to reach it with Tab. If you cannot, it is not a button. |
| Invented class names | Search the docs for it. btn-huge looks right and does nothing. |
| Headings chosen for size | Read the headings alone, in order. Do they outline the page? |
| Answers a question you did not ask | Reread your own prompt. It solved something adjacent. |
Add this question to
Loading your meetings…
You asked for a navigation bar. You got: <div class="navbar"><div class="nav-item" onclick="go('/about')">About</div></div>. It looks right in the browser. What is actually wrong?
Two failures at once, and both are invisible if you only ever check with a mouse and your eyes: no landmark for assistive technology, and no keyboard access at all. This is exactly why WD4.4.A asks you to evaluate generated code against the requirement rather than against the screenshot.
Write it · html
Renders as you type · nothing leaves your browser
Repair it. Same look, real markup.
index.html
Tab indents. Press Esc first to tab out of the box.
Result
- It is a real nav landmark
- The links are links
- Nothing is left clickable-but-unreachable
- The invented class is gone
- The call to action still stands out
You did not lose anything by fixing it — it still looks the same. That is the usual outcome, and it is why 'it renders fine' is never the test.
Say what you used
Getting help
Two tools and one skill.
Live Share lets someone else’s cursor into your editor. It is the fastest way to get unstuck when the person helping you is nearby.
A good bug report is what you need when they are not. Someone who cannot see your screen can still help you, but only if you give them three things:
- What you did. The specific action, not “I was working on it.”
- What you expected. This is the one people leave out, and it is often where the misunderstanding actually is.
- What happened instead. Including the exact error text, copied, not paraphrased.
Submit for review · text
Read by a human · you can resubmit
Describe a bug you have actually hit in this course — from Unit 3, from your Hot Take, from setting up your editor — so that someone who cannot see your screen could help. Three parts: what you did, what you expected, what happened.
What earns points5 pts
- 2 States the specific action taken
- 2 States what they expected to happen
- 1 States what actually happened, concretely
Half of all debugging is one person explaining the problem accurately to another. Sometimes the other person is not even needed by the end of the sentence.
That is the unit: an editor and a real server (WD4.1); commits, pushes, and
messages worth reading (WD4.2); other people’s code, changed carefully
(WD4.3); generated code, checked rather than trusted (WD4.4); and asking for
help in a way that can be answered (WD4.5).
Unit 5 is where the site stops looking like a template and starts looking like yours — type, colour, and images you chose and can defend.
Where you are
Not startedAnswer the checks above whenever you like. They're not graded, and you can retry any of them.
Kept in this browser only, unless you sign in.
Signing in carries this — and everything else you've done here — onto any device, and keeps it if you clear this browser.
Intro to Web Design · members' unit
The Working Environment is behind a locked door
Units in Intro to Web Design are for people taking the course. Getting in takes a link or a key — signing in on its own doesn't do it.
What's in this unit · 9 min read
- Local development
- Version control
- Working with other people’s code
- Working with code a machine wrote
- Getting help
3 quick checkslive HTML/CSS sandboxcode exercises
1 Sign in
With your school Google account. This is how your work reaches the gradebook — it doesn't open the unit by itself.
A key unlocks this browser and keeps your progress here; signing in keeps it with you across devices. Either way the key itself is only ever checked as a hash. Manage all of this on your account, read what signing in stores, or go back to Intro to Web Design.
Sources
- Gilmour Academy — Intro to Web Design