Building Ethan’s Crazed Emoji Showcase

Mason’s app showed a pre-rendered PNG because Python Turtle Graphics produces a static bitmap. There is no live version to show. Ethan’s sketch is different in every way: it loops at ~60 frames per second, uses frameCount to animate, and its defining visual features (spinning spiral eyes, oscillating tongue) are only visible in motion.

A static screenshot of Ethan’s sketch would show a blurry smear where the spiral eyes are mid-rotation — identical to how a slow shutter on a spinning propeller produces a visual artifact instead of the actual shape. The only honest representation is the running canvas. The page therefore loads p5.js and runs the sketch live, right next to its source code.

Mason’s page used a warm cream background because the Python emoji face is drawn on a light gray canvas and a dark page would create jarring contrast. Ethan’s sketch also uses background(240) (light gray). The same logic applies — but the “crazed” theme argues for something more dramatic.

Decision: dark navy background (#0a0b1a) with yellow accent (#ffcc00, the emoji face color). The light canvas appears as a glowing window against the dark page — a spotlight effect that makes the animation more visually striking than it would be on a cream background. The hero uses the same dark-navy-to-dark-red gradient as the page, framing cuckoo.jpg without competing with it.

Ethan’s sketch uses p5.js global mode: setup(), draw(), and drawSpiralEye() are plain global functions. In global mode, createCanvas() appends the canvas to document.body — the very last element, not a specific column layout position.

To place the canvas in the right column, next to the greenbar code display, p5.js needs to know which container to target. This requires instance mode, where a sketch function receives a p object and attaches to a named <div>:

var ethanSketch = function(p) {
    p.setup = function() {
        let cnv = p.createCanvas(460, 400);
        cnv.parent('ethansCanvas'); // target container by id
        p.angleMode(p.DEGREES);
    };
    p.draw = function() { /* ... */ };
};
new p5(ethanSketch);

The critical question: does using instance mode mean modifying Ethan’s original code? No — and this distinction matters. The page separates two things:

1. The code that is displayed in the greenbar is Ethan’s original global-mode source, stored in a JavaScript template literal ETHAN_CODE. It is passed to buildCodeDisplay() and rendered line-by-line in the greenbar. It is never executed.
2. The code that runs is an inline instance-mode adapter that contains the same logic — same drawing commands, same math, same animation — but with p. prefixed throughout and a cnv.parent('ethansCanvas') call added. The original file sketches/origEmojiSketch.js is untouched.

The displayed code is authentic; the running code is adapted for context. Both are faithful to Ethan’s work. This is the same principle applied in the Magic 8 Ball refactor: preserve working, tested code; build a new presentation layer around it.

Mason’s greenbar displayed Python. Ethan’s displays JavaScript. The CSS technique is identical: nth-child(6n±) for three-line group alternation, counter-reset / counter-increment for auto-generated line numbers, and ::before for the selection-proof gutter. The only thing that changes is the syntax highlighter.

For JavaScript, the comment detector scans each line character by character, tracking whether it is inside a single- or double-quoted string before treating // as a comment boundary. This prevents stroke(204, 136, 0) (which contains no //) from being confused with // comment, and prevents color strings like “#ffcc00” (which contain characters but not //) from triggering false positives. Keywords are highlighted with a simple word-boundary regex applied only to the non-comment portion of each line.

The original sketch uses createCanvas(500, 400). In the page layout, the canvas column is col-lg-5 — approximately 380–460px wide depending on viewport. A fixed 500px canvas would overflow on narrow screens.

The instance-mode adapter reads the container’s offsetWidth at setup time and clamps it: var w = Math.min(container.offsetWidth || 460, 460). The height is derived at 0.87× the width, maintaining the original 5:4 aspect ratio. At 460px wide, the canvas is 460×400 — identical to the original proportions. Below that, it scales down proportionally. The face (300×300) has comfortable margin at 460px and remains visible down to approximately 340px canvas width.

The Explore page category cards were already full, so both S.P.A.R.K. and Processing entries were added to their respective offcanvas panels only.

S.P.A.R.K. offcanvas — Two entries added after the Twelve Days Parody chatlog entry:

• Ethan’s Crazed Emoji (showcase link, lang-badge lang-js p5.js)
• Ethan’s Crazed Emoji — Chat Log (chatlog link, lang-badge lang-js S.P.A.R.K.)

Processing offcanvas — One entry added after the Lemur Game entry (chatlog not duplicated here):

• Ethan’s Crazed Emoji (showcase link, lang-badge lang-js p5.js)

A news entry was added to news.html as entry #069, inserted above entry #068 (Quadratic Class Grows Up). The entry title, date format, accordion structure, and link-with-icon style match the surrounding entries.

The entry summarises the four key points: the live canvas decision, the instance-mode adapter pattern, the original file being untouched, and the chatlog’s five design decisions. Two links close the entry: the showcase page (with a fa-face-grin-squint icon) and the chatlog (with fa-comments).

Why first: Every other improvement is easier to make and easier to teach once each facial feature lives in its own named function. This is the architectural change that turns a monolithic draw() into a readable recipe.

1. Extract drawFace() — the yellow ellipse and stroke. One feature, one function. A student can comment out the call and the face disappears but the eyes and mouth stay. That single observation teaches the lesson.
2. Extract drawEyebrows() — the two arc() calls that create the wild asymmetric brows. These are standalone geometry with no state dependency on other features.
3. Extract drawEyes() — both eye push/rotate/drawSpiralEye/pop blocks. drawSpiralEye() already exists as a helper; drawEyes() becomes its caller, managing the two translate/rotate transforms. This is the primary push/pop teaching function.
4. Extract drawMouth() — the off-center dark ellipse. Simple geometry; good starter function for students writing their first extractions.
5. Extract drawTongue() — the push/translate/rect/line/pop block. This is the primary sin()/cos() oscillation teaching function. Wrapping it in a named function gives the motion a name that students can search for and study.
6. Rewrite draw() as a call list:

   function draw() {
     background(240);
     translate(width / 2, height / 2);  // center origin once
   
     drawFace();
     drawEyebrows();
     drawEyes();
     drawMouth();
     drawTongue();
   }//end draw

   This draw() reads like plain English. A student who has never seen the rest of the file can predict what it does from this alone.

Teaching payoff: Comment out drawEyes(). The face, brows, mouth, and tongue render; the eyes vanish. Restore it. Comment out drawTongue(). The emoji goes still. That hands-on cause-and-effect is the modularization lesson no slide deck can replace.

Why second: Once functions exist, the magic numbers are clearly owned by their feature. Named constants belong at the top as a “control panel” — one place to change one value and have everything respond. This is the DRY (Don’t Repeat Yourself) lesson.

1. Declare face constants: var FACE_DIAM = 300;, var FACE_STROKE_W = 8;. Every reference to 300 in the original becomes FACE_DIAM.
2. Declare eye constants: var EYE_L_X = -60; var EYE_L_Y = -20;, var EYE_R_X = 60; var EYE_R_Y = -10;, var EYE_L_SIZE = 50; var EYE_R_SIZE = 80;, var EYE_SPEED_MULT = 2;, var EYE_R_SPEED_MULT = 1.9;. That last one is the most important — the “1.9” was a creative choice Ethan made. A name honours that choice.
3. Declare tongue constants: var TONGUE_SPEED_X = 8; var TONGUE_SPEED_Y = 12;, var TONGUE_DIST_X = 15; var TONGUE_DIST_Y = 8;. The multipliers inside and outside the sin()/cos() calls are the most educational constants in the entire sketch — changing them produces visually immediate feedback.
4. Organize by feature at the top of the file: A block of face constants, then eye constants, then tongue constants. The file now has a “settings panel” a student can tune without reading the drawing code.

Teaching payoff: Change EYE_R_SPEED_MULT from 1.9 to 3.0. The right eye spins faster and the crazed effect intensifies. Change it to 1.0. Both eyes spin at the same rate and the asymmetry vanishes. One variable. Two dramatically different animations. This is why we name things.

Why third: Phase 2 gives color values a name; Phase 3 gives those names a meaning any human can read. var FACE_HUE = 48 is only useful if the reader knows that 48° is yellow-orange. Without HSB mode, a student still needs a color picker to interpret the constant. The two phases complete each other: names become interpretable only once the color model speaks human.

One line in setup() switches the entire sketch from RGB to HSB:

colorMode(HSB, 360, 100, 100, 100);
// H: 0-360 (color wheel)   S: 0-100%   B: 0-100%   A: 0-100%

All color calls in the sketch then become self-documenting:

1. Face fill(255, 204, 0) → fill(48, 100, 100) — 48° = yellow-orange, 100% saturation, 100% brightness. Pure emoji yellow, stated explicitly.
2. Brown outline stroke(90, 50, 10) → stroke(30, 89, 35) — 30° = warm brown, 89% saturated, 35% bright = dark earthy brown. The darkness is directly readable from the brightness value alone.
3. Mouth interior fill(80, 20, 20) → fill(0, 75, 31) — 0° = red axis, 75% saturation, 31% brightness = deep blood-red. A student who reads 31 knows it is dark before running the code.
4. Tongue fill(255, 80, 100) → fill(353, 69, 100) — 353° = just past red into pink, 69% saturation, full brightness = vivid pink-red.
5. Pair HSB with named constants from Phase 2: var FACE_HUE = 48; var FACE_SAT = 100; var FACE_BRI = 100;. The constant names are readable; the HSB values are interpretable. Together they form a self-documenting color palette — the full expression of Phase 2’s intent.

Teaching payoff: Change FACE_HUE from 48 to 180. The face turns cyan. Change FACE_SAT from 100 to 20. The face desaturates to near-white. Students are now composing color by thinking — hue, saturation, brightness — rather than guessing RGB combinations. That shift from guessing to knowing is what HSB mode teaches.

Why fourth: After Phase 1, functions exist but they may leave transforms in an inconsistent state. Phase 4 enforces the rule that every function that calls translate() or rotate() must open with push() and close with pop(). This makes every function independently commentable and independently testable — the “Leave No Trace-y” principle applied to p5.js.

The principle: when your function ends, the coordinate system should look exactly as it did when your function started. Your function should leave no trace on the transform stack.

1. Audit every function for unclosed transforms. Ethan’s spiral eyes already use push/pop correctly — note that as a teaching compliment. The tongue already uses push/pop. Verify the other functions introduce no stray translations.
2. The established pattern for every feature function:

   function drawEyes() {
     // Left Eye — push: save state; rotate; draw; pop: restore
     push();
       translate(EYE_L_X, EYE_L_Y);
       rotate(frameCount * EYE_SPEED_MULT);
       drawSpiralEye(EYE_L_SIZE);
     pop();
   
     // Right Eye — opposite spin, 1.9× faster
     push();
       translate(EYE_R_X, EYE_R_Y);
       rotate(-frameCount * EYE_SPEED_MULT * EYE_R_SPEED_MULT);
       drawSpiralEye(EYE_R_SIZE);
     pop();
   }//end drawEyes

   The indentation inside push/pop is optional style but makes the nesting visually explicit for students.
3. Add a brief comment at each push/pop pair explaining what state is being saved and why it needs to be restored.
4. Test by commenting out individual functions. After Phase 3, every function can be commented out independently and the remaining features still render correctly. That is the test. If commenting out one function breaks another, push/pop discipline is incomplete.

Teaching payoff: Remove one pop() from drawEyes(). Watch what happens to the mouth and tongue in subsequent frames. The accumulated transform makes them fly off-canvas. Restore the pop(). The sketch is immediately correct again. Students remember the lesson because they saw the breakage. This is the most visceral p5.js lesson available.

Why fifth: Only after the code is modular (Phase 1), named (Phase 2), colorized in HSB (Phase 3), and disciplined (Phase 4) does scalability become clean. Adding scale to messy code produces messy scaled code.

1. Derive FACE_RADIUS from canvas width: var FACE_RADIUS = width * 0.30; — the face fills 60% of the canvas width. All other constants that were previously tied to FACE_DIAM = 300 become expressions of FACE_RADIUS. At 500px wide: FACE_RADIUS = 150 = half of 300. Exact match.
2. Express positional constants as ratios of FACE_RADIUS: Eye X-offsets are approximately 40% of the face radius (EYE_L_X = -FACE_RADIUS * 0.40). Eye sizes are roughly 33% and 53% of the face diameter. Derive these from the original hardcoded values: 60/150 = 0.40, 50/300 = 0.167. The math is the lesson.
3. Move constant calculation into setup(): Since width is not defined before createCanvas(), all derived constants must be computed after the canvas is created. This is itself a teaching moment: variable declaration order matters.
4. Add windowResized():

   function windowResized() {
     resizeCanvas(windowWidth, windowHeight);
     recalcConstants();  // re-derive FACE_RADIUS and friends
   }//end windowResized

   Dragging the browser window resizes the emoji in real time. The first time a student sees that, they understand what “scalable” actually means.

Teaching payoff: Change createCanvas(500, 400) to createCanvas(800, 640). The emoji grows proportionally without touching a single drawing constant. Change it to createCanvas(250, 200). It shrinks. That is scalability: one change propagates everywhere.

Why last: Breadcrumbs and instructional comments are most useful when the code they describe is already clean. A breadcrumb in a tangle is noise. A breadcrumb in a well-structured function is a lesson.

1. Add SHOULD_SHOW_BREADCRUMBS flag (the TNT pattern, demonstrated in the Quadratic Upgrade). One boolean at the top. true = every function announces itself in the DevTools Console; false = silent animation.
2. Add console.log(“...drawFace...”) at the top of each function, gated by the flag. With 60 frames per second, this produces a flood of messages — which is itself a lesson in animation loops: draw() runs sixty times every second.
3. Annotate the oscillation math in drawTongue():

   // sin/cos oscillation: multiplier INSIDE controls speed (8 = fast)
   // multiplier OUTSIDE controls distance (15px left/right swing)
   // two independent functions = non-repeating Lissajous-style wobble
   var tongueOffsetX = sin(frameCount * TONGUE_SPEED_X) * TONGUE_DIST_X;
   var tongueOffsetY = cos(frameCount * TONGUE_SPEED_Y) * TONGUE_DIST_Y;

4. Consider a “Stage 3: Scaling” showcase page (following the Mason’s Nerdy Icon pattern) that shows the Stage 2 refactored code alongside the Stage 3 scaled version, side by side in separate browser tabs.

Teaching payoff: Open DevTools. Set SHOULD_SHOW_BREADCRUMBS = true. Watch the Console scroll. Count the messages per second. A student who does this has just measured 60fps with their own eyes. That is more memorable than any lecture about animation loops.

The “View the Showcase” button serves a reader who has just finished reading. Two intermediate buttons implied the log was complete at those points — it was not. A single button at the very end of the document is more accurate (the log is done here) and less visually disruptive to a document meant to be read linearly.

Why Phase 3 — after Named Constants, before Push/Pop:

Phase 2 gives color values a name. Phase 3 gives those names a meaning a human can read. var FACE_HUE = 48 is only useful if the reader knows that 48° is yellow-orange. Without HSB, a student still needs a color picker to interpret the constant. The two phases complete each other: names become interpretable only once the color model speaks human.

HSB precedes Push/Pop (Phase 4) because it is a color model change, not a transform structure change. It touches every fill() and stroke() call in the file but does not touch the transform stack at all. Push/Pop’s scope is transforms only. Keeping the two lessons in separate phases keeps each one independently teachable: one phase changes how colors are expressed; the next changes how coordinate systems are managed. Two separate ideas; two separate lessons.

Phase 1 required three new files. Each has a single clear responsibility:

1. phase1EmojiSketch.js — The standalone, documented, global-mode p5.js refactor. This is the file a student would open, study, and run on its own (with a local HTML wrapper or p5.js web editor). It contains the full Phase 1 code with explanatory comments at every function and every push/pop pair. It is the teaching artifact.
2. ethanCrazedEmojiPhase1.html — The showcase page. It displays the Phase 1 code in the greenbar (sourced from a PHASE1_CODE template literal, identical to ETHAN_CODE in the original) and runs the same logic as an instance-mode adapter to place the canvas in the correct column. The same architectural separation as the original: displayed code is authentic global-mode; running code is adapted for DOM placement.
3. ethansCrazedEmojiPhase1Styles.css — A self-contained CSS file, identical to the original’s styles except the canvas target changes from #ethansCanvas to #phase1Canvas. Keeping separate CSS files means each page is independently maintainable — a future Phase 2 palette change does not accidentally alter Phase 1.

Five feature functions were extracted from draw(), plus drawSpiralEye() was already a helper in the original and was kept. Here is what each extraction did:

The result: draw() shrank from ~40 lines to 7. A student who reads those 7 lines knows the order of the emoji’s construction without reading a single drawing command.

Phase 1 adds comments that were absent from Ethan’s original. These are not retrospective documentation — they are forward-facing teaching annotations. Each push/pop pair now has an inline comment explaining what state is being saved and why it must be restored:

function drawEyes() {
  let spiralSpeed = frameCount * 2;

  push(); // save transform state before rotating left eye
  translate(-60, -20);
  rotate(spiralSpeed);            // spins clockwise
  drawSpiralEye(50);
  pop();  // restore — coordinate system is back at (0,0) before the right eye starts

  push(); // save again for right eye
  translate(60, -10);
  rotate(-spiralSpeed * 1.9);    // counter-clockwise at 1.9× speed — Ethan's deliberate choice
  drawSpiralEye(80);
  pop();  // restore
}//end drawEyes

The comment on rotate(-spiralSpeed * 1.9) is particularly important: it names Ethan’s creative decision as deliberate. A student reading this understands that the 1.9 is not an accident or a typo — it is a choice that Ethan made to produce a specific visual effect. The refactor honours that choice even while reorganizing the code around it.

Three navigation changes were made so the pages form a coherent series:

1. Original sketch spark-bar — added a Phase 1 link alongside the existing Chat Log link. The spark-bar is now a phase navigator: Original → Chat Log → Phase 1.
2. Chatlog back-bar — added a Phase 1 link alongside the existing Original Sketch link. A reader who just finished the chatlog’s Phase 1 section can go directly to Phase 1 with one click.
3. Phase 1 spark-bar — links back to Original Sketch and Chat Log. Phase 1 has no “next” link because Phase 2 does not exist yet. When it does, it will be added here.

The convention: every page in the series links to every other page that exists. As phases are added, each page’s spark-bar grows by one link. The series is self-navigating.

The C.R.A.P. design framework — Contrast, Repetition, Alignment, Proximity — is a foundational tool at TNT for evaluating visual design decisions without guessing. Of the four principles, Repetition is the one most often violated unintentionally: a designer creates a consistent visual element in one place, then builds something new somewhere else without returning to the original as a reference. The result is two things that look similar but not identical — which reads as a mistake rather than a choice.

That is exactly what happened here. The Original Sketch page and the Phase 1 page both use a .spark-bar with .spark-links wrapping the navigation anchors, a 1.2rem gap between links, and margin-left: auto pushing the page label to the right. The chatlog’s navigation bar was built separately using a .back-bar class with different spacing (0.5rem gap vs 1.2rem), justify-content: space-between instead of margin-left: auto, and no .spark-links wrapper. The links looked amber and bold in both — but the spacing, grouping, and hover behavior did not match.

The fix was three-part:

1. CSS — Replaced the inline .back-bar rules with .spark-bar / .spark-links rules that exactly match the CSS in the showcase pages’ external stylesheets.
2. HTML structure — Changed <div class="back-bar"> to <div class="spark-bar"> and wrapped the navigation anchors in a <div class="spark-links">, giving them the same grouping and gap behaviour as the other pages.
3. Hover behaviour — Added color: #fff on hover to the links, which was present in the showcase pages but absent from the original chatlog styles.

The lesson Repetition teaches: a repeated element is only as strong as your commitment to repeating it precisely. “Similar” and “identical” are not the same thing in design. Similar creates visual noise; identical creates visual rhythm. When every page in a series uses the same navigation bar — same height, same colors, same spacing, same hover state — a user’s eyes learn to trust it. The nav becomes invisible infrastructure rather than something they have to read. That invisibility is the goal.

The key structural idea in Phase 2 is the settings panel: a block of named constants at the top of the file, organized by feature, that a student can tune without reading the drawing code. The drawing functions in Phase 1 had magic numbers embedded inside them. Phase 2 lifts those numbers out of their functions and gives them names and a home.

The organization matters as much as the naming. Constants are grouped under feature labels (// ── FACE ──, // ── EYES ──, etc.) so a student who wants to change the mouth can find all mouth constants in one place. The teaching payoff is immediate: change EYE_R_SPEED_MULT from 1.9 to 3.0 and watch the right eye spin dramatically faster. Change TONGUE_SPEED_X and TONGUE_DIST_X and observe the difference between how fast the tongue moves and how far it swings. These are experiments a student can run in 30 seconds — and they teach concepts that would take 30 minutes to explain in a lecture.

The BROWN_R/G/B constants deserve special mention. The dark-brown outline color (90, 50, 10) appears in four different functions: eyebrows, eye disc, mouth, and tongue. In Phase 1, that value was copied four times. In Phase 2, it is declared once as BROWN_R/G/B and referenced everywhere. This is the DRY (Don’t Repeat Yourself) principle made visible: one change to BROWN_G, and every outline color in the sketch responds simultaneously.

Color constants in Phase 2 use a _R/_G/_B suffix pattern: FACE_FILL_R = 255, FACE_FILL_G = 204, FACE_FILL_B = 0. This is intentionally verbose. Each constant is annotated with its Phase 3 equivalent:

// Phase 3: replace with fill(48, 100, 100) and stroke(30, 89, 35) in HSB mode
var FACE_FILL_R   = 255;  var FACE_FILL_G   = 204;  var FACE_FILL_B   =   0;
var FACE_STROKE_R = 204;  var FACE_STROKE_G = 136;  var FACE_STROKE_B =   0;

The _R/_G/_B naming is a deliberate signpost: a student doing Phase 3 can search the file for every constant ending in _R to find every color group that needs to change. Phase 3 will collapse each trio into a more readable HSB trio — FACE_FILL_R/G/B becomes FACE_HUE=48, FACE_SAT=100, FACE_BRI=100 — which is a significant reduction in line count alongside a dramatic improvement in readability.

The inline Phase 3 HSB values in the comments are not accidental. They give a student who reads Phase 2 a preview of what the values mean: 48° is yellow-orange, 100% saturation, 100% brightness — pure emoji yellow, stated explicitly. The comment is doing double duty: it documents the future change and it explains the current RGB values in human terms.

Positional constants are annotated with their Phase 5 equivalents:

// Phase 5: FACE_DIAM → width * 0.60 so the face fills 60% of any canvas width
var FACE_DIAM = 300;

// Phase 5: all eye positions and sizes → multiples of FACE_DIAM
var EYE_L_X = -60;   // will become -FACE_DIAM * 0.40
var EYE_L_SIZE = 50;  // will become FACE_DIAM * 0.167

These comments do something more than document the future: they teach the math behind scalability. A student who reads EYE_L_X = -60 and its annotation will become -FACE_DIAM * 0.40 can verify the ratio: 60 / 150 = 0.40 (150 is FACE_DIAM / 2 = the face radius). The constant encodes the ratio; the comment reveals it. Phase 5 does not invent new numbers — it makes the numbers that were always implicitly there explicit.

The eyebrow arc() calls retain hardcoded values in Phase 2:

arc(-60, -70, 60, 40, 200, 340); // left eyebrow  — Phase 5 will parametrize these values
arc(60, -50, 70, 40, 180, 310);  // right eyebrow — Phase 5 will parametrize these values

This was a deliberate decision, not an omission. Adding 12 new constants for eyebrow arcs would be technically correct but pedagogically noisy — six parameters per arc, two arcs, all of which are positional values that Phase 5 will derive from FACE_DIAM anyway. Naming them now as BROW_L_X = -60; BROW_L_Y = -70; etc. would give Phase 3 nothing to work with (eyebrows have no color constants that need HSB conversion) and would give Phase 5 a larger refactor rather than a smaller one.

The BROW_STROKE_W = 10 constant was extracted, because it is a single stylistic value a student might reasonably want to tune. The arc geometry was not, because it is a group of dependent positional values that only makes sense to parametrize all at once in Phase 5. This distinction — extract what a student would tune; leave what only makes sense as a group — is itself a design judgment worth discussing.

The entire Phase 3 color model change is activated by a single line in setup():

function setup() {
  createCanvas(500, 400);
  angleMode(DEGREES);
  colorMode(HSB, 360, 100, 100);  // ← the one new line; all colors now speak in hue/sat/bri
}

From this point, every fill(a, b, c) and stroke(a, b, c) call interprets a as hue (0–360°), b as saturation (0–100%), and c as brightness (0–100%). The argument count is identical to RGB; only their meaning changes.

The pedagogical value of a one-line change is enormous. A student who compares Phase 2 to Phase 3 can find this single addition in under ten seconds. Everything else that changes (the constants) is a consequence of this one decision. That cause-and-effect is visible at a glance.

Phase 2 had nine RGB triple declarations. Phase 3 collapses each triple into a compact, readable H/S/B group:

Black and white — previously expressed as fill(255) and stroke(0) — are now explicit: fill(0, 0, 100) (white: 0% saturation, 100% brightness) and stroke(0, 0, 0) (black: 0% brightness). Single-argument color calls behave unexpectedly in HSB mode; three-argument explicit forms remove all ambiguity and model the color correctly for students.

In Phase 2, face fill and face stroke had six independent constants that implied a relationship nobody had named. Phase 3 names it:

var STROKE_BRI_PCT  = 80;  // stroke brightness as % of face brightness
var FACE_STROKE_BRI = FACE_BRI * STROKE_BRI_PCT / 100;  // = 80

Any student who reads these two lines understands not just what the value is but why it is what it is. When the interactive slider changes STROKE_BRI_PCT to 50, the face stroke darkens regardless of face color. The relationship holds across all colors — which is the definition of a proportional rule, not a hardcoded value.

The interactive controls introduce a new architectural requirement: the p5 sketch must read externally controlled values every frame. The solution is window.phase3Settings — a shared bridge between two independent systems:

1. phase3EmojiFaceColorScript.js — defines window.phase3Settings immediately on load (before the DOM is ready, so p5 setup finds it on the first frame), wires the color picker and slider, keeps the HSB code readouts in sync. Never touches the canvas.
2. Inline p5 instance-mode sketch — reads window.phase3Settings inside drawFace() on every p.draw() call. Computes stroke brightness as Math.round(b * getStrokeBriPct() / 100). Never touches the DOM controls.

This separation means either piece can be modified independently. window.phase3Settings is the contract — a minimal API between two independent systems. It is also a concrete example of the design principle students will encounter in every major framework they ever use.

Choosing <input type="color"> over a custom hue slider was deliberate. A hue slider locks saturation and brightness at 100% — the face would always be vivid. The native color picker allows pastels, desaturated tones, and near-blacks. When a student picks pale lavender and sees fill(270, 40, 90) in the readout, they understand from the numbers that it is a low-saturation, high-brightness purple — because they just chose it.

The controls script also implements the inverse HSB → hex conversion to synchronise the picker’s initial displayed color with the starting FACE_HUE=48, FACE_SAT=100, FACE_BRI=100 constants. This ensures the picker opens showing the emoji’s original yellow rather than defaulting to black.