Unit 08
Ship
By the end of this unit your stylesheet is built for real instead of loaded from a CDN, your site lives at a public address you can hand someone, and you can say exactly what it costs the person who opens it — in bytes, and in what it tells about them.
Every project so far has loaded Tailwind from a CDN — three script tags, no
build, working the moment you opened index.html. Unit 3 told you the honest
version of that trade: Tailwind’s own documentation calls the browser build
“designed for development purposes only, and is not intended for
production.” This is the unit where that finally has to be true.
Inspect and override
A real build
The CDN tag ships the entire Tailwind engine to every visitor and generates your classes in their browser, live, every load. A build does the same work once, on your machine, and ships only the CSS your page actually uses — smaller, faster, and the thing every real Tailwind project actually runs.
The standalone CLI from Unit 4 is the whole tool: one executable, no Node, no package manager.
./tailwindcss -i input.css -o style.css --watchinput.css is where you write real CSS — including your Unit 5 palette
block. style.css is what --watch regenerates every time you save,
containing only the utilities your markup actually calls for. Swap the CDN
<script> tag for a plain <link rel="stylesheet" href="style.css">, and
your page is running on a file, not a request to someone else’s server.
Finding the rule
Every style on screen came from a rule, and dev tools will tell you which one. Right-click anything, Inspect, and the Styles panel lists every rule touching that element — in the order the cascade actually applied them, struck through wherever something later won.
Add this question to
Loading your meetings…
A button is the wrong shade of blue and you don't know why. What's the fastest way to find out?
Dev tools show you the cascade as the browser actually resolved it — which rule is winning, and which ones lost. That is almost always faster than guessing.
Changing a template without breaking it
Unit 4 taught you the method: change one thing, look, repeat. Here it is again, on your Studio project’s real template, for real content.
Write it · html
Renders as you type · nothing leaves your browser
Your content, the template's structure.
index.html
Tab indents. Press Esc first to tab out of the box.
Result
- The headline is yours, not the template's
- The intro line is yours
- The hero structure survived intact
Same lesson as Unit 4, on the project that actually ships this time: replacing the words is the assignment, and the last goal is what catches the shortcut of deleting hero-content because it looked unnecessary.
Overriding by specificity, not by force
!important wins every fight by breaking the rules of the fight. It is a
last resort, and using it as a first one means the next override has to be
!important too, and the one after that — an arms race with no ceiling.
| Approach | What it costs later |
|---|---|
| A more specific selector | Nothing — the cascade still works the way you learned it. |
!important | The next person who needs to override THIS rule has only one tool left, and it is the same one. |
Add this question to
Loading your meetings…
Your theme's stylesheet sets .btn-primary { background: var(--color-primary); }. You need one specific button, inside .hero, to be a different colour. What's the right move?
Specificity is the cascade's own mechanism for 'this rule should win here.' Reach for a more specific selector before reaching for a rule that wins by breaking the mechanism.
A new class, and a new id
Write it · html
Renders as you type · nothing leaves your browser
Add both — and use both.
Tab indents. Press Esc first to tab out of the box.
Result
- A new class is declared in the stylesheet
- That class is used in the markup
- A new id is declared in the stylesheet
- That id is used in the markup
Both directions have to be true — declared in the CSS AND present in the HTML — or it's dead code on one side or the other. This is the smallest possible version of extending someone else's template rather than rewriting it.
One file, organised
A stylesheet that started as a fragment in Unit 5 is now the whole visual language of a real, published site. It earns real organisation: commented section headers, and the palette block at the very top where anyone opening the file sees it first.
/* PALETTE — "late shift"
* primary #E8624A
* base-100 #1A1714
*/
/* ===== RESET & BASE ===== */
/* ===== LAYOUT ===== */
/* ===== COMPONENTS ===== */
/* ===== UTILITIES OVERRIDES ===== */Add this question to
Loading your meetings…
Your stylesheet is 400 lines with no structure. A teammate asks where the navbar's mobile breakpoint is handled. What does an unorganised file cost you here that a sectioned one wouldn't?
Organisation doesn't change what a stylesheet does. It changes how fast a person — including future you — can find the part they need to change.
Adding to a site
A real project needs new sections after the template stops being blank. Two things have to move together: the navbar link, and the anchor it points to.
Write it · html
Renders as you type · nothing leaves your browser
A link that actually arrives.
index.html
Tab indents. Press Esc first to tab out of the box.
Result
- A new nav link points at the new section
- The new section exists with that id
- Scrolling to it is smooth, not a jump cut
Add a Hours section with id='hours' and a matching navbar link with href='#hours'. scroll-smooth is one class, on the html or body element, and it's the whole difference between a jump cut and a scroll a reader can follow.
Deploy
Everything so far lived at a file:// path or a preview only you could see.
This is where it gets a real address.
We publish through Netlify — the same host this course itself runs on.
Netlify Drop takes a dragged folder straight to a public URL, no account
needed for a first publish: drag your project’s folder onto
app.netlify.com/drop, and it’s live.
| Route | How you redeploy |
|---|---|
| Netlify Drop | Drag the folder again. Each drop is a new deploy, same URL. |
| A linked GitHub repo | Push. Netlify rebuilds and redeploys automatically — the exact workflow Unit 4 already taught you. |
The address Netlify generates first is random. WD8.3.B asks for a
meaningful one — change the site name in Netlify’s settings, and your
address becomes something you’d actually hand someone, not a string of
words you didn’t pick.
Add this question to
Loading your meetings…
You fixed a typo in your hero headline and pushed to GitHub. Your Netlify site is linked to that repo. How do you confirm the live page actually changed?
A push starts a deploy. It doesn't confirm one. The only real confirmation is opening the public address and checking that what changed is actually there.
Evaluate the shipped thing
You already have the instrument for this — the requirements checklist in
your Top 6 starter’s own README, from Unit 3. WD8.4.A is that same habit,
run against the site that’s actually live now instead of the one still open
in your editor.
Submit for review · text
Read by a human · you can resubmit
Open your live, published site — the real public URL, not a preview. Go through your requirements checklist and report each item pass or fail, with evidence: what you saw, not what you intended.
What earns points5 pts
- 1 Genuinely audits the live public URL, not the editor
- 2 Goes through the requirements list item by item
- 2 Each verdict has real evidence, not just pass/fail
A checklist against your own memory of the project tells you what you meant to build. A checklist against the live URL tells you what you actually shipped, and those two are not always the same page.
What a page costs its reader
Every third-party request your page makes tells that third party something — an IP address, a referrer, the fact that this specific reader opened this specific page, at this specific time.
Add this question to
Loading your meetings…
Your page loads a font from Google Fonts, an embedded YouTube video, and an analytics script. Where would you find the full, honest list of everyone your page actually contacts?
The Network tab is a record of reality, not of what you intended to load. It's the same instrument from WD6.5's audit, pointed at a different question.
Submit for review · text
Read by a human · you can resubmit
Open your live site's Network tab. List every third party it contacts and, for each, what that party learns about the reader. Then find your single largest asset by file size and describe one real change that would shrink it — and why that change doesn't cost the page anything it needs.
What earns points5 pts
- 2 Lists the real third parties from the Network tab, not a guess
- 1 Says specifically what each one learns, not just that it was contacted
- 2 Names the actual largest asset and a real fix for it
WD5.3's lesson about image weight was about load time. WD8.5 is the same measurement, for a different reason: every byte and every request is something you decided to ask your reader to pay, sight unseen.
That is the unit: a real build instead of a CDN, and the cascade tools to
work inside it (WD8.1); new sections that arrive the way the rest of the
site does (WD8.2); a public address, confirmed to actually update
(WD8.3); your own checklist, run against the live thing (WD8.4); and an
honest account of what a page costs the person who opens it (WD8.5).
That’s Intro to Web Design. You started this course finding out what a URL even is. You are ending it having shipped one — with a team, a real environment, and a habit of checking your own work against something more solid than a feeling.
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
Ship 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 · 8 min read
- Inspect and override
- Adding to a site
- Deploy
- Evaluate the shipped thing
- What a page costs its reader
5 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
- Tailwind Labs — Tailwind CSS CLI