Everybody's on the Phone Lab

A good curriculum anchor for an abstract concept does three things: it is memorable, it is accurate, and it arrives from an unexpected source. Buffett’s lyric hits all three:

• Memorable: A song lyric sticks in the brain differently than a statistic. Students who hear “so connected and all alone” will remember it long after forgetting that mobile traffic is 60%.
• Accurate: The description of everyone staring at a phone in a social setting is, in 2026, so accurate it reads as journalism rather than poetry.
• Unexpected source: A Jimmy Buffett beach song from 2006 has no obvious connection to web development. That incongruity makes the connection — once made — surprising and therefore more durable in memory.

The additional fact that the song predates the iPhone by a full year is the teaching moment: Buffett observed the behavioral shift before the device that caused it was widely available. That is what makes the lyric prophetic rather than merely descriptive, and prophecy is a better discussion starter than description.

YouTube embeds accept a start parameter (in seconds) that positions the playhead before the video begins. Adding ?start=39 to the embed URL means the video loads already 39 seconds in, placing the viewer directly at the relevant lyric or moment without sitting through a long intro.

This is the same technique used by teachers who cue a DVD to the right scene before class: it respects the student’s attention and signals that the educator has already done the navigation work for them. The specific timestamp also functions as a citation — it tells anyone reading the source exactly which moment in the video the page is built around.

Note for deployment: The YouTube video ID placeholder (BUFFETT_VIDEO_ID) in the embed src must be replaced with the actual video ID for “Everybody’s on the Phone” before the page goes live. Search YouTube for “Jimmy Buffett Everybody’s on the Phone” and copy the 11-character ID from the URL.

When introducing responsive design to students, the “why should I care?” question is always the hardest. Abstract principles (“it’s industry best practice”) produce compliance, not understanding. Numbers produce understanding:

Each statistic answers a specific version of “so what?” together they form an argument that cannot be dismissed as a developer preference. The section closes by crediting Ethan Marcotte’s 2010 coinage of “responsive web design” — giving students the name, the person, and the date, so the concept is anchored in history rather than floating as an abstract rule.

Section 3 replaces the Star Trek “fun facts” section with Bootstrap 5’s six named breakpoints in a table. The table format is intentional: breakpoints are a taxonomy, and taxonomies are best presented as structured lists rather than prose.

Each row names a breakpoint, its class prefix, its minimum width, and a typical device. This gives students four simultaneous reference points — they can look up a device and find its prefix, or look up a prefix and find its width. The col-sm-6 col-md-4 example immediately below the table demonstrates the syntax in context: the rule is stated once in the table, then applied once in prose, closing the gap between reference and usage.

The section ends with a live challenge: “Look at this page on your phone. Resize your browser.” This converts passive reading into an immediate experiment that takes zero setup and produces visible results within five seconds of the instruction — exactly the “visible and tangible” principle from the TNT philosophy.

The user requested that the hero artwork from the movie clip page (jimmmy-buffett-best-albums.webp) be used for pages in the EverybodyOnPhone/ folder. This is deliberate visual continuity: every page in the project shares the same atmospheric image, so navigating between the clip page, the chatlog, and (later) the lab feels like moving within a single cohesive experience rather than jumping between unrelated pages.

From EverybodyOnPhone/, the relative path to the root images/ folder is ../images/ — one level up, same as from movie_clips/. The path is therefore identical in both locations, which simplifies copying and future maintenance.

Note: the image filename contains a triple-m typo (jimmmy) that was preserved intentionally — renaming it would break the existing reference in buffetEverybodyOnPhone.html.

This chatlog was created before the EverybodyOnPhone lab exists. That order is intentional and follows the Movie Credits Simulator pattern: the development record starts on day one, so the first session is documented as the beginning of a story rather than reconstructed after the fact.

Starting the chatlog before the app means:

• The inaugural prompt is preserved verbatim, not paraphrased from memory
• Every decision made — including the ones that seem obvious in the moment — is recorded while the reasoning is still fresh
• Students who read the log see a project that started small and grew, not a finished product presented as if it emerged complete

The sub-navigation bar links to everybodyOnPhone.html even though that file does not yet exist. The broken link is a deliberate placeholder — it shows where the lab will live and makes the connection visible before the lab is built.

Every curriculum that teaches CSS faces the same problem: students do not value styling until they experience its absence. Starting with a styled page and explaining what Bootstrap is doing is like explaining a joke — the explanation is never as good as the experience.

The three-step sequence — unstyled HTML, styled CSS, responsive layout — mirrors how the web actually developed: HTML (1991) first, CSS (1996) second, responsive design (2010) third. Students who see the steps in order have an accurate mental model of what each layer adds. Students who start with Bootstrap often see it as a black box of magic classes.

The unstyled page is not a failure state. It is Step 1. Framing it explicitly in the page (the teacher-note section) prevents students from experiencing it as something broken that needs to be fixed, and positions it instead as the baseline that CSS will improve.

A song lyric page has a clear content hierarchy: the whole song is one cohesive creative work (an <article>), each structural unit (verse, chorus, bridge) is a named subdivision (a <section>). Two implementation decisions made this maximally accessible:

The pre-chorus lines (“Talkin’, squawkin’, hawkin’”) are grouped as a second <p> within Verse 1 rather than their own section — they are a coda to the verse, not an independent structural unit.

The user requested a “mini-nav bar for breadcrumbs.” The WCAG-compliant breadcrumb pattern uses an ordered list inside a <nav aria-label="Breadcrumb">: ordered because breadcrumbs have a hierarchy (Home → Section → Current), and labeled so screen readers distinguish it from other navigation landmarks on the page.

The final list item carries aria-current="page" and has no <a> tag — it is the current page, so linking it would be both misleading and redundant. This is the ARIA pattern for “you are here.”

An unstyled breadcrumb looks like a plain numbered list. That is intentional: it reinforces the lesson that an <ol> is not inherently a breadcrumb until CSS (and possibly JavaScript) transforms it into one. The structure is correct; the presentation is absent.

Without the teacher-note section, a student encountering this page for the first time might reasonably conclude it is broken. The note prevents that misreading by naming the situation explicitly: this is Step 1, not a mistake.

The note does three things:

1. Names the semantic elements visible on the page — students who read the note while viewing the page can verify each claim (“the song is an <article>”) by opening DevTools and inspecting the DOM.
2. Describes the missing layer (“No colors, no spacing, no custom font”) — names the CSS properties that will be added in Step 2.
3. Maps the four-step curriculum sequence — positions this page not as an endpoint but as the start of a journey with a clear next step.

The note is in a <section> with its own <h2> heading, not a <div>. This means a screen reader user navigating by headings will encounter it as a distinct named section of the page — “What You’re Looking At” — rather than as unmarked prose.

The unstyled page includes <meta name="robots" content="noindex, nofollow">. This prevents search engines from indexing it or following its links. Two reasons:

• It is not a finished product. A search result pointing to a visually broken page misrepresents the site. Google would serve a result that looks like TNT is broken.
• It is a curriculum step, not a destination. This page exists to be compared against the styled version that follows. A visitor who arrives without context has no frame of reference for what they are seeing.

The nofollow directive also prevents search equity from passing through the page’s outbound links to the movie clip and chatlog pages. Those pages earn their indexing through the main TNT navigation, not through a demo artifact.

The standard professional practice is to keep CSS in an external .css file (separation of concerns). Here it is intentionally in a <style> block, for one specific reason: every rule is immediately visible in DevTools without needing to open a second file.

When a student opens the Elements panel and clicks any element, the Styles pane shows the rule, its selector, and its line number inside the <style> block — all in one view. They can click the line number to jump directly to the rule in the Sources panel. This closed loop — element → rule → source — is harder to follow when the CSS is in a separate file, especially for beginners.

The decision also teaches by example: students see the comment explaining why the CSS is inline. When the external stylesheet version arrives, the contrast will make the separation-of-concerns argument concrete rather than abstract.

The palette was derived from Jimmy Buffett’s visual identity (the hero image, album art, and the Margaritaville aesthetic) rather than selected arbitrarily. This matters pedagogically: it demonstrates that color choices in real projects are not random — they come from a brand, a reference image, or a deliberate mood.

The CSS custom properties (:root { --jb-ocean: ... }) make this palette inspectable and editable in real time. A student can open the Styles pane, find the :root rule, change --jb-ocean to navy, and watch every dark surface on the page update simultaneously — a live demonstration of design systems in miniature.

The only HTML change between the unstyled and styled versions is adding three class names to the <section> elements: .verse, .chorus, and .bridge. This is the minimum change needed to give CSS something to target distinctly.

The names are semantic (they describe what the content is, not how it looks), which makes them reusable. If the chorus color changes from coral to blue tomorrow, only the CSS changes — not the HTML. Class names like .coral-section or .highlighted would couple the HTML to a specific visual state, which is exactly what CSS is supposed to prevent.

This three-class change also makes the curriculum point visible: “we added three words to the HTML and changed everything about how three different types of content look.” That ratio — tiny HTML change, large visual result — is the CSS value proposition in miniature.

This page has no @media rules. The layout will look good on a laptop, acceptable on a tablet, and cramped on a phone. That is intentional: the next session adds media queries, and students need to experience the before-state to appreciate what the after-state fixes.

If media queries were silently added “for free,” the session would lose its teaching moment. When students open this page on their phones and see the cramped text, they will ask why — and that question is exactly what Session 4 answers.

A similar sequence is used throughout this curriculum: unstyled before styled, non-responsive before responsive. Each step is deliberately incomplete so the next step has something concrete to improve. The ugliness is the motivator; the fix is the lesson.

The breadcrumb on the CSS page includes “Unstyled” as a live link, one click from the current page. The unstyled page’s footer and teacher note were updated to link forward to “With CSS.” This creates a bidirectional comparison path:

• From the CSS page: click “Unstyled” → same content, browser defaults only
• From the unstyled page: click “With CSS” → same content, tropical styling

The ability to switch instantly between the two is more powerful than any explanation. Students who toggle back and forth will see exactly what CSS added — without needing to diff source code or read documentation. The comparison is the instruction.

The movie clip page’s hero image (jimmmy-buffett-best-albums.webp) was added to the header using the CSS background shorthand with two layers stacked:

The gradient is listed first (topmost layer) and the image second (behind it). The gradient uses rgba() with ~84–92% opacity so the photograph shows through — a standard professional technique for keeping text readable over a photo without completely hiding the image. DevTools students can toggle the gradient rule off and see the raw photograph underneath.

This belongs in Session 3 (aesthetics) rather than Session 4 (responsiveness): background images are a CSS visual feature, not a layout or breakpoint concept. The user correctly identified that the scope fits this stage.

The C.R.A.P. design principle — Contrast, Repetition, Alignment, Proximity — demands that text be distinctly readable against its background. The <code> rule set dark-teal text (--jb-ocean: #005f68) on a near-transparent dark-teal background, both sitting on top of an already-dark header gradient. The result: dark on dark, effectively invisible.

The fix adds a more specific selector that overrides the general rule for code inside the dark header only:

Sunshine gold (--jb-sun: #ffd166) on a semi-transparent white background reads cleanly against the dark ocean gradient. This is the fix; here is the teaching moment:

• C.R.A.P. Contrast — contrast is relational. The dark-teal code color was fine everywhere else on the page (light sandy background). It failed only inside the dark header because the relationship between foreground and background changed. A color that passes in one context can fail in another.
• CSS Specificity — body > header code has higher specificity than code, so it overrides without !important. DevTools shows both rules in the Styles pane — the general rule struck-through, the specific rule winning.

One bug, two lessons. That is the most efficient kind of fix.

A media query is a CSS conditional grouping rule. The basic form is:

The condition is typically a viewport dimension. The two most common:

Why does the @media rule win over the default? Not specificity — both selectors are identical. Source order: the @media block appears later in the stylesheet. When the condition is true, the later rule takes effect. When the condition is false, the later rule is skipped entirely, and the earlier default wins.

This is why the @media blocks are placed at the bottom of the <style> block. If they were at the top, the default rules would override them regardless of screen size.

Two philosophies exist for structuring responsive CSS, and professionals actively debate their merits:

Both produce the same visual result at any given viewport width. The difference is which screen size is the “default” and which is the exception that requires an explicit breakpoint.

Desktop-first was chosen here because the CSS already existed as desktop styles. Adding max-width rules is the minimal, readable addition. Rewriting everything mobile-first would be a refactor, not a teaching example — and seeing the override structure explicitly is the point.

Google’s mobile-first indexing evaluates your page as a phone would see it. Bootstrap’s mobile-first grid aligns with this. When we move to Bootstrap in Session 5, students will see that its col-sm-6 classes use min-width internally — the same concept, packaged into a class name.

The two breakpoints (768 px and 480 px) were not chosen because specific devices exist at those widths. They were chosen because the CSS page starts to look cramped at those widths. This is the correct criterion.

The traditional approach — a fixed set of breakpoints tied to known device dimensions — creates a maintenance problem: devices change constantly, but your CSS is frozen at last year’s screen sizes. The modern standard is: add a breakpoint where the design breaks, not where a device exists.

The DevTools Device Toolbar is the tool for finding breakpoints: drag the viewport handle left until the layout looks wrong, note the width, add a breakpoint there.

The DevTools Styles pane has specific behavior with media queries that makes it ideal for teaching:

• Rules inside an inactive @media block are listed but visually dimmed — the browser is showing you what would apply at a different viewport, even though it is not currently applying it.
• Rules inside the active @media block (the one whose condition is currently true) appear normally, showing the source line and allowing live editing.
• The Device Toolbar (Ctrl+Shift+M) dynamically updates both the rendered layout and the Styles pane simultaneously. Drag the width handle and watch the active/inactive state of each @media block flip in real time.

This live visibility is why keeping all CSS in a single <style> block (as this curriculum does) is valuable for learners: every rule — default and media-query override — is reachable without switching files.

The clearest way to teach Bootstrap’s value is to show the direct equivalence between manual CSS + @media and Bootstrap utilities. The eopBootstrap5.html teacher note includes this table:

The result: the custom <style> block shrank from ~65 rules with 2 @media blocks to ~20 rules with zero. The visual output is identical. Bootstrap did not change what the page looks like; it changed how much code was needed to make it look that way.

Bootstrap 5 ships with rfs (Responsive Font Size) built in. Every .display-* and .h* heading class automatically scales its font size across viewport widths using calc() and clamp() under the hood. No @media override required.

In the media-queries version, three rules managed the h1 size:

In the Bootstrap version: one class (display-5) replaces all three. The scaling is continuous and smooth across the full viewport range, not stepped at two breakpoints.

Bootstrap is a layout and component framework, not a design system. It cannot know about Jimmy Buffett, tropical beaches, or the visual distinction between a chorus and a bridge. The custom <style> block in eopBootstrap5.html still contains ~20 rules for:

• Tropical color palette (--jb-* custom properties)
• Background image + gradient on the page header
• Chorus sections (coral gradient + left border)
• Bridge section (gold tint)
• Lyric text left border and line-height

This is the correct division of labor: Bootstrap provides the structural skeleton; custom CSS provides the personality. Neither is optional; neither can fully replace the other.

A four-page curriculum without a cover page forces every new visitor to enter at a random stage. The cover page (everyBodyOnPhoneCover.html) solves this by:

• Framing the whole arc — four stage cards show the progression from zero CSS to Bootstrap 5 at a glance
• Providing the correct entry point — the movie clip page now links here rather than to a placeholder; every path into this curriculum starts at the same hub
• Demonstrating the curriculum’s own thesis — the cover page itself uses Bootstrap’s responsive row-cols-1 row-cols-sm-2 row-cols-lg-4 grid to lay out the stage cards. The page is an example of what it teaches

The cover page lives in the Styl’n category because the curriculum’s subject is CSS and responsiveness. The TNT navbar marks Styl’n as active, correctly placing this alongside other visual-design showcases.

The four stage cards on the cover page use Bootstrap’s row-cols-* shorthand:

This reads: “1 card per row by default (phone), 2 per row at sm (≥576px), 4 per row at lg (≥992px).” No individual col-* classes needed on each card. This is Bootstrap’s most expressive responsive pattern for equal-width card grids.

Students who drag the Device Toolbar across this cover page will watch the 4-card row collapse to 2 cards and then to 1 — the same breakpoint behavior they coded manually in Session 4, but expressed in three class names.

A TNT app is not “launched” because its files exist on the server. For a new app to be discoverable and documented, three files must always be updated:

Two rules govern explore.html entries:

• Category cards are capped at 3 featured apps. When a card already shows 3 apps, new apps go only into the offcanvas panel.
• Only the S.P.A.R.K. offcanvas links to chatlogs. Styling and other subject-matter panels list apps only; chatlog links belong in S.P.A.R.K. where the development dialog is the primary subject.

The “Everybody on the Phone” curriculum belongs in both the S.P.A.R.K. and Styling offcanvas panels because it is simultaneously a S.P.A.R.K. project (five sessions documented, 27 decisions) and a Styling showcase (the subject is CSS and responsiveness). When an app qualifies for two categories, it goes in both.

The C.R.A.P. Repetition principle requires that recurring elements — navigation especially — look and behave the same everywhere. The cover page and chatlog had the complete seven-link EOP sub-nav. The four stage pages had inconsistent, truncated breadcrumbs (3, 4, 5, and 7 links respectively, in different orders).

Every stage page now lists the same seven destinations in the same order:

The cover page and chatlog use a styled Bootstrap bar (.eop-spark-bar). The Bootstrap 5 stage uses a Bootstrap breadcrumb component. The CSS and media query stages use a custom-styled <nav> with an <ol>. The unstyled page uses a plain <ol>. Four different visual implementations — one consistent information architecture. This is the correct application of C.R.A.P. Repetition: the information is standardized, not the styling — each page’s nav style is appropriate to its own CSS stage.

The cover page hero used no width-constraining wrapper. At narrow viewports, the .eop-hero-lyric element (a left-bordered quote block) overflowed its container because display: inline-block sizes to content, not to the viewport.

Two changes resolved the overflow:

• Container wrapper — <div class="container"> added around all hero content. Bootstrap’s container applies responsive horizontal padding at every breakpoint, preventing content from touching viewport edges on mobile.
• Lyric block — display: inline-block changed to display: block; max-width: 520px; margin: 0 auto. The block is now constrained, centered, and cannot exceed its parent’s width. text-align: left preserves the left-aligned quote appearance inside the centered block.

This is a direct live demonstration of the lesson on Bootstrap’s .container: the cover page was not using Bootstrap’s layout system in its own hero section, and it showed on a phone.

The #bootstrapBreakpoints table in buffetEverybodyOnPhone.html has four columns. On portrait phones below 475px, the table exceeded its container width, overflowing the page.

A media query hides the table at max-width: 474px and shows a rotation prompt (.bp-rotate-warning) in its place. The breakpoint was chosen at 474px rather than 576px (Bootstrap’s sm boundary) because landscape phones above ~475px can comfortably display the four-column table.

Showing a broken overflowing table is worse than showing no table at all. The rotation prompt sets a clear expectation rather than leaving the student wondering why content is cut off. This is responsive design applied to a page about responsive design — a usable meta-lesson.

The amber curriculum callout on buffetEverybodyOnPhone.html originally appeared after .clip-wrapper. On mobile (below 576px), the clip-wrapper is hidden. Mobile users saw only the three <details> sections and a clips-unavailable warning — with no visible next step.

Moving the callout above the clip section ensures mobile users always see the curriculum link regardless of viewport. The resulting mobile flow:

1. Three educational details sections
2. Amber curriculum callout — “Explore the Curriculum”
3. Red clip warning — “clips unavailable on this viewport”

The amber-then-red color sequence is a minor cosmetic consideration noted but accepted: the information hierarchy (curriculum navigation before clip availability notice) outweighs the visual tension between the adjacent colors.

Three related fixes to the chatlog’s own “About this Chat Log” section, discovered by the same mobile-review process documented in Decisions 29–30:

• Session 6 row added to the summary table — a chatlog that omits its most recent session is incomplete by definition. The about-box table now documents all six sessions including the post-launch refinement work.
• Table hidden at < 475px with rotation prompt — the three-column session table overflowed on portrait phones, creating a horizontal scroll context that caused the page to appear left-shifted in Chrome DevTools mobile preview. Same max-width: 474px pattern as #bootstrapBreakpoints — consistent treatment of overflowing tables across the project.
• overflow-x: hidden on body — prevents any child overflow from shifting the page horizontally. Safe for a single-column document; .chat-bubble pre already carries its own overflow-x: auto for scrollable code blocks.

Intro text updated from “four-stage unit” to accurately describe the curriculum: six sessions, the first five building the four CSS stages, the sixth documenting post-launch refinements.

Width-based breakpoints (max-width, min-width) are the most common media query type, but the orientation media feature opens a different axis: portrait vs. landscape. The background color change makes the difference visceral — sandy cream becomes sky blue on rotation, snapping back on return. That immediate, dramatic visual shift creates an “aha” moment that a subtle padding change would not.

The query uses two conditions joined by and:

The max-height: 600px is the device filter. Phones in landscape have heights of roughly 320–430 px; laptops and desktops are typically 768 px or taller even in a narrow window. Setting the threshold at 600 px means phones in landscape trigger the rule while desktops do not — even when a user makes their browser window wider than tall. Without this constraint, resizing a laptop browser into landscape geometry would produce confusing background changes unrelated to mobile orientation.

The color #98d1f2 is a recognizable sky blue — associated with “looking up” in landscape — and contrasts sharply enough with the sandy cream of portrait mode to register without DevTools. That matters for students who encounter the change on a physical phone before opening the inspector. A subtle color change teaches nothing; a dramatic one teaches immediately.