See the Code — Genesis
From “can this go in Tool Time?” through seven pushbacks to its own venue.
Sourced from Tool Time Chatlog
Sessions 30, 31, and 34 • 2026-10-27
This is the founding document of the See the Code venue — a complete record of how the idea traveled from a casual Tool Time consideration to a fully reasoned, dedicated venue with its own name, hook, and scope.
The genesis happened in three sessions of the Tool Time Development Chatlog on 2026-10-27. That material has been brought here so the venue has its own origin story, accessible without navigating 30+ sessions of a different project. Session 4 below documents the founding of this chatlog page itself.
I am building a collection of entries in Tool Time. I have provided you with an overview of the ecosystem, the home page and the chatlog. You are an experienced computer science teacher, a web developer and are developing talented software engineers to be hired in cutting edge AI-based companies. I’m thinking about putting an entry into the Tool Time ecosystem that is just an image, such as the one I’ve attached here. The thought is that a novice should be able to take that starting place and ‘vibe code’ a webpage that renders the output without using the actual image. It would be created solely with HTML and CSS. This is a slight variation from what we’ve done so far, but it seems like a very important and CRAFT-y skill. What are the pros and cons of featuring such projects? To me, it would be a great way to learn HTML and CSS from a reverse engineering approach, as we mention in our about page (attached). Use a list or a table to layout the arguments for including or excluding such projects. Of course, add this prompt to our chatlog along with a critique/grade of how it measures up to our CRAFT prompting scheme.
A−: The three-role spec and the format directive are real advances. One A+ sentence would have been: “Give me exactly five arguments each direction and weight them by impact on novice learning outcomes.”
FOR including image-to-HTML/CSS entries:
- Purest reverse engineering in the collection — no code to lean on, only output to match
- Zero setup barrier — browser + text file, no library or IDE needed
- Immediate visual feedback loop — CSS changes render in milliseconds
- Perfect vibe-coding starter — describing what you see maps directly to what an AI needs
- Teaches a real professional skill — pixel-matching design specs is core front-end work
- Natural CSS concept coverage — forces
font-weight,flexbox,color,border, box model from real need - The image content earns its place — “10 Things That Require Zero Talent” is on-brand for TNT
- Exercises all five C.R.A.F.T. elements in one prompt
AGAINST (cautions):
- Breaks the established Tool Time premise — existing entries start with “novice code that works”
- S.P.A.R.K. is an improvement framework — starting from an image requires reframing Step 1
- Success criterion is vague without a rubric — “does it look like the image?” needs definition
- Different discipline — existing entries are animated p5.js sketches; this is static HTML/CSS
- May warrant its own label or sub-section if the format grows
- Copyright precedent for sourced images
- No “run it” moment — the existing entry template anchors on a live running sketch
- Scaffolding needed for cold entry — image gives no structural hints
Bottom line: “The case for inclusion is strong, but the pedagogical model is genuinely different enough to warrant a clear signal.”
Continuing our dialog about the ‘image to code’ inquiry: Keeping with our ‘Tool Time’ metaphor with ‘Tim the Tool Man Taylor’ this sort of entry fits if one considers that Tim sees a picture of something he wants to build with his large collection of tools. He’s not starting with something, he’s building something from scratch. With modest language descriptions in the home page, I can see this working. I agree we’d need a badge indicator. However, this sort of inclusion is a powerful way to create code from only a visual reference point. Given what you have said, I’m proposing we move forward with this sort of entry in the Tool Time space, but I want you to push back on me again to force me to carefully consider the implications of this choice. It’s the purest form of reverse engineering and verbal description I can think of. Novices can bring their own images to code, giving them more ownership in the process.
B+: The devil’s advocate move is genuinely sophisticated. The missing chatlog directive and undeclared role are the only gaps.
- The Tim metaphor cuts both ways. Tim building from scratch is the show’s setup for disaster. The show’s comedy engine is Tim’s overconfident scratch-building vs. Al’s process-driven improvement. Who is Al in the image-to-code scenario?
- “Novices can bring their own images” is a Pandora’s box. Copyright exposure (brand logos, movie posters, UI screenshots will arrive). Reproducibility filtering (photos are not CSS-achievable). Loss of the attribution model. Build the first entry yourself to define “good” before opening any submission pathway.
- “Verbal description → AI → code” is not the same as learning CSS. A student can produce a near-perfect reproduction without understanding a single CSS property. That is a prompting skill — real and valuable — but it is not CSS comprehension. Existing entries require comprehension because the code exists and can be read.
- The badge solves the gallery problem. It does not solve the chatlog arc. Every existing entry chatlog has: original code with a copy button, a live running version, a S.P.A.R.K. improvement arc, and a before/after comparison. An image-to-code entry has none of these. Design the chatlog format for the new entry type before building it.
- The difficulty level has not been field-tested. The Zero Talent image uses a heavy condensed sans-serif — likely Impact or a commercial face not available in Google Fonts. A novice’s first result may look wrong in ways they cannot diagnose. Validate the challenge is achievable at a novice skill level before featuring it.
- This deserves more than a badge. If the image-to-code format is genuinely a different pedagogy — and it is — it deserves a dedicated venue, not a sub-type within Tool Time. A badge is a workaround; a venue is a home.
- S.P.A.R.K. is an improvement framework. “Set a Goal” in Tool Time is “improve this working code.” In image-to-code it is “create from scratch.” That is a fundamentally different Step 1 — not a small reframe, a complete reframe. The method itself needs adaptation.
Tagline: “You look at it and see a poster. Learn to look at it and see display:flex; font-weight:900; background:#000.”
The Matrix “red dress” monologue as a curriculum. Every image is two things simultaneously: what a human eye sees, and what a browser renders. This venue teaches the transition — the moment when a student stops seeing the picture and starts seeing the layout, typography rules, and box model beneath it.
Format: Image on the left, live HTML/CSS render on the right. The gap between them is the lesson. Students iterate until the gap closes.
Movie hook: The Matrix (1999) — Cipher’s monologue. “I don’t even see the code. All I see is blonde, brunette, redhead…” The metaphor is exact: learning to see beneath surface appearance to the underlying structure is precisely what this venue teaches.
Year 1 scope: Typographic posters only (the “Print Shop” sub-scope). Teacher-curated images from the existing gallery. Eight to ten CSS-eligible candidates already in the gallery. Zero Talent is confirmed Entry #1.
- ✅ The concept is valid and worth building — field test of Zero Talent confirmed “a great first pass”
- ✅ It does NOT belong in Tool Time — different pedagogical model, different S.P.A.R.K. framing, different discipline
- ✅ The skill being taught is prompting AND CSS — be honest that they are two separate skills practiced simultaneously
- ✅ Teacher-curated images only to start — no student-submitted images until format is proven
- ✅ Typographic posters first — narrow scope for Year 1; 8–10 gallery images already eligible
- ✅ Existing gallery is the source — Reverse Gallery infrastructure uses the gallery as navigation surface
- ✅ “See the Code” is the venue name
- ✅ The Matrix Cipher monologue is the movie hook
- ✅ Zero Talent is Entry #1 — field-tested, confirmed
- ✅ “Fonts Matter” is the natural Entry #2 — a poster about fonts, built with CSS fonts
You are a co-developer at TNT, a UX specialist, a professional high school computer science teacher and a developer of aesthetically pleasing web pages designed to engage attention and evoke curiosity. You have a markdown file description of ideas we considered in creating a TNT venue where novices will be given images and asked to create them using only HTML and CSS. We’ve already proven that this can be done with a couple of example images we featured at the TNT Gallery. I’ve attached an example that was ‘ground zero’ for the attempt (pun intended!) I have created a sub folder in TNT: SeeTheCode with sub folders for organization. I’ve attached sister pages from our ToolTime ecosystem so you can see how we’ve laid out other pages that feature other development venues in TNT. In some ways, this is a ‘Reverse Gallery’ where an image becomes code. These images, however, are more like documents that use font, color, text and arrangement in their content. As we did for ToolTime, we’d like a seeTheCodeHome.html with associated styles and seeTheCodeChatlog.html with associated styles. For now, we’ll use the cipher image for the hero background like we used in the movie clip page. I may replace it with an alternative once the pages are built.
A mature, fully-assembled prompt. Five tagged files cover every reference needed. The markdown genesis document is attached, which means the entire decision trail is available without asking follow-up questions. The four-role specification is the richest in the series.
seeTheCodeHome.html, home styles, seeTheCodeChatlog.html, chatlog styles. Each is named; the relationship to the ToolTime ecosystem is established via tagged sister pages.
Grade rationale: A. The four-role specification, the complete context via markdown genesis document, and the graceful placeholder constraint are all genuine advances. The one gap: no difficulty tier chart or entry card spec for the home page. The markdown describes Haiku/Sonnet/Epic — a single sentence about how to present them on cards would have been an A+.
Color identity: Matrix green (#00b800). The cipher movie clip page already established this palette. See the Code inherits it directly — the visual language is consistent with the movie hook and distinct from Tool Time (amber) and the Galton Board (steel blue).
Hero image: ../images/cipherMatrix.jpg (placeholder).
Same image used in cipherSeesMatrixMC.html at center 35%. TTG has flagged this as a placeholder; the hero structure is designed to accept any replacement image without layout changes.
Difficulty tiers rendered as badges: Haiku (green), Sonnet (amber), Epic (red) — consistent with the genre metaphor from the genesis document. The badge colors map naturally to easy/medium/hard without needing labels.
Entry #1 thumbnail path: ../ZeroTalent2026/images/zeroTalent.jpg.
The page includes an onerror handler that renders a green-on-black CSS snippet as a fallback — which is, fittingly, the whole point of the venue.
The prompting vs. CSS distinction is explicit on the home page. Per the genesis document’s key decision #3, the venue is honest that it teaches two skills simultaneously: verbal description (prompting) and CSS structure (coding). The “How It Works” section names both without privileging either.
For every entry in this venue, we’d like to feature a ‘behind the scenes’ page that lists copyable HTML and/or CSS sections of code that can be conveniently copied and pasted for use elsewhere. Let’s create a zeroTalentBehindScenes.html with accompanying page zeroTalentBehindScenesStyles.css to showcase the source code for this file. Since the CSS is within the zero talent document, we’ll just be showing the HTML but in other apps we might be showing both HTML and CSS. In our current color schemes at TNT, we use green for Python, blue for Java and yellow/gold for JavaScript. Since HTML is ‘colorless’ let’s use a light gray for showing its code. I’ve attached an example file (grayson’s song) where we’ve used striped lines (vintage computer paper!) to denote the code. Let’s do that here, but in banded gray. Also, at the bottom of the entry, lets link to the zeroTalentNoStyles.html page so novices can gawk at the page without the styling, the ‘secret sauce’ for the app! Add a cross-link on that page back to the behind-the-scenes page. Add some introductory explanations on the behind the scenes page explaining in broad terms the HTML framework and the CSS styling that produced the final page. Let’s add this prompt and its critique and grade in our seeTheCodeChatlog.html since this is our introductory entry into the ecosystem. Future entries will likely have their own chatlogs.
A very strong prompt. Five tagged files provide exact context. The language/color system is specified from existing conventions. The “secret sauce” framing is both memorable and precise. The one ambiguity — layout of the explanatory section — keeps this from A+.
zeroTalentBehindScenes.html, (2) zeroTalentBehindScenesStyles.css,
(3) reveal link to zeroTalentNoStyles.html, (4) cross-link from no-styles back,
(5) chatlog session. Each is explicitly named; no deliverable is left implicit.
Grade: A− / 91. The action list is complete, the context is excellent, and the “secret sauce” framing is both clever and pedagogically precise. The explanatory-section spec is the only gap. The forward-looking note about two-panel entries for separate CSS files is genuine systems design — it turns a one-off deliverable into a reusable template pattern.
Gray banded paper for HTML.
The Grayson’s Song pattern uses colored paper (yellow=JS, blue=Java, green=Python) with matching
alternating row tints. For HTML, #f4f4f4 base with rgba(0,0,0,0.035) stripes
produces a cool neutral paper that is visually distinct from all three language colors. The dark gray
(#374151) header bar completes the “vintage computer terminal” look.
Copy from variable, never from DOM.
The copyRaw(btn, HTML_CODE) function copies the JavaScript String.raw variable
directly to the clipboard. Reading from DOM textContent would include HTML-escaped entities
(< instead of <), breaking the paste. This is the same discipline
established in Grayson’s Song.
noStyles cross-link uses minimal inline CSS.
The zeroTalentNoStyles.html page has no framework. The cross-link back uses
style=”...” inline on a plain <p> element — the
minimum needed to make it visible on a default-white background. Adding TNT framework to a
“no styles” demo page would defeat its purpose.
Template for future entries. This is Entry #1’s chatlog, but the behind-the-scenes template (gray HTML panel + optional second CSS panel + noStyles reveal) is designed for reuse. Future entries with separate CSS files will add a second panel without changing the page structure. The per-language color convention (gray=HTML, green=Python, blue=Java, gold=JS) is now the established system for all See the Code entries.
What was built: HTML_CODE stored as a
String.raw template literal inside the page’s
<head> <script> block. The HTML source
included </body> and </html>.
Error: Uncaught SyntaxError: Unexpected end of input
at a body line; currentYear is not defined in
onload.
Root cause: Chrome’s HTML parser scans
<script> content for structural closing tags regardless of
JavaScript context. </body> and </html>
inside the template literal caused the parser to prematurely close the
<head>. The JavaScript engine received an incomplete script.
What was built: Switched to a regular template literal using
<\/body>, <\/html> to keep structural tags
out of the HTML parser’s view. All utility functions moved to the
head script. Multi-line onload replaced with
onload="init();".
Error: Invalid or unexpected token at the
/* comment line; Unexpected token '*' at a CSS rule.
Root cause: A JavaScript block comment contained the literal
text (</head>, </body>, </html>) as
documentation. The HTML parser has no concept of JavaScript comments —
it saw </head> and terminated the head. The /*
on the very next line was the first thing the JS engine saw in the
incomplete script, which was parsed as a divide-then-multiply
rather than a comment start.
What was built: HTML_CODE moved to
scripts/zeroTalentBehindScenesData.js, loaded via
<script src="..."></script>. Head
<script> contains only pure JavaScript — zero HTML
tags anywhere, including comments.
Why it works: A .js file is never parsed as HTML.
The browser delivers its bytes directly to the JavaScript engine with no HTML
tokenizer in the chain. String.raw is completely safe in a
.js file. The testing file confirmed correct copy-paste behavior.
There was considerable effort getting this behind the scenes page to validate and run (show the code correctly). To avoid this in the future, please write up (for yourself and for me, the human) the necessary guidelines in the attached markdown file that I can give you next time to alleviate the problems next time. Additionally, write this dialog (and the prompt/critique/grade) in the chatlog for See the Code.
A lean, meta-level prompt: its job is to turn a debugging experience into reusable institutional knowledge. The dual-audience framing (“for yourself and for me”) is the standout move — it explicitly acknowledges that the AI needs the guidelines as much as the human.
Grade: A− / 92. The dual-audience framing and the implicit “AI instruction document” format requirement are sophisticated. The one gap: scope of the debugging documentation is left open. An A+ would say “document all three error rounds with exact console messages.”
The HTML5 parser is not your friend when embedding source code.
Spec-compliant behavior says only </script> terminates a
script element. Real browser behavior in Chrome (and likely others) reacts to
structural closing tags even deep inside JavaScript syntax — template literals,
regular strings, and block comments are all transparent to the HTML parser.
This is not a browser bug worth filing; it is a constraint to design around.
The external .js data file is the correct architecture,
not a workaround. For any page that needs to display source code,
the separation of concerns is: the HTML file handles structure and behavior,
the data file carries the payload. This is the same principle as externalizing
CSS or using a CDN for libraries. The data file is just another resource.
The debugging arc itself is a teaching artifact. The three error rounds — each one revealing a deeper layer of the same root cause — are exactly the kind of problem-solving sequence that CS students and prompting learners need to see. The difference between “fix the immediate error” (escape the closing tags) and “fix the architectural cause” (move the data out of the HTML entirely) is the core lesson of iterative debugging.
The guidelines are a prompt engineering artifact.
Attaching behindScenesGuidelines.md to the next build prompt
is an example of what the Intro to Prompting course calls “Context”
in C.R.A.F.T. — giving the AI a complete, unambiguous picture of the
constraints before asking it to act. Every debugging session that becomes a
reusable guideline is a permanent improvement to the prompting process.
With a working behind the scenes page, let’s add a subtle link below the poster in the talent page so people can look at the code and read about its various features. Add this to our seeTheCodeChatlog page too.
zeroTalent1.html; add chatlog entry. Clean.
Grade: A− / 91. “Subtle” is doing real UX work. The missing spec is the exact visual treatment. An A+ would add: “same hover-reveal pattern as the no-styles cross-link.”
The link sits between the poster and the page bottom margin, centered, in
small muted text: color:rgba(0,0,0,0.28) at rest —
barely visible against the light-gray page background — brightening to
rgba(0,0,0,0.65) on hover. No underline at rest; the
</> prefix signals “code lives here.”
The implementation uses inline CSS and onmouseover/onmouseout
handlers, consistent with the no-styles-page cross-link pattern in the
behindScenesGuidelines.md — no framework, minimal footprint,
works without any stylesheet.
Gemini image-generation prompt:
“An AI Robot is in a vaudeville act, tap dancing on a stage. He’s not very good, so there’s this long hooked cane coming in from the left as if it’s about to pull him into the area off stage.”
Gemini named the robot SPROCKET (chest plate), gave him a jaunty top hat, blue glowing eyes, brass gears, and tap-dance shoes. The marquee at stage left reads “Sprocket’s Big Disaster.” The cane is a proper vaudeville hook — wooden, long, unmistakable. The audience is visible in the balconies, clearly delighted. The warm stage-light amber, theater crimson curtains, and gold-trim arches defined the entire color palette for the Zero Talent entry.
This is a strong example of a Gemini image prompt: one scene, two characters (robot and cane), one action (being pulled), one emotion (dismay). No adjective overload. Gemini filled in the atmospheric detail — the theater, the audience, the marquee — from the vaudeville context alone.
It’s likely that every entry in See the Code will have its own theme. The theme for ‘See the Code’ is Cipher and the Matrix, but since this entry is based on the idea of ‘Zero Talent’ AI created a picture of a robot on stage with ‘No Talent’ and is being withdrawn by the cane. Let’s match this color theme and reference the picture in a whimsical way (being pun-ny) that while it didn’t have much talent novices who can use AI responsibly can certainly develop THEIR talents.
Grade: A. The per-entry theme architecture, the pun directive, and the pedagogical message are all clear and actionable. The missing file-scope spec is the only gap. The result: “Sprocket Got the Hook. You Don’t Have To.” as the hero headline — which is exactly what the prompt asked for.
For reference on that last prompt, the prompt I gave to Gemini to produce the image was: An AI Robot is in a vaudeville act, tap dancing on a stage. He’s not very good, so there’s this long hooked cane coming in from the left as if it’s about to pull him into the area off stage.; let’s put this prompt and our adjustment request prompt in the chatlog as well. Also, because that picture is so engaging, let’s put in a button/link in the ‘Meet Sprocket’ area that loads the picture in a nice frame/modal along with the prompt that generated it, so novices can enjoy the full picture without the dimmed hero effect.
Grade: A− / 91. The WHY of the modal (“without the dimmed effect”) is the strongest part — it transforms a feature request into a reasoned UX decision. Modal styling is the only gap.
Session 8A established a pattern for the entire venue: each See the Code entry has its own color theme derived from the AI image generated for that entry. The venue-level theme (Matrix green, Cipher) stays in the home page and chatlog; the entry-level theme (theater amber and crimson, Sprocket) lives in the entry’s stylesheet.
This is a good design principle: the venue provides the frame, the entry provides the personality. Future entries should: (1) generate an AI image whose color palette drives the entry theme; (2) document the image-generation prompt in the chatlog; (3) give the AI a name (Sprocket sets the precedent); (4) build a thematic callout connecting the AI to the lesson. The modal pattern — full image + generation prompt — is also now a reusable component for every entry.
A quick run of the code revealed that we never showed the original image that we created in code! I think we should show it prominently in the ‘behind the scenes’ area, perhaps as a thumbnail that can be enlarged as a modal so novices can compare the original image with the coded image. This will likely be a standard to follow in future entries. Let’s weave this into our behind the scenes page and insert this prompt and its critique in the chatlog. I’ve included the original image from the images subfolder.
The best-structured prompt in this series for self-testing behavior. “A quick run of the code revealed” is the most important phrase — it shows the developer using the product, noticing a gap, and proposing the fix. That is the correct workflow.
Grade: A / 93. Self-testing that produces a concrete improvement request, a clear format specification, a WHY, and a forward-looking template note — this is what good iterative development looks like from the inside.
The challenge image card is now a named component of every behind-the-scenes entry.
The pattern: thumbnail at left (portrait image, amber border,
clickable) + contextual text at right (“This Is What
You’re Building”, brief description, two action links) +
full-image modal (uses the existing .sprocket-modal-*
styling) + challenge prompt in the modal (what the student needs
to reproduce). Add this component to the behindScenesGuidelines.md
checklist for all future entries.
The two action buttons — “See the Coded Version” (links to the live entry) and “See It Without CSS” (links to the no-styles page) — complete the comparison circuit that the original prompt asked for: original image → coded version → naked HTML bones.
You have the context of ‘See the Code’ and the TNT Home page which sports a link to ToolTime. Let’s create a card that follows the Tool Time card on the index file that links to the seeTheCodeHome page. It should have the Cipher picture as a background and a brief description statement of the venue. I’m open to suggestions on the nature of the badge we could place on it, if any. Let’s write this prompt and your critique and analysis in the chatlog for see the code.
Lean and well-placed. Five tagged files provide all necessary context. The “open to suggestions” move on the badge is the prompt’s most sophisticated element — it explicitly delegates a creative decision rather than under-specifying it or over-constraining it.
index.html (the target),
seeTheCodeHome.html (the link destination), toolTimeHome.html
(the adjacent card for comparison), and the chatlog. “Which sports a link to
ToolTime” efficiently establishes the card’s neighborhood without
re-describing the page.
feature-card pattern. That one
phrase eliminates all layout ambiguity.
Grade: A / 93. The placement constraint, the asset reference, and the badge delegation are all correct prompting moves. The description under-constraint is the only gap.
</> Now: Decoding
The badge is an opportunity to carry the venue metaphor into the home page.
Tool Time uses 📺 Now: On the Air — a television broadcast
pun matching the Home Improvement theme. See the Code’s metaphor is
Cipher from The Matrix: the man who “decodes” the rain.
</> Now: Decoding in Matrix green (#00b800) works on three levels:
</>looks like a closing HTML tag — a code reference that signals the discipline immediately- “Decoding” echoes Cipher who decodes the Matrix rain into meaning — the movie hook
- The word perfectly describes what students do: they “decode” an image into CSS properties
The badge pattern of “[symbol] Now: [action]” is now consistent across both venue cards on the home page. Future venues should follow the same pattern: a metaphor-consistent symbol + “Now:” + a one-word action drawn from the venue’s theme.
There is a white band above (and below?) the Cipher image. If we move the image up in the card, it will look balanced. I’m attempting to use the existing picture aesthetically without having to Photoshop it or find a replacement. Put this in the chatlog too.
cipherMatrix.jpg
The image has a cinematic wide aspect ratio. When used as a card background with
background-size: cover, the card’s portrait proportions crop the
image heavily on the sides. With background-position: center 35% the
crop window was centered on the lower portion of the image, revealing a light/white
letterbox band at the top and potentially at the bottom.
Fix: background-position: center 35%
→ center 15%. A smaller vertical percentage positions the image
higher within the card frame, shifting the interesting content (Cipher’s face,
the monitor glow) into view and pushing the letterbox areas outside the visible crop.
No image editing required.
background-position value is left open. This is fine for a
visual/aesthetic fix — the developer needs to test the value. A screenshot
would have let the developer pick the exact percentage without guessing.
Grade: A− / 91. Clean diagnostic prompt. The constraint (“no Photoshop”) is exact; the solution direction is correct. A screenshot of the visible band would close the last gap.
cipherMatrix.jpg measures 645×276 px — ratio 2.34:1 (strongly landscape).
The feature card on the home page is portrait-oriented (taller than wide).
background-size: cover scales the image so BOTH dimensions ≥ the
container. For a landscape image in a portrait container, the height is the
constraining dimension:
Scale to fill HEIGHT: card_height ÷ image_height At card height 300px: scale = 300/276 = 1.09× → image width = 645 × 1.09 = 703px (>> card width) ✓ covered → image height = 300px = card height exactly ← ZERO vertical overflow
Zero vertical overflow means changing background-position Y
(from 35% to 15% to 5%) has no visible effect whatsoever —
there is nothing to scroll. This is not a CSS specificity issue; it is pure geometry.
The white band visible in the card is burned into the image content itself
(bright ceiling/top of the cinema frame). To fix it, the image must be scaled
LARGER than the container in both axes, creating vertical overflow that
background-position can then control.
The user resolved this on the card by overriding background-size
to force larger scaling.
The See the Code home page hero is a landscape container (full viewport width, ~55vh tall). For the same 2.34:1 image in a wide container:
Scale to fill WIDTH: container_width ÷ image_width At 1440px wide: scale = 1440/645 = 2.23× → image height = 276 × 2.23 = 616px → hero height ≈ 440px (55vh at 800px viewport) → vertical overflow = 616 - 440 = 176px ← position DOES work!
With 176px of vertical overflow, background-position: center 35%
= 35% × 176 = 62px from the top of the image.
Moving to center 10% = 10% × 176 = 18px from the top —
a ~44px upward shift at 1440px viewport width (roughly 30px average across breakpoints).
The change: seeTheCodeHomeStyles.css line 72,
center 35% → the user’s corrected value.
To further adjust: smaller % = image moves up (shows more of top frame);
larger % = image moves down.
cipherSeesMatrixMC.html also uses center 35% / cover
inline in its <style> block. It works because that hero is
also a wide landscape container. The same value that works there will work on
any full-width hero — but will silently fail on a portrait card, because
the geometry is fundamentally different. This is not a visible error; the image
simply fills the card without any response to position changes.
background-position Y Actually Work?
background-position Y only has a visible effect when
background-size: cover produces vertical overflow
(image height > container height). This happens when the container is wider
than the image’s aspect ratio allows at the covering scale. For a
landscape image: use it on wide heroes, not on portrait cards. For a portrait
card, you must override background-size to something larger than
cover (e.g., auto 125%) before Y position control becomes possible.