The last CSS class asks the biggest question
Your site looks perfect on the projector. Now take out your phone.
Class 11 gave you X-ray vision — every element is a box, and you can compute its true width to the pixel. But every width you have written so far — width: 300px, width: 480px — was measured against one screen: the lab monitor. India browses on phones. A 360px screen does not negotiate with your 480px form. Today CSS learns to listen to the screen it is on — with media queries, the viewport meta tag, and the mobile-first habit. This is the final classroom session of Unit 1's CSS track: after today, Lab 3 is pure surgery.
Walk out of this room able to…
Every responsive demo in this session is a live width simulation running right on this slide — you will drag windows narrower and press device buttons instead of downloading anything. To practise on your own machine, make a fresh throwaway folder fswd-practice\Class-12\, open it in VS Code, and type tiny scratch .html/.css files from nothing — build them, shrink the window, throw them away. Nothing here is committed: fswd-practice\ is scratch paper, never a git repo. The real, continuous poshtik-campus\ project — and all its commits — lives only in the lab classes. Never in a regular class.
The picture that explains everything
A fixed-width page doesn't shrink. It gets amputated.
Here is a quick scratch page — three dish cards typed into fswd-practice\Class-12\menu.html, each a proud 172px wide, sitting in a row that adds up to about 560px. On the lab monitor: perfect. Now watch what happens as the window narrows past what the content demands. The cards do not politely stack. The text does not reflow. The page simply keeps its width and lets the window cut it off — and a horizontal scrollbar is born, the universal symbol of a site that never met a phone.
Say the definition: responsive design means one HTML page whose CSS adapts its layout to the width of the screen it is on — cards that share a row on a laptop choose to stack on a phone. Not a separate mobile site, not a zoomed-out miniature: the same file, listening. The listening device is a CSS rule called a media query — and you already met its cousin: Class 11's @media print listened for paper; today's queries listen for width.
The early web did exactly that — a second site at m.example.com with its own HTML. It failed for a reason you can now name: two copies of every page means every menu change is made twice, forgotten once, and wrong somewhere forever. Responsive design won because it keeps one source of truth and moves all the adaptation into CSS — the same separation-of-concerns argument that moved you from inline styles to style.css in Class 10.
Real numbers, so this isn't hand-waving: the most common phone viewport widths in India are 360px and 393px; your lab monitors are 1366–1920px wide. A layout that assumes even 500px of guaranteed width is broken for most of your actual users.
The one-line fix every student forgets
Before CSS can listen to the phone, HTML must stop lying to it.
Here is a trap with history. Phones arrived in 2007 to a web built for monitors — so phone browsers lied in self-defence: they pretend to be ~980px wide, render the desktop layout onto that imaginary canvas, then photograph it and shrink the photo to fit the glass. Result: your whole page "fits", but as an unreadable miniature. One line in <head> tells the browser: stop pretending — use your real width. Without it, every media query you write today is measuring the imaginary 980px canvas and will simply never fire.
<head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>Campus Café</title> <link rel="stylesheet" href="style.css"></head>width=device-width — "your layout canvas is the real glass, not the imaginary 980px monitor." A 360px phone now reports 360px — and your media queries can finally hear it.
initial-scale=1.0 — "start at 100% zoom, no shrink-to-fit photography." The user can still pinch-zoom; you're setting the opening state, not forbidding zoom.
HARD RULE FROM TODAY: this line goes in the <head> of EVERY HTML file you create, before you write a single CSS rule. No exceptions, ever.
Same page, same phone — the only difference is line 3.
Campus Café — Today's Healthy Ten
The phone renders a pretend 980px monitor, then shrinks the photograph. Every word is ant-sized; the customer pinch-zooms, sighs, and orders elsewhere.
Campus Café
The classic exam-lab disaster, pre-told: a student writes a perfect media query, opens the page on a phone, sees no change, and concludes "media queries don't work." The query was fine. The viewport line was missing, so the phone was still measuring its imaginary 980px canvas — wider than the breakpoint, query never fires. Symptom: tiny page + working desktop CSS = missing viewport meta. Diagnose it in one look, forever.
The listening rule
@media — a CSS if-statement whose condition is the screen.
A media query is a wrapper you place around ordinary CSS rules. The rules inside apply only while the condition is true — and the browser re-checks the condition live, every time the window changes. Two vocabulary words carry the whole part: max-width: 600px means "at 600px or narrower" (phones); min-width: 601px means "at 601px or wider" (laptops). The number where behaviour changes has a name you'll use for the rest of the course: the breakpoint.
<!DOCTYPE html><html lang="en"><head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1"> <!-- queries need this on real phones --> <title>Media play</title></head><body> <h1>Campus Café</h1> <article class="dish">Ragi Idli Bowl — Rs. 50</article> <!-- the card the query resizes --> <article class="dish">Pesarattu — Rs. 45</article></body></html>/* HTML is complete & PLAIN above — two stacked, unstyled cards. Now the CSS ↓ */ <style> /* typed back up in the <head> */ .dish /* ordinary rule — true on EVERY screen */ { background-color: mintcream; border: 2px solid seagreen; padding: 9px; width: 300px; /* a fixed width — remember this number */ } @media (max-width: 600px) /* condition: 600px or NARROWER */ { .dish { width: 100%; /* full-width — cards stack */ } } /* ← the query's OWN closing brace — count them: 2 open, 2 close */ </style>Campus Café — Today's Healthy Ten
Window is WIDER than 600px → the @media condition is FALSE → only the ordinary rule (lines 8–12) applies. Cards share the row.
Three traps, named now so they never bite: ① the double close-brace — the query wraps whole rules, so every @media block ends with two } in a row; miss one and every rule below it silently dies. ② No semicolon after the condition — @media (max-width: 600px); kills the block. ③ Order matters — the query only overrides; anything you don't restate inside it (the mintcream background, the seagreen border) carries through unchanged from the ordinary rules above.
Slow-motion — what the phone query actually changes, one rule at a time. The device toggle above flips ALL the query's rules at once (that's what a real phone does). Here we open the same block up and add its rules one press at a time, so you can see each responsive change on its own: first the row turns into a column, then the cards stretch full-width, then the heading calms down. Plain layout first — then each rule, in sync.
/* the row of two cards is already on screen (laptop layout) */.row { flex-direction: column; } /* cards stack */.dish { width: 100%; } /* stretch to fill */h1 { font-size: 18px; } /* calm the heading */Today's Healthy Ten
Before any press: the laptop layout (row of two cards, big heading). Each press applies one line from inside the query. Press Back to un-apply them — exactly what happens when a phone rotates back to wide.
Nowhere sacred. A breakpoint is your decision about where your content stops looking good — not a constant of nature. The industry clusters around ~600px (phone/tablet) and ~992–1024px (tablet/laptop) because content commonly cracks there, but the professional habit is the one Activity 3 teaches: shrink your own site until it breaks, and put the breakpoint where it broke.
You can also combine conditions: @media (min-width: 601px) and (max-width: 991px) targets only the tablet band — exactly what the second PYQ today requires.
Solved PYQ · straight from the papers
Four marks, two halves: what media queries do + the selector families.
This question pairs today's headline idea with a Class 9 flashback — the examiner loves stitching units together. The media-query half you can now answer from experience: you just watched one fire live in Part 4. The selector half is revision: you've been using element, class and id selectors since Class 9; here you only have to name them. Take it one point per press.
asked verbatim!What is the role of media queries in responsive web design? List the different types of CSS selectors with an example for each. [4M]
Model answer — media queries first, then the selector families :
@media (max-width: 600px) { … }. The browser re-evaluates it live as the window resizes.✓ 1mp { color: darkslategray; } · class selector targets a reusable label with a dot: .dish { border: 2px solid seagreen; }.✓ 1m#daily-special { background: mintcream; } · universal selector targets everything: * { box-sizing: border-box; } · group selector shares one rule across many: h1, h2 { font-family: Georgia; }.✓ 1m@media block you write selectors. The query chooses when rules apply; the selector chooses what they apply to. Say that sentence in the exam and the marker knows you actually build pages.Memory anchor for the selector list: your own style.css already uses four of the five — body (element), .dish (class), h1, h2 (group) from Class 10, and * (universal) from Class 11's border-box line. The only one you haven't shipped yet is the id selector — and Class 9's #daily-special demo covered it. Nothing to memorise; just remember what you built.
Catch a professional site shapeshifting — with the browser as your ruler.
Every food-delivery site you've ever ordered from is running media queries right now. Your mission: catch one mid-transformation. You'll shrink a real site slowly and note the exact pixel widths where the layout snaps — nav collapsing into a ☰ hamburger, a dish grid dropping from 4 columns to 2 to 1. Those snap-points are the site's breakpoints, and DevTools will read you the width live.
F12, then drag the window's edge slowly narrower. Watch DevTools' top-right corner: it shows the live width × height readout as you drag.- Start full-width. Note how many columns the dish/restaurant grid shows and what the nav looks like.
- Drag slowly narrower. The instant anything snaps — nav becomes a ☰, columns drop, a sidebar vanishes — freeze and write the width from the readout.
- Keep going to ~360px. Collect every snap you can find.
- For one snap, hunt the culprit: in DevTools' Elements → Styles panel, find a rule whose header says
@media (max-width: …).
@media condition you found in the Styles panel, copied exactly.Hunt honestly first. Reading a production site's breakpoints is how professionals steal layout wisdom, legally.
| WIDTH BAND | WHAT THE SITE DOES | THE QUERY BEHIND IT |
|---|---|---|
| ≈1200px+ | Full nav bar in words · dish grid 4 columns · sidebar filters visible | the default rules — no query needed |
| ≈992px | Grid drops to 3 columns; padding tightens | @media (max-width: 992px) |
| ≈768px | Nav words collapse into the ☰ hamburger; sidebar becomes a button | @media (max-width: 768px) |
| ≈600px and under | Grid goes single-column; buttons grow to thumb size | @media (max-width: 600px) |
The professional takeaways: ① breakpoints arrive in a ladder, not alone — big sites usually carry three or four, each handling one band of screens. ② Everything you caught was CSS-only: the page never reloaded, because the browser re-evaluates queries live on every resize — the same behaviour you watched in Part 4's widget. ③ The exact numbers differ per site (992 here, 1024 there) — which proves Part 4's point: breakpoints are chosen where the content cracks, not copied from a holy list.
Solved PYQ · straight from the papers
Four marks, four screens: one page that redecorates itself per device.
This is the writing counterpart of Q16a: the examiner hands you four screen-size bands and wants a page whose background changes in each. It looks long, but it's one pattern stamped four times — write the first @media block correctly and the other three are copy-edit work. Model answer first, one point per press; then the whole file, typed and run.
asked verbatim!Demonstrate responsive web design using media queries: write CSS so the page background changes across four different screen-size ranges. [4M]
Model answer — the plan before the code :
<head> — without <meta name="viewport" content="width=device-width, initial-scale=1.0"> a phone measures a pretend 980px canvas and no width query ever fires on it.✓ 1mbody { background-color: … } — the middle bands need two conditions joined with and: @media (min-width: 601px) and (max-width: 991px) { … }.✓ 1mNow run the answer. The panel types the exact file; the preview beside it is live — press the four device buttons and watch the same page change coat. Each band wears a pale named colour so the change is unmissable on paper AND on screen.
<!DOCTYPE html><html lang="en"><head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1"> <title>Four screens</title></head><body> <h1>One page. Four coats.</h1> <!-- the body behind it changes colour --> <p>The width decides which coat it wears — live, on every resize.</p></body></html>/* HTML is complete & PLAIN above — black Times on white, no colour at all. Now the CSS ↓ */ <style> /* typed back up in the <head> */ body /* default — also the fallback if no band matches */ { font-family: Georgia, serif; } @media (max-width: 600px) /* band 1 · phones */ { body { background-color: lavender; } } @media (min-width: 601px) and (max-width: 991px) /* band 2 · tablets */ { body { background-color: lightyellow; } } @media (min-width: 992px) and (max-width: 1199px) /* band 3 · laptops */ { body { background-color: lightgreen; } } @media (min-width: 1200px) /* band 4 · large screens */ { body { background-color: lightblue; } } </style>One page. Four coats.
The width decides which coat it wears — live, on every resize.
PLAIN HTML — NO <style> EXISTS YET, SO NO COAT AT ANY WIDTHC:\Users\student\Desktop\fswd-practice\class-12\four-screens.html — skeleton + viewport meta + the style block aboveTwo dialects, one professional default
Which screen do your NORMAL rules describe? That choice has a name.
Everything today so far was desktop-first: the ordinary rules described the big screen, and max-width queries patched things smaller. Flip the strategy and you get mobile-first: the ordinary rules describe the phone, and min-width queries add complexity as the screen grows. Same tools, opposite direction — and the industry has largely picked a winner.
Why mobile-first won: ① most visitors are the default — in India, the phone IS the common case, so the unqueried rules should serve it; ② simple-to-complex is safer — starting minimal and adding is less error-prone than building ornate and demolishing; ③ old or cheap phones win too — a device that fails to run your queries still gets the phone layout, which is exactly right. A site that already exists on desktop goes desktop-first out of retrofit reality; your next fresh project starts mobile-first.
Open any stylesheet and count: mostly max-width queries → desktop-first; mostly min-width → mobile-first. Try it on the site you hunted in Activity 1. Bootstrap, Tailwind and every modern CSS framework are min-width machines — knowing this now means Unit 2's framework classes will feel familiar instead of arbitrary.
Write ONE @media rule from a written spec — then meet it at three widths.
Time to write your first media query with your own hands. You get a spec, exactly the way a designer would hand it to you — three sentences, no code. Turn it into one @media block. The solution then shows the same file at three widths side by side, so you can check all three behaviours in one glance.
- Start from the given base:
.row { display: flex; gap: 12px; }·.dish { width: 300px; }·h1 { font-size: 28px; }— type these first, unqueried. - Add exactly ONE
@mediablock implementing the whole spec — both the stacking and the heading change live inside it. - The stack:
.row { flex-direction: column; }plus.dish { width: 100%; }. - Viewport meta line in
<head>— the hard rule. Its absence is the #1 reason "my query doesn't work on my phone". - Test by dragging the window past 600px, both directions, watching both changes land together.
C:\Users\student\Desktop\fswd-practice\class-12\stack-at-600.html — one file, style block in the headposhtik-campus\ project is touched only in the labs.Write and test yours first. The spec-to-code translation IS the skill — reading a solution translates nothing.
<!DOCTYPE html><html lang="en"><head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1"> <title>Stack at 600</title></head><body> <h1>Today's Healthy Ten</h1> <div class="row"> <!-- the flex row that must stack --> <article class="dish">Ragi Idli Bowl — Rs. 50</article> <article class="dish">Pesarattu — Rs. 45</article> </div></body></html>/* HTML is complete & PLAIN above — a heading and two bare stacked blocks. Now the CSS ↓ */ <style> /* typed back up in the <head> */ .dish { background-color: mintcream; border: 2px solid seagreen; padding: 10px; } .row { display: flex; gap: 12px; } /* side by side */ .dish { width: 300px; } h1 { font-size: 28px; } @media (max-width: 600px) /* the spec's own number */ { .row { flex-direction: column; } /* the stack */ .dish { width: 100%; } /* full-width cards */ h1 { font-size: 20px; } /* the calm-down */ } /* remember: the query's own brace */ </style>Today's Healthy Ten
Two separate @media blocks? Works, but the spec said one rule — grouping every change for one breakpoint into one block is the professional habit; scattered duplicates of the same condition are how stylesheets rot.
Forgot .dish { width: 100% }? The cards stack but stay 300px wide — a stack of stubby cards with dead space beside them. Stacking and stretching are two separate decisions.
Page below the query went unstyled? You closed one brace, not two. After the last inner rule on line 16, the query needs its OWN closer — line 17.
The same file, photographed at three widths. This side-by-side habit — checking every width band before calling anything done — is how responsive work is reviewed professionally.
Today's Healthy Ten
Today's Healthy Ten
Today's Healthy Ten
A scratch page, made phone-ready
A scratch style.css earns its first @media block — one query, three targets.
Now put it together on a throwaway page. In fswd-practice\Class-12\ we append one desktop-first media query to the bottom of a small style.css you typed today — stacking the dish cards, letting a wide 480px form breathe, and calming the heading. Watch it land line by line, then see the same menu page at two widths. This is scratch practice — nothing is committed today.
<!-- FILE 1 of 2 · menu.html — the plain HTML the stylesheet will dress --><!DOCTYPE html><html lang="en"><head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1"> <title>Menu</title> <link rel="stylesheet" href="style.css"> <!-- the sheet we are about to grow --></head><body> <h1>Today's Healthy Ten</h1> <article class="dish">Ragi Idli Bowl — Rs. 50</article> <article class="dish">Pesarattu — Rs. 45</article></body></html>/* HTML is complete & PLAIN. FILE 2 of 2 · style.css — the base rules first ↓ */.dish { background-color: mintcream; border: 2px solid seagreen; padding: 10px; }.dish { width: 300px; } /* the desktop width the query will override */h1 { font-size: 34px; } /* the billboard heading */ text-decoration: none; /* … the other plain rules you typed, untouched … */} /* ← end of the scratch sheet — the @media block APPENDS below *//* ===== Class 12 · phone layout — your first media query ===== */@media (max-width: 600px){ .dish { width: 100%; /* was 300px — now the full glass */ } form { width: 100%; /* was 480px — wider than many phones! */ } h1 { font-size: 22px; /* headline, not billboard */ }}Today's Healthy Ten
Today's Healthy Ten
C:\Users\student\fswd-practice\Class-12\ — a throwaway folder, never a git repostyle.css — the block is appended at the bottom; nothing above it changesposhtik-campus\ project (and every commit) belongs only to the lab classes. In a regular class you build, shrink, and throw away.Check first — the viewport line. Open your scratch HTML file and confirm <meta name="viewport" …> is in the head (it has been in every skeleton since Class 5 — but verify, don't assume). If it's missing, today's query will work when you resize the desktop browser and silently fail on an actual phone — the Part 3 disaster.
Turn Activity 1's hunt on your scratch page: where does it still crack?
You hunted Swiggy's breakpoints; now hunt the page you just typed. With Part 10's query in place, shrink your scratch menu.html from full width down to 320px and log every remaining crack — text touching edges, anything forcing a sideways scroll, tap targets too small for a thumb. This audit is not busywork: the checklist you learn to make here is exactly what you'll run on the real site in Lab 3.
fswd-practice\Class-12\menu.html in Chrome. Press F12, then toggle device toolbar (Ctrl+Shift+M, the phone-and-tablet icon) — now you can type exact widths instead of dragging.- Test your scratch page at exactly 1366, 768, 600, 393 and 320 — write a one-line verdict per width.
- At each width ask three questions: any sideways scrollbar? any text or control touching the screen edge? anything too small to tap with a thumb?
- Confirm Part 10's fix: at 360px the dish cards must be full-width and the form must fit. If not — is the viewport line present? is the query's second brace there?
- Log every remaining crack as one line: width · symptom. Aim for at least three finds.
Audit honestly first — your own list is the one that earns Lab 3 marks, not this reference one.
| WHERE | THE CRACK | THE LAB-3 FIX (PREVIEW — DON'T DO IT TODAY) |
|---|---|---|
| every page · ≤600px | Nav links crowd into a cramped line; tap targets under thumb size | bigger padding on nav a inside the query — or the ☰ pattern, later |
| menu.html · 320px | Dish text touches the glass edge — cards are 100% wide with no side gutters | body { padding: 0 12px; } inside the query |
| index.html · ≤393px | The hero heading still wraps awkwardly mid-word | a smaller size or overflow-wrap in the query |
| about.html · ≤600px | The wide table (if you kept Class 6's) forces sideways scroll | tables are Lab 3's hardest case — overflow-x: auto on a wrapper |
The meta-lesson: one media query made the site survive phones, not delight them — and that distinction is the whole gap between today and Lab 3. Notice also what the audit trained: you now instinctively test at multiple widths before calling anything done. That habit — not any single fix — is what "responsive developer" means.
The final pass: does your CSS read like it was written by ONE careful person?
Unit 1's classroom track ends here, so your scratch style.css gets the treatment every professional codebase gets before a milestone: a compliance pass against a written style guide. Not "does it work" — you know it works — but "is it consistent, readable, and honest about its intentions". You'll grade your own scratch file against the exact checklist your instructor grades the real site with in Lab 3.
fswd-practice\Class-12\style.css in VS Code, full screen. Read it top to bottom once before touching anything — auditors read first, edit second.- One brace dialect throughout — this course writes the opening
{on its own line, every rule, no exceptions. Mixed dialects read as two careless authors. - Consistent indentation — two spaces inside every block; four inside a rule nested in a
@mediablock. - Named colours only, and RELEVANT ones — the course canon is
seagreen / darkslategray / mintcream / floralwhite / white. No hex creep, no colour that means nothing. - Sections labelled — one comment banner per region (base · header · dishes · form · phone layout), like line 20's Class-12 banner.
- No dead rules — any property you commented out "to try later" either lives or leaves. The file shouldn't hoard.
- The media query sits LAST — overrides below the rules they override, so the file reads chronologically: default first, exceptions after.
fswd-practice\Class-12\style.css — cosmetic edits only: spacing, comments, ordering. Behaviour must not change.poshtik-campus\ stylesheet in Lab 3, where tidying earns its own separate commit. In a regular class, nothing is committed.Grade honestly. In Lab 3 the same checklist is applied by someone who doesn't love your file as much as you do.
| CHECK | THE USUAL MISS | WHY IT MATTERS BEYOND MARKS |
|---|---|---|
| brace dialect | Class-10 rules use own-line braces; a rushed Part-10 addition sneaks { onto the condition line | consistency is how the NEXT reader (Lab-3 you) trusts the file |
| indentation | rules inside @media left at two spaces, not four | the eye uses depth to see WHAT is conditional — flat indent hides the query's reach |
| colours | a stray hex pasted from a tutorial | the canon exists so every colour means something — seagreen IS the brand |
| section banners | none — 30 rules in one unbroken wall | banners are the table of contents Ctrl+F navigates by |
| dead rules | two commented-out experiments from Class 10 | Git is the attic; the file is the living room |
| query placement | fine — if you appended in Part 10, you already pass | default-then-exceptions is the desktop-first contract, visible in file order |
Why a style guide is a CLASS topic and not lab nagging: from Unit 2 onward you write JavaScript, and JS punishes inconsistency with actual bugs, not just ugliness. The discipline of "one dialect, labelled sections, no dead code" transfers wholesale — you are practising it now on CSS, where mistakes are merely cosmetic, so that it's automatic later, where they aren't.
Take it home
Your responsive kit — the whole class on one card.
| TOOL | DOES | THE ONE THING TO REMEMBER | TODAY'S EXAMPLE |
|---|---|---|---|
| viewport meta | Makes the phone report its REAL width | hard rule: in EVERY head, before any CSS — without it no query fires on a phone | <meta name="viewport" content="width=device-width, initial-scale=1.0"> |
| @media (max-width: N) | Rules for N px or narrower | N is included; ends with TWO closing braces | @media (max-width: 600px) { … } |
| @media (min-width: N) | Rules for N px or wider | the mobile-first workhorse — adds, never undoes | @media (min-width: 601px) { … } |
| and | Joins two conditions into a band | bands must not overlap — 601–991, not 600–991 | (min-width: 601px) and (max-width: 991px) |
| breakpoint | The width where layout changes | chosen where YOUR content cracks — not copied from a holy list | today's scratch page: 600px |
| mobile-first | Phone = default; queries enhance upward | the professional default for every fresh project | base width: 100%, then min-width queries |
| desktop-first | Desktop = default; queries simplify down | the retrofit dialect — used when a desktop site already exists | base width: 300px, then max-width queries |
fswd-practice\ and is thrown away; the continuous poshtik-campus\ repo is edited and committed ONLY in labs. Lab 3 is where today's @media skill and your Activity 3 crack log meet the real site. Bring the crack log in your notebook.Class 12 · closed — and with it, Unit 1's classroom track
CSS is complete. Lab 3 is where it all becomes one site you're proud of.
Twelve classes ago you didn't know what a tag was. Today your scratch page listens to the screen it's on: you shrank a page until it snapped, learned the viewport line as law, wrote max-width and min-width queries, ran the four-band PYQ live, chose a dialect, wrote your first media query, and audited your own work like a professional. Lab 3 takes your Activity 3 crack log and your 6/6 style-guide habit and turns them into graded surgery — polishing the real poshtik site into the version that goes in your portfolio, where it earns its commit.
- Five-minute drill: without notes, write the viewport meta line and one complete @media block — then count the closing braces out loud.
- PYQ rehearsal: write both answers cold — P3·Q16a (role + selector families) and P3·Q11b (the four bands, non-overlapping, with the and syntax).
- Ten-minute experiment: in four-screens.html, change band 1's boundary from 600 to 500, reload, and find the widths where the coat now changes. Breakpoints are yours to move — feel it.