/* Chris, 2026-09-09: real phones (Galaxy S8+, iPhone SE, Galaxy Z Fold 5) were wrapping "LH Fingers"/"RH Fingers" and quality-row captions like "1-♭3-5-♭7" even at the narrow-width font sizes already tuned and Playwright-verified for those exact device widths (see the #wpl-scale-view-row / #wpl-quality-row2 breakpoint comments below). That mismatch (fits in headless Chromium, wraps on the real device) is the signature of mobile browsers' automatic "font boosting" / text-size-adjust, which silently inflates small text in narrow columns to keep it "readable" -- it only kicks in on real devices, so no desktop or emulator test catches it. Turning it off makes every font- size on this page render at exactly the px value authored, on every device, which is what all the hand-tuned breakpoints below already assume. */ #wpl-wrapper { -webkit-text-size-adjust: 100%; text-size-adjust: 100%; } #wpl-wrapper * { -webkit-tap-highlight-color: transparent; box-sizing: border-box; -webkit-text-size-adjust: 100%; text-size-adjust: 100%; } #wpl-wrapper button { font-family: inherit; } body { box-sizing: border-box; background: #f2efe9; margin: 0; padding: 14px 16px; } #wpl-wrapper { --wpl-cream: #f2efe9; --wpl-card: #fffdf8; --wpl-ink: #2a2f34; --wpl-muted: #8a8b82; --wpl-tan: #efe9e0; --wpl-tan-hover: #e3dcd0; --wpl-tan-text: #55565a; /* Chris, 2026-09-12 (round B pick 6B): deep teal for every selected button, Play, the tempo slider and the step circles, so red and blue only ever mean right hand / left hand. The old brand blue #14A3C7 sat right next to the left hand's sky blue (#38BDF8); deep teal is the same family as the logo, but darker and greener. */ --wpl-accent: #0F766E; --wpl-accent-dark: #0B5F58; --wpl-line: #e5ded2; --wpl-prog-bg: #e2f5fa; --wpl-prog-hover: #cfeaf2; --wpl-prog-border: #cdeaf2; /* Practice hub tile tints (2026-09-09, Chris: "it's so bland. a little color could be nice") -- soft pastels in the same low- saturation family as --wpl-prog-bg above, so the grid gets variety without clashing with the cream/tan editorial look. Reused via nth-child on .practice-tile, 4-color cycle. */ --wpl-tile-teal-bg: #e2f5fa; --wpl-tile-teal-border: #cdeaf2; --wpl-tile-peach-bg: #faece2; --wpl-tile-peach-border: #f2dcc9; --wpl-tile-sage-bg: #eaf3e2; --wpl-tile-sage-border: #dbe9cb; --wpl-tile-gold-bg: #faf2df; --wpl-tile-gold-border: #f0e2bf; --wpl-lift-shadow: 0 4px 10px rgba(42,38,32,0.10); --wpl-active-shadow: 0 3px 10px rgba(42,38,32,0.16); /* Chris, 2026-09-12 (round B pick 1C): DM Sans everywhere (titles stay Fraunces), so the app looks the same on every device instead of each one drawing its own system font. Loaded in index.html. */ font-family: 'DM Sans', -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, sans-serif; /* DM Sans's default ("normal") line spacing is ~1.30x its size, taller than the ~1.19x of the San Francisco system font the layout was tuned on -- left at normal, every text line grew ~1px and the card grew 5-9px (measured 2026-09-12). Pinning the old spacing keeps every height exactly as it was. (Buttons keep their own line heights.) */ line-height: 1.193; box-sizing: border-box; width: 100%; max-width: 1100px; margin: 0 auto; padding: 16px 32px 16px; background: var(--wpl-card); border-radius: 20px; box-shadow: 0 4px 24px rgba(60,50,20,0.08); color: var(--wpl-ink); position: relative; } /* ---------- Header ---------- */ .wpl-header { text-align: center; margin-bottom: 8px; } .wpl-eyebrow { font-size: 11px; font-weight: 700; color: var(--wpl-muted); text-transform: uppercase; letter-spacing: 1.6px; margin-bottom: 6px; } .wpl-title { font-family: 'Fraunces', Georgia, 'Times New Roman', serif; font-size: 32px; font-weight: 600; color: var(--wpl-ink); line-height: 1.15; } .wpl-subtitle { font-size: 14px; font-weight: 500; color: var(--wpl-muted); margin-top: 6px; } /* A one-line "pick a key, then a chord type" hint briefly lived here, 2026-09-07, to orient a cold first-time visitor -- cut again the same day once Chris set a hard rule: "the shell can't get bigger. it was the perfect size on my phone before." Every extra line has a real height cost, so the fix for "people don't understand the flow" has to come from the existing elements (step badges below, tab bar) rather than adding new ones. */ /* Overlaid on the card (position:absolute), not in normal flow — this is deliberate so the countdown never affects #wpl-wrapper's height or pushes the header/tabs/piano down (Chris: "doesn't effect the size, but sits in a visually good place"). #wpl-wrapper is given position:relative (see top of this file) so this positions relative to the card, not the page. */ .wpl-trial-note { display: none; position: absolute; top: 14px; right: 16px; z-index: 3; text-align: center; padding: 6px 12px; background: #e2f5fa; border: 1px solid #cdeaf2; border-radius: 10px; line-height: 1.3; } .wpl-trial-label { display: block; font-size: 10px; font-weight: 700; text-transform: uppercase; letter-spacing: 0.3px; color: var(--wpl-tan-text); } .wpl-trial-clock { display: block; font-size: 13px; font-weight: 800; color: var(--wpl-accent-dark); font-variant-numeric: tabular-nums; } /* Default (above the 520px breakpoint) reservation — covers the common embed widths between phone and the 1100px desktop max-width, where the card is narrower than the eyebrow text's clear margin needs. */ /* ---------- Top tab bar ---------- */ /* Chris, 2026-09-07: people he showed the app to cold "didn't notice the top tabs either" -- a plain text label + thin underline apparently reads as inert page furniture, not as "3 different tools live here," next to the same large colored buttons that were already winning the attention fight against the numbered step labels. Chris's own reference: real manila folder tabs -- a raised, filled shape that visibly sits "in front of" and connects to whatever's open beneath it, with the other (unopened) folders receding behind the divider line. Implemented as a classic connected-tab shape rather than a literal folder's single-side notch (that notch is a physical filing detail, not a web-tab convention): each tab gets its own rounded-top card filled with the resting tan color; the active one switches to the same background as the content card below it and its bottom edge overlaps .wpl-tabbar's divider line (negative margin-bottom, exactly the line's own thickness) so the line visually disappears under it -- the "this folder is open and connected to what you're looking at" effect. Round 2, Chris (screenshot): "the buttons are rounded, and the tabs are square. plus the way the tabs are connected looks weird with that gray line." Bumped radius 8px->12px to match .prog-tab's corner roundness -- the app's other most-rounded element -- so the tabs read as clearly rounded instead of near-square. Tried a shadow-only active state next (no border) -- Round 3, Chris (screenshot): "it sinks down and the lower shadow make it look separated from the lower body. it needs to be a part of the body." Tried giving every tab the same visible border next -- fixed the float, but then (Chris, describing the mental model precisely): "the body will have a line above it that's under the tabs. when a tab is clicked, the upper border will wrap over and around the clicked then continue until it reaches the other side." That's the actual spec: ONE continuous horizontal line (.wpl-tabbar's own border-bottom, edge to edge) is the top of the body and runs underneath every unclicked tab uninterrupted; only the active tab's own border detours up and over it -- left side up, across the top, down the right side -- before the line resumes. So only .active gets a real border (left/top/right); unclicked tabs are borderless fills that simply sit above the line. The active tab's own ::after strip erases the exact segment of that line running under it (rather than a margin-bottom trick, which previously shifted its whole box down under align-items:flex-end and misaligned its top with the other tabs -- Chris: "the top of the clicked tab is lower than the unclicked tabs"). Padding-top differs by exactly the border's own width (6.5px active vs 8px unclicked) so both states still resolve to the same total box height -- no jump when a different tab becomes active. Chris: "don't let the unclicked tabs touch. should be 1px space between them." Small explicit gap between every tab so the continuous line still shows through as a thread connecting them, rather than one solid tan bar. */ .wpl-tabbar { display: flex; align-items: flex-end; gap: 1px; border-bottom: 1.5px solid var(--wpl-line); margin-bottom: 10px; } .wpl-tab { position: relative; /* Border is reserved at full width on EVERY tab, all the time -- transparent when inactive, colored in when active. Chris (zoomed screenshot, comparing an active vs. inactive shot of the same tab): "the tab text moves when it's clicked... the border should move around the tab to create the movement, not move the tab." The old rule gave only .active a border at all (none -> 1.5px on three sides). Since flex:1 1 0 divides the row's width among the tabs by their flex-basis, adding/removing that 1.5px border changed each tab's own box-sizing:border-box outer width slightly as it toggled -- so the active tab's box (and its centered label) visibly shifted sideways instead of staying put. Reserving the same border on every tab at all times means toggling .active only flips border-color and background; the box a tab occupies, and where its text centers within it, never changes. */ border: 1.5px solid transparent; border-bottom: none; background: var(--wpl-tan); border-radius: 12px 12px 0 0; cursor: pointer; padding: 8px 16px 10px; /* Fixed height, not just matching padding, so the active tab's top lines up with the others pixel-for-pixel. A border-width-based padding offset (padding-top reduced by the border's own 1.5px) looked right in theory, but Chris still saw "the clicked tab's top is shorter" -- Chromium was rendering the 1.5px border as a rounded 1px (computed style confirmed it), so the offset was wrong by the difference. Height is an explicit box-sizing:border- box value instead (see #wpl-wrapper's global border-box reset at the top of this file) -- immune to how any given browser rounds a fractional border, since the border simply eats into the content area rather than changing the box's own total height. */ height: 34px; font-size: 14px; font-weight: 700; color: var(--wpl-tan-text); letter-spacing: 0.2px; transition: color 0.15s ease, background 0.15s ease; display: flex; /* flex-end, not center: pins the label a fixed distance (this padding's own bottom value) above the tab's bottom edge. Chris (zoomed screenshot): "it looks like the clicked tab text moves up 1px. it can't move at all." The active tab is 1px taller on purpose (see .active below); with vertical centering, that extra height moves the box's own midpoint, so the centered label rides up with it. Anchoring to the bottom instead means the extra height lands as invisible padding stacked above the label -- the label's own position never changes, since the tab's bottom edge is itself already pinned by .wpl-tabbar's align-items:flex-end regardless of which tab is active. */ align-items: flex-end; justify-content: center; gap: 6px; /* Unlike .prog-tab/.step-btn/.key-tab (the sub-rows within a panel), this row never got flex:1 -- with exactly 4 tabs today the fixed padding + font sizes below happen to fit every breakpoint, but a future 5th tab would just overflow or wrap the bar (adding height) instead of sharing the row width like every other button row in the app already does. flex:1 1 0 + min-width:0 makes this row self- adjusting the same way, so adding a tab is a markup-only change here too, not a new round of breakpoint tuning. white-space:nowrap keeps a label + its "Soon" pill on one line instead of wrapping inside the tab and growing the bar's height once the button gets narrower with more tabs sharing the row. */ flex: 1 1 0; min-width: 0; white-space: nowrap; } .wpl-tab.active { /* 1px taller than the unclicked tabs (Chris: "that will help make it stand out more"), added at the TOP only -- align-items: flex-end on .wpl-tabbar keeps every tab's bottom pinned to the same line regardless of height, so a taller active tab pokes up above its neighbors instead of also pushing its bottom (and the body-fusion seam) out of place. */ height: 35px; border-color: var(--wpl-line); background: var(--wpl-card); color: var(--wpl-accent-dark); } /* Erases the .wpl-tabbar divider line directly under the active tab -- the "line wraps over and around the clicked tab" effect -- without touching the tab's own box model. A small absolutely-positioned strip, sized to the tab's own width and colored to match the body, sits just below it and paints over that one segment of the line. */ .wpl-tab.active::after { content: ""; position: absolute; left: 0; right: 0; bottom: -1.5px; height: 1.5px; background: var(--wpl-card); } .wpl-tab-soon { font-size: 9px; font-weight: 800; text-transform: uppercase; letter-spacing: 0.5px; color: var(--wpl-muted); background: var(--wpl-tan); border-radius: 5px; padding: 2px 5px; } .wpl-tab.active .wpl-tab-soon { color: var(--wpl-accent-dark); background: #e6f6fb; } /* ---------- Shared instrument block (key selector + readout + piano) — stays in the same position across every tab; only .wpl-panel below it swaps content. ---------- */ .wpl-instrument { margin-bottom: 10px; } /* Chris (desktop only): "there is not enough space above #1 and below the tabs. move #1 and everything in this image down a few pixels so everything is closer to #2. but don't move #2." #1 sits right below .wpl-tabbar's own margin-bottom, and #2 sits right below .wpl-instrument's -- moving #1 down without moving #2 means growing the first gap and shrinking the second by the same amount, so the total space the whole instrument block occupies (and therefore where #2 lands) never changes, only where #1 sits within it. */ @media (min-width: 521px) { .wpl-tabbar { margin-bottom: 14px; } .wpl-instrument { margin-bottom: 6px; } } /* ---------- Section labels ---------- */ /* Chris, 2026-09-07: people he sent the app to cold "didn't really understand the flow... their eyes were naturally drawn to the big blue buttons instead of working from the top down." These labels are the only thing telling someone there IS a top-down order (1, then 2, then 3), but at 11px muted gray they lost every visual fight against the large colored buttons directly below them. First pass enlarged the label text itself (11px->13px) and its margin (5px->7px) too, on top of adding the circle -- but that grew the shell's total height, and Chris set a hard rule right after: "the shell can't get bigger. it was the perfect size on my phone before." So font-size/margin-bottom here are back to their exact original values (measured: at these values the circle adds zero net height to the row, since a small circle fits inside the existing line box). All the emphasis now comes from the circle alone -- .step-num, sized to stay within that existing row height. Circle color: teal (var(--wpl-accent)) was the same color as an already-selected/active button directly below it, so the badge visually blended into the button row instead of standing apart from it -- Chris: "should the 1,2,3 buttons be in red?" Switched to the app's existing right-hand/chord-tone red (#f87171) rather than inventing a new color, since it's already established elsewhere in this same UI as "a note of emphasis," just applied to step numbers instead of piano keys -- and unlike teal, it never appears on any button in this row, so it can't blend in the same way. */ .section-label { font-size: 11px; font-weight: 700; color: var(--wpl-muted); text-transform: uppercase; letter-spacing: 0.6px; margin-bottom: 5px; display: flex; align-items: center; gap: 6px; } /* Chris, 2026-09-12: the 1, 2, 3 step circles were removed from every section label ("maybe i don't need those 1,2,3 circles now"). The labels keep their exact size, so the card doesn't change. Their SVG markup and styles live in git history (checkpoint bcb1b12) if they're ever wanted back. On desktop the 14px circle was what set the row's height (the text alone is about 13px), so the label keeps a 14px minimum there. */ @media (min-width: 521px) { .section-label { min-height: 14px; } } /* ---------- Shared button feel: progression tabs, key tabs, step buttons all hover/select the same way — a quiet lift, no colored ring. Progression tabs get their own light-blue rest color (matching the reference); key tabs and step buttons share the tan. ---------- */ .prog-tab, .key-tab, .step-btn { border: 1.5px solid var(--wpl-line); cursor: pointer; text-align: center; color: var(--wpl-ink); min-width: 0; transition: background 0.15s ease, border-color 0.15s ease, box-shadow 0.15s ease, transform 0.15s ease, color 0.15s ease; } .prog-tab.active, .key-tab.active, .step-btn.active { background: var(--wpl-accent); color: #fff; border-color: var(--wpl-accent); box-shadow: var(--wpl-active-shadow); transform: translateY(0); /* Chris, 2026-09-06, from a frame-by-frame screen recording: "the blue buttons taking 9 frames [0.15s] to fade in... gives the appearance of being late when the piano lights up completely in 1 or 2 frames." The OLD button fading back to tan still uses the shared 0.15s transition above (the plain, non-.active rule) -- Chris confirmed that half "looks good" (the previous selection melting away). Only fading IN was the problem: CSS applies whichever transition value is declared on the state a property is arriving at, so redeclaring transition here without background makes a newly-active button's fill snap on immediately instead of easing in -- matching how its own text color and the piano's own highlight already snap with no transition at all (see .prog-tab.active .num etc. above and light() in piano-engine.js). border-color/box-shadow/transform keep easing at 0.15s -- only the background fill itself was the one reading as late. */ transition: border-color 0.15s ease, box-shadow 0.15s ease, transform 0.15s ease; } /* ---------- Progression tabs ---------- */ .prog-tab { flex: 1; border-radius: 12px; padding: 14px 6px; background: var(--wpl-prog-bg); border-color: var(--wpl-prog-border); /* center (not flex-start): all 5 progression names are now single words (Foundation/Smooth/Soft/Big/Full), so every button's .num + .name block is the same height and centers identically — no more risk of a 2-line-wrapped name pushing one button's .num out of line with the rest. If a future name gets long enough to wrap again, revisit this (see git history 2026-08-30 for the prior flex-start fix and why it was needed then). */ display: flex; flex-direction: column; justify-content: center; min-height: 78px; } /* Chris, 2026-09-06, from a screen recording: "on the bottom row it's correct, the button text changes from white to black right when you click it... but on the top row... the black text slowly fades to white making it look like the button is very slightly delayed." .step-btn.active already sets its own .n/.l colors explicitly further below, which is why it snaps instantly -- .prog-tab .num/.name never had that, so they were only ever inheriting .prog-tab.active's own `color: #fff`, which fades over the shared 0.15s color transition above. Explicit color here (like .step-btn's) makes it snap the same way, since neither .num nor .name declares its own transition. */ .prog-tab.active .num { color: #fff; } .prog-tab.active .name { color: rgba(255,255,255,0.85); } .prog-tab .num { font-weight: 800; font-size: 22px; line-height: 1.2; } /* margin-top: 4px matches the vertical gap every other "label + caption" pairing in the app uses (.step-btn's flex gap:4px, both for the Progressions step-row and the Chords position row) — Chris, 2026-09-02: "make it all equal" after comparing this row's spacing to the step-row's and finding this one tighter (was 2px here, 1px on the Chords quality row's override below — now both 4px, one shared standard). */ .prog-tab .name { font-size: 12px; font-weight: 600; opacity: 0.9; margin-top: 4px; } /* ---------- Key tabs ---------- */ .key-tab { flex: 1; border-radius: 8px; padding: 9px 0; font-weight: 600; font-size: 13px; background: var(--wpl-tan); color: var(--wpl-tan-text); white-space: nowrap; /* Fixed (px, not ratio) line-height so box height depends only on padding, never on font-size — .key-tab-wide sets a smaller font-size for 2-letter labels (Db/Eb/F#/Ab/Bb) and, since it never redeclares line-height, inherits this exact px value, keeping its row the same height as the 1-letter keys next to it. */ line-height: 15px; /* Chris, 2026-09-06: "the choose a key buttons need to have the black text change to white immediately when clicking a new button like the bottom 2 rows do, instead of fading into white." .step-btn/.prog-tab snap instantly because their visible text lives in child .n/.l/.num/ .name spans that never declare their own transition — explicit color set directly on those children (see .step-btn.active .n etc. above) just switches with no animation. .key-tab has no such child span; its label is a plain text node directly inside .key-tab itself, so it was inheriting the shared .prog-tab/.key-tab/.step-btn color transition below and fading over 0.15s instead of snapping. Redeclare the transition here without color (background/border/shadow/transform still ease) to opt this element back out of the color fade. */ transition: background 0.15s ease, border-color 0.15s ease, box-shadow 0.15s ease, transform 0.15s ease; } .key-tab.locked { opacity: 0.55; } /* ---------- Step buttons ---------- */ .step-btn { flex: 1; border-radius: 8px; padding: 9px 4px 7px; background: var(--wpl-tan); display: flex; flex-direction: column; align-items: center; justify-content: center; gap: 4px; min-height: 60px; } .step-btn.active .n { color: #fff; } .step-btn.active .l { color: rgba(255,255,255,0.85); } /* RH/LH-colored hand initials on the Scales "Choose a View" buttons (see handColoredLabel/VIEW_HAND_CLASS in ui.js). Plain colored text -- two earlier contrast attempts (a white text-shadow halo, then a solid white badge) both read as visual smudges once Chris saw them rendered. Chris, 2026-09-06: "keep the red and blue colors as is, but when it's clicked blue, then maybe make them a whiter red and whiter blue, that will make it pop more against a blue background" -- the .active overrides below lighten each hue only while its own button is the selected one (background becomes --wpl-accent teal), same idea as .n/.l above but a separate rule since these spans need their own hue, not white. */ .wpl-hand-rh { color: #f87171; } .wpl-hand-lh { color: #38bdf8; } .step-btn.active .wpl-hand-rh { color: #fecaca; } .step-btn.active .wpl-hand-lh { color: #bfdbfe; } /* Chris, 2026-09-06: "the buttons should pulse like the piano notes do" + "does the top row [Chords' Choose a Position] need the same highlight" as the bottom row already had -- .prog-tab never had a .playing rule at all (only .step-btn did), even though ui.js already toggles "playing" onto #wpl-position-tabs2's .prog-tab buttons every step (Chords tab) same as it does for .step-btn (Progressions' chord row); it was just silently doing nothing. Added .prog-tab.playing here so Chords' step highlight works the same way Progressions' already did, plus an animation so each new step's ring blooms in and settles rather than just snapping on -- same idea as the piano keys' own played-note flash (flashPlayedKey in piano-engine.js), so a step changing on the buttons reads as part of the same "this just played" language as the keys lighting up, not a separate effect. ui.js removes then re-adds the class on a fresh element each step (not the same node twice in a row in the common case), which is what lets this animation restart cleanly without needing piano-engine.js's reflow trick. */ .step-btn.playing, .prog-tab.playing { border-color: #f59e0b; box-shadow: 0 0 0 1px rgba(245,158,11,0.35); animation: wpl-step-pulse 1s ease-out; } /* Chris, 2026-09-06: "the gold ring is still too big. reduce it by another 50%." Resting ring down from 2px to 1px, pulse peak from 3px to 1.5px -- same proportions as before, just half the spread. */ @keyframes wpl-step-pulse { from { box-shadow: 0 0 0 1.5px rgba(245,158,11,0.6); } to { box-shadow: 0 0 0 1px rgba(245,158,11,0.35); } } /* Chris, 2026-09-02, follow-up (after reviewing Chords v2): "the Major/Minor titles on the OLD Chords tab's bottom row look bigger/bolder than Chords v2's... make that change on chords2 to match" + "make the progressions tab lower row title match... so the shell fonts are the same size" + later, after a scoped fix still left Practice's row out: "why do I keep having to tell you to resize text? they should be the same on all the tabs... unless the text on a button is too long." So this is the BASE rule now (not a per-ID override) — every consumer of plain .step-btn .n automatically gets the same weight/size with no per-tab patching needed: Progressions' #wpl-step-row, Chords v2's #wpl-quality-row2, AND Practice's #wpl-scale-hands-row/#wpl-scale-direction-row/ #wpl-scale-octaves-row (Right/Both, Up/Down/Up-Dn, 1-2-3 8ve) all share this one rule. Matches the OLD Chords tab's #wpl-chord-quality-tabs .prog-tab .num sizing exactly (800/16px desktop, see that rule further down) — that's the one row this whole family is modeled on. Captions (.l) are untouched; only rows that use them (step-row, quality-row2) are affected, at 12px as before. */ .step-btn .n { font-weight: 800; color: var(--wpl-ink); font-size: 16px; line-height: 1.2; } /* Chris, 2026-09-04: top-row subtitle (.prog-tab .name) and bottom-row subtitle (.step-btn .l) read as two different colors -- .name has no color of its own (inherits --wpl-ink at 0.9 opacity from the shared .prog-tab/.key-tab/.step-btn rule above), .l was hardcoded to --wpl-muted (gray). Matching .l to the same treatment (drop the hardcoded color, add the same 0.9 opacity) makes every subtitle the same color everywhere .step-btn .l is used -- Progressions' step-row, Chords v2's quality-row2, Scales' view-row. */ .step-btn .l { font-size: 12px; opacity: 0.9; line-height: 1.2; } /* Full label ("Right Hand", "Left Hand") vs short label ("RH", "LH") -- Chris, 2026-09-04: short only on mobile, full on desktop. Short is the default/safe-everywhere text; full switches on at each consumer's own min-width query below. (The Choose a Scale row's title used to need this too, to abbreviate "Pentatonic" to "Pent" -- Chris, 2026-09-05, moved "Pentatonic" down to the button's subtitle instead, always spelled out, so that row no longer uses these classes at all -- see .wpl-name-wide below.) */ .wpl-lbl-full { display: none; } .wpl-lbl-short { display: inline; } /* Scale readout ("C", "Cm", ...): spelled-out Major/Minor only above the readout box's own mobile/desktop split (140px box starts here, same breakpoint the .wpl-readout-row mobile override below uses) -- Chris, 2026-09-05: "on desktop... change the text back from C to C Major and Cm to C Minor." Below this width the compact "C"/"Cm" stays (matches the smaller 112px/88px boxes at narrower widths). */ @media (min-width: 521px) { #wpl-chord-name .wpl-lbl-full { display: inline; } #wpl-chord-name .wpl-lbl-short { display: none; } /* Chris, 2026-09-10: "you changed it on desktop too. i didn't want that. just mobile." -- same full/short split as #wpl-chord-name above, so desktop (plenty of room) keeps "RH Fingers"/"LH Fingers" spelled out (SCALE_VIEWS' nFull in ui.js) and only mobile drops to the short "RH"/"LH" (nShort), which is what .wpl-lbl-short/.wpl- lbl-full already default to below this width. */ #wpl-scale-view-row .wpl-lbl-full { display: inline; } #wpl-scale-view-row .wpl-lbl-short { display: none; } /* Practice's Choose hands row (2026-09-12): "Left Hand Octave" / "Left Hand Top Note" / "Right Hand" on desktop, "LH Oct" / "LH Top" / "RH" on mobile, same split. */ .wpl-practice-hands-row .wpl-lbl-full { display: inline; } .wpl-practice-hands-row .wpl-lbl-short { display: none; } } /* On-key note/number labels: same 11px/10px (white/black) at every width until now -- Chris, 2026-09-05: "on desktop only, can you make the note names/number names any bigger?" Base size (mobile/tablet keys are too narrow for anything bigger) stays the original inline-style values; only bumped from 521px up, same "desktop" threshold as the readout box above. */ .key-label-white { font-size: 11px; } .key-label-black { font-size: 10px; } @media (min-width: 521px) { .key-label-white { font-size: 15px; } .key-label-black { font-size: 13px; } } /* Choose a Scale row's title (.num) is always "Major"/"Minor" now -- Chris, 2026-09-05, reordering the row into 2 groups of 3 -- so it no longer needs its own downscoped size like the old "Pentatonic" title did; it just uses the same .prog-tab .num sizing as every other row (12px/14px/22px across the same 340/520 breakpoints). "Pentatonic" moved down to be the subtitle (.name) instead, always spelled out rather than abbreviated to "Pent". .wpl-name-wide still flags just those two buttons' subtitles (see SCALE_TYPES "wide" flag in ui.js) for the 521-619px tier below, where "Scale"/"Blues" keep the row's normal, larger .name size and only "Pentatonic" needs its own smaller size to avoid wrapping. Below 521px, though, Chris, 2026-09-05 (mobile only): "make Pentatonic bigger... then reduce the subtitles Scale and Blues to be the same size as Pentatonic" -- so the two mobile tiers (see #wpl-scale-type-row .prog-tab .name further down, at the 341-520px and <=340px breakpoints) drop the .wpl-name-wide restriction and size ALL THREE subtitles (Scale/Pentatonic/Blues) the same, at the largest size that still fits "Pentatonic" -- the longest of the three -- at that tier's narrowest real device width (Playwright-verified: candidate sizes tested against the button's actual measured width, with wrap/overflow checked directly via scrollHeight and scrollWidth, at real phone widths 320-520px rather than the full theoretical breakpoint range, since e.g. 341-359px has no real device and its own tighter "pinch" from the row's padding/gap shrinking right at that boundary). 9px still covers 521-619px; 620px+ is wide enough for the row's own normal .name size (12px) with real margin, so no override is needed there. */ @media (min-width: 521px) and (max-width: 619px) { #wpl-scale-type-row .prog-tab .name.wpl-name-wide { font-size: 9px; } } /* "Right Hand"/"Left Hand" became "RH Fingers"/"LH Fingers" (Chris, 2026-09-04), shown at every width (nFull===nShort for this row again -- "Finger Patterns" briefly lived here on 2026-09-05 but Chris caught it: "no! not 'finger patterns' on the bottom row! only the scale / view part above the piano," so this row is back to "RH Fingers"/"LH Fingers", see SCALE_VIEWS in ui.js) -- so unlike "Note"/"Number", this row's text can't just avoid wrapping by getting shorter below some breakpoint on its own; the fix here is shrinking the row's own .step-btn .n font at the widths where it otherwise wraps. Chris, 2026-09-05 (mobile only): "make the titles bigger, but don't let LH and RH fingers wrap... make the bottom subtitles the same text size as the top row subtitles." The old flat 8px/7px for all of <=520px actually still wrapped "RH Fingers"/"LH Fingers" at real 320px-wide phones (Playwright-confirmed: scrollHeight jumps to a 2nd line at 8px there), so the <=520px tier is now split into four narrower bands, each the largest .n size that keeps "RH Fingers" on one line at that band's narrowest *real* device width (forced white-space:nowrap + measured scrollWidth against the button's actual width, tested across every common phone width 320-520px, not the theoretical breakpoint continuum): 7px for <=340px (real floor: 320px); 8px for 341-374px (real floor: 360px); 8.25px for 375-411px (real floor: 375px); 9px for 412-520px (real floor: 412px). .l (the subtitle) is set to match the Choose a Scale row's own new unified subtitle size at the same two breakpoints it uses (7.75px <=340px, 8px 341-520px) per Chris's "same as the top row" instruction, rather than following the .n tiers above -- both sets of numbers were verified together (all six buttons' .n and .l, at every real width 320-520px) with zero wraps or overflow. 10px/9px still covers 521-589px; 12px/10px still covers 590-899px; 900px+ keeps the row's standard, unscoped 16px/12px (already verified to fit there). */ /* Chris, 2026-09-10: "scales RH part is still wrapping" -- these tiers were tuned to the thinnest margin that measured as safe (as little as ~1-2px of clearance per the notes above), and that margin isn't holding up on Chris's real phones (rendering differences the headless measurements didn't catch). Dropping by a real, deliberate amount at every tier below instead of shaving another fraction of a px, so there's actual room to spare rather than a hairline fit. */ /* .n (the title) has no per-tier override here anymore -- Chris, 2026-09-10: "make the bottom row of buttons just say RH and LH... increase the text size back to a good size where 'number' is the longest one." Dropping "Fingers" (see SCALE_VIEWS in ui.js) makes "Number" (6 letters) this row's longest label instead of "RH Fingers"/"LH Fingers" (10), so the row's normal shared .step-btn .n size (11px mobile / 9px <=340px / 16px desktop) now has real room to spare at every width -- no narrow-width shrinking needed. Only .l (the subtitle, "2 Octaves" etc) still needs its own smaller tiers. */ /* Chris, 2026-09-10: "make it 1px smaller on mobile. number is end to end" -- 1px below whatever this row's .n would otherwise inherit from the shared .step-btn .n mobile sizing (9px <=340px, 11px 341-520px), now that "Number" is the row's longest mobile label. */ @media (max-width: 340px) { #wpl-scale-view-row .step-btn .n { font-size: 8px; } #wpl-scale-view-row .step-btn .l { font-size: 7.75px; } } @media (min-width: 341px) and (max-width: 520px) { #wpl-scale-view-row .step-btn .n { font-size: 10px; } } /* Chris, 2026-09-10: "the 3 other tabs are still wrapping the bottom row" -- Chords v2's #wpl-quality-row2 has the exact same problem as #wpl-scale-view-row above (a long caption -- "1-♭3-5-♭7" for Min7 -- wrapping to a 2nd line), but it only ever got a font-size fix at the <=340px tier (see the "extra-narrow safety net" block further down). 341-520px silently fell back to the shared 10px .step-btn .l, which wraps "1-♭3-5-♭7" well before 340px, let alone up to 520 -- exactly the gap that let this keep happening on real 360-412px phones (Galaxy S8+, iPhone SE, Galaxy Z Fold 5) even after every other narrow-width fix. Filling in the same three tiers #wpl-scale-view-row already uses, at the same 8px value that row's own testing already verified fits a caption this length at these widths. */ @media (min-width: 341px) and (max-width: 374px) { #wpl-scale-view-row .step-btn .l { font-size: 8px; } #wpl-quality-row2 .step-btn .l { font-size: 8px; } } @media (min-width: 375px) and (max-width: 411px) { #wpl-scale-view-row .step-btn .l { font-size: 8px; } #wpl-quality-row2 .step-btn .l { font-size: 8px; } } @media (min-width: 412px) and (max-width: 520px) { #wpl-scale-view-row .step-btn .l { font-size: 8px; } #wpl-quality-row2 .step-btn .l { font-size: 8px; } } @media (min-width: 521px) and (max-width: 589px) { #wpl-scale-view-row .step-btn .l { font-size: 9px; } } @media (min-width: 590px) and (max-width: 899px) { #wpl-scale-view-row .step-btn .l { font-size: 10px; } } /* Choose a View row: every button now has both a title and a subtitle (Note/Names, Scale/Degrees, RH/1 Octave, etc, 2026-09-04) so plain .step-btn centering (shared rule above) already puts every title on the same plane -- no per-row override needed, same as Progressions' own step-row. (Earlier attempt used flex-start to compensate for 2 of the 6 buttons having no subtitle; not needed once the labels were split.) */ /* ---------- Chord / number readout ---------- */ /* Two equal-width columns spanning the row edge to edge (no gap, no side padding), each value centered within its own half -- Chris, 2026-09-07: the old approach (both boxes a fixed width just big enough for "Root High"/"Root Low", grouped near the middle via justify-content:center + gap) left "D♭m Pentatonic" too little room and it silently wrapped to a hidden 2nd line on phones. Rather than keep shrinking text to fit a narrow box, each column now stretches "from the center of the screen to the end of the screen on both sides" (Chris) at every width, desktop included, and the same row is shared by all three tabs (Chord/Number, Position/Number, Scale/View) so this applies everywhere uniformly. No horizontal padding here means the columns reach the exact same left/right edges as the piano frame below. (A hand-with-numbered-fingers icon briefly lived in this row too, 2026-09-05 -- removed again: even capped at a modest max size it was still taller than the readout boxes on every tier, which grew the row's own height and visibly pushed the piano down every time a Fingers view was selected. Chris: "your hand is too big which pushed that row down which made the entire shell move down... just delete the hand." A real PNG image, sized to fit inside the existing box height instead of growing it, is the likely next approach if he supplies one -- flagged here so the reasoning isn't lost if it comes back.) */ /* Chris (zoomed screenshot, desktop): "i was wrong about moving the scale / view out so much, it needs to be moved back in toward the middle. close enough that the text doesn't wrap." Each side used to be a fixed width:50% of the whole instrument card (set in index.html inline, up to 1100px wide -- see #wpl-wrapper's max-width), so "Scale" and "View" centered themselves at each half's own midpoint -- roughly a quarter of the way in from either edge, with a wide gap of empty space between them. First fix dropped the fixed width entirely so each side would shrink-wrap its own label -- but a shrink-wrapped, centered-as-a-pair layout re-centers on every render, so a short value ("D♭m") sits in a different spot than a long one ("D♭m Pentatonic") even though it's the same on-screen column -- Chris: "they're moving in and out depending on the text length. they need to be fixed at the closest position where the longest text doesn't wrap" (both mobile and desktop). Fixed here instead: each column gets an explicit width (see the breakpoint overrides below), sized to the single widest string this app can ever put in EITHER column -- measured directly via Playwright by rendering every real chord name (transposed through all 12 keys), position name, scale name, and view label into the actual #wpl-chord-name element at each font-size tier and taking the max scrollWidth, then padded a bit further for safety margin against font differences on Chris's own device (see this file's git history/PR notes for the measured numbers). Text still centers within that fixed box via text-align:center (in index.html), so a short value just sits centered in the same unmoving box instead of shrinking the box around itself. */ .wpl-readout-row { display: flex; align-items: flex-end; justify-content: center; gap: 64px; margin: 8px 0 6px; } .wpl-readout-row > div { width: 160px; } .wpl-readout-label { font-size: 13px; color: var(--wpl-muted); } /* Numbers/symbols ("C", "1", "5/7") read fine big and bold; full words ("Root High", "1st Inv") look oversized/heavy at the same size, so ui.js's setReadoutValue() adds this class whenever the raw value is longer than any real number/symbol ever gets (see ui.js comment). */ /* Chris, 2026-09-12 audit: the readout used to jump between a big size (short values like "C", "1") and a small one (words like "Root Low", "Notes") -- 24 vs 18px here, 19 vs 15 on phones -- so the same value looked different from screen to screen. Now one size per screen width, the largest that still fits the widest value this app can show ("D♭m Pentatonic") in its fixed box, with room to spare for device font differences: 20px here (widest measured 147 of 160px). */ .wpl-readout-row #wpl-chord-name, .wpl-readout-row #wpl-step-label, #wpl-chord-name.long-label, #wpl-step-label.long-label { font-size: 20px !important; } /* ---------- Piano ---------- */ /* Chris, 2026-09-12 (phone video): with the phone piano zoom, the keys showed through the frame's right edge, so the right border looked thinner than the left. The frame's edge is now a real border (same color, same width as the old padding, so the same size): overflow clips inside a border, never inside padding, so the zoomed piano always sits inside an even frame. */ #wpl-piano-frame { background: #1e293b; border-radius: 12px; padding: 0; border: 5px solid #1e293b; } /* Each white/black key's own look (piano-engine.js's buildKeyboard, which still sets each key's position/size inline since that's computed per-key -- only the shared, static look lives here). Bottom corners are rounded on every key, matching a real keyboard's rounded key-fronts. Top corners stay square on every key EXCEPT the two at the very outer ends of the whole keyboard (.wpl-key-first/-last, added by buildKeyboard) -- Chris (zoomed screenshot): "the first and last piano keys need to be rounded at the top to match the round at the bottom. don't round the top of any of the middle keys though, just the first and last." Matching the bottom radius exactly (5px white / 4px black) so the outer corner reads as one continuous curve, not two different curves stacked. */ .wpl-white-key { flex: 1; background: linear-gradient(#fff, #f1f5f9); border: 1px solid #cbd5e1; border-radius: 0 0 5px 5px; position: relative; cursor: pointer; } .wpl-white-key.wpl-key-first { border-top-left-radius: 5px; } .wpl-white-key.wpl-key-last { border-top-right-radius: 5px; } .wpl-black-key { background: linear-gradient(#1e293b, #334155); border: 1px solid #000; border-radius: 0 0 4px 4px; cursor: pointer; } #wpl-status { text-align: center; font-size: 12px; color: var(--wpl-muted); margin-top: 3px; height: 18px; line-height: 18px; overflow: hidden; } /* Opt-in divider inside a button row (Scales' two rows, 2026-09-12) -- same look as the key row's natural/accidental divider. It never grows, so the buttons on either side keep sharing the leftover width, and a partner row with a divider in the same spot keeps every button lined up. See makeRowDivider() in ui.js and CLAUDE.md's layout rules. */ .wpl-row-divider { flex: 0 0 3px; align-self: stretch; margin: 6px 3px; background: var(--wpl-line); border-radius: 2px; } /* ---------- Playback bar ---------- */ .wpl-playbar { display: flex; align-items: center; gap: 18px; background: var(--wpl-tan); border: 1.5px solid var(--wpl-line); border-radius: 12px; /* 2026-09-12 audit: was 14; the app uses 8 / 12 / 20 */ padding: 9px 18px; margin-top: 22px; flex-wrap: wrap; } .wpl-bpm { display: flex; align-items: center; gap: 10px; flex: 1; min-width: 180px; } .wpl-bpm-label { font-size: 12px; font-weight: 700; color: var(--wpl-tan-text); white-space: nowrap; } .wpl-bpm-value { font-size: 13px; font-weight: 800; color: var(--wpl-ink); width: 40px; text-align: right; font-variant-numeric: tabular-nums; } .wpl-bpm input[type="range"] { flex: 1; -webkit-appearance: none; appearance: none; height: 5px; border-radius: 3px; background: linear-gradient(var(--wpl-accent),var(--wpl-accent)) 0/var(--pct,50%) 100% no-repeat, #ddd2b3; outline: none; } .wpl-bpm input[type="range"]::-webkit-slider-thumb { -webkit-appearance: none; width: 16px; height: 16px; border-radius: 50%; background: var(--wpl-accent); border: 2.5px solid var(--wpl-card); box-shadow: 0 1px 4px rgba(60,50,20,0.3); cursor: pointer; margin-top: -0.5px; } .wpl-bpm input[type="range"]::-moz-range-thumb { width: 14px; height: 14px; border-radius: 50%; background: var(--wpl-accent); border: 2.5px solid var(--wpl-card); box-shadow: 0 1px 4px rgba(60,50,20,0.3); cursor: pointer; } .wpl-playbar-controls { display: flex; align-items: center; gap: 8px; } .wpl-toggle-btn { display: flex; align-items: center; gap: 6px; border: 1.5px solid var(--wpl-line); background: var(--wpl-card); color: var(--wpl-tan-text); font-weight: 700; /* Kept at 12.5px (2026-09-12 audit): matching Play's 13px made these buttons 1px taller, which grew the card on every screen. */ font-size: 12.5px; padding: 9px 13px; border-radius: 8px; /* 2026-09-12 audit: was 9; the app uses 8 / 12 / 20 */ cursor: pointer; transition: background 0.15s ease, border-color 0.15s ease, box-shadow 0.15s ease, transform 0.15s ease, color 0.15s ease; white-space: nowrap; min-width: 0; } .wpl-toggle-btn.active { background: var(--wpl-accent); border-color: var(--wpl-accent); color: #fff; box-shadow: var(--wpl-active-shadow); } .wpl-toggle-btn .wpl-icon { font-size: 14px; line-height: 1; } .wpl-play-btn { display: flex; align-items: center; justify-content: center; gap: 7px; border: 1.5px solid var(--wpl-accent); background: var(--wpl-accent); color: #fff; font-weight: 800; font-size: 13px; padding: 10px 18px; border-radius: 8px; /* 2026-09-12 audit: was 9; the app uses 8 / 12 / 20 */ cursor: pointer; box-shadow: var(--wpl-active-shadow); transition: background 0.15s ease, border-color 0.15s ease, transform 0.15s ease; white-space: nowrap; min-width: 132px; } .wpl-play-btn.playing { background: #f59e0b; border-color: #f59e0b; } /* ---------- Panels (the shell doesn't move on tab switch — the key selector + piano above this live in .wpl-instrument and never move at all, regardless of tab) ---------- All 4 panels are stacked in the SAME grid cell (grid-row/grid-column:1), so .wpl-panels sizes itself to whichever panel is naturally tallest — automatically, with no min-height number to keep in sync by hand. Only the active one is visible; the rest sit underneath at visibility:hidden (not display:none, which would remove them from the height calculation entirely and defeat the whole point). Chris (2026-08-28): "I don't want to keep adjusting vertical heights for things" when adding future tabs or content — this is the fix, do NOT go back to per-panel min-height tuning. Adding tab #5 someday just means adding a 5th `.wpl-panel` in here; its height is picked up automatically. */ .wpl-panels { display: grid; } /* .wpl-content-area: a plain block, one level up from .wpl-panels -- NOT a tallest-wins grid itself. #wpl-instrument (piano/keys -- its own top-level block now, no longer nested inside .wpl-standard-view) and #wpl-standard-view (just Chords/Progressions/Scales now) stack in normal document flow, one after the other, and BOTH always reserve their real height even while hidden (visibility, not display:none -- same trick .wpl-panel uses below, and Chris 2026-09-09: "the card needs to be the same size on every tab"). That combined height is what makes the card the same size on every tab, always, with no hand-picked number to keep in sync. #wpl-panel-practice is absolutely positioned on top of BOTH of them combined (inset:0 relative to THIS element) -- so by default Practice gets the FULL card, exactly like the hub did before Speed Drills existed (Chris spent a lot of rounds getting that tile grid to fill the card nicely -- losing that space to a dead gap where the instrument WOULD be was the bug in the first pass of this rework, 2026-09-10: "it's ruined"). Only when a Speed Drill un-hides #wpl-instrument does ui.js's syncPracticePanelTop() push Practice's own top down by the instrument's real (measured) height, so the drill's content starts right where the instrument ends instead of overlapping it or leaving its own gap -- Chris, 2026-09-10: "the piano and speed and key picker needs to default back to their regular place when not hidden. anything in their way needs to move somewhere else." */ .wpl-content-area { position: relative; } #wpl-instrument.wpl-instrument-hidden { visibility: hidden; pointer-events: none; } /* #wpl-panel-practice is deliberately taken OUT of normal document flow with position:absolute -- see .wpl-content-area's comment above for why (Practice never affects the card's height, and covers the full card by default). overflow-y:auto means a future module whose content is genuinely taller than the budget scrolls INSIDE its own box instead of pushing the card taller. */ #wpl-panel-practice { position: absolute; inset: 0; overflow-y: auto; } .wpl-panel { grid-row: 1; grid-column: 1; visibility: hidden; pointer-events: none; /* Without this, a grid item's default min-width:auto lets its own content's min-content size force the shared grid COLUMN wider than the wrapper — the width equivalent of the height "tallest wins" trick above, but as a bug: one panel's non-wrapping row (e.g. the Scales settings row) can blow out the column and drag every OTHER panel to that same width, overflowing the card on narrow screens (Chris, 2026-08-31 — caught via Playwright at 390px). min-width:0 lets the item shrink to the column's real size so its own flex/text content wraps instead. */ min-width: 0; } .wpl-panel.active { visibility: visible; pointer-events: auto; } /* ---------- Coming soon panel ---------- */ .wpl-soon { display: flex; flex-direction: column; align-items: center; justify-content: center; padding: 20px; text-align: center; color: var(--wpl-muted); } .wpl-soon-icon { font-size: 34px; margin-bottom: 12px; } .wpl-soon-title { font-size: 17px; font-weight: 700; color: var(--wpl-ink); margin-bottom: 6px; } .wpl-soon-text { font-size: 13.5px; max-width: 380px; margin: 0 auto; line-height: 1.5; } /* ---------- Practice hub (tile grid, replaces old single "coming soon" panel) ---------- Tiles reuse the app's existing visual language rather than inventing a new one: resting tan fill + var(--wpl-line) border, same as .key-tab/ .step-btn; the "Soon" pill is the exact .wpl-tab-soon class the tab bar already uses. Only .practice-tile itself, the grid, and the sub-view toggle are new. Grid starts at 2 columns (fits the narrowest phones this app supports) and moves to 3 at the same 521px breakpoint several other rows in this file already switch at, rather than introducing a new one Chris would have to reason about separately. */ .practice-hub { /* height:100% makes this fill #wpl-panel-practice's fixed, resolved height (from its own position:absolute; inset:0) instead of sitting only as tall as 7-8 tiles naturally need with dead space below -- Chris, 2026-09-09: "distributed evenly across the card". grid-auto- rows:1fr splits that full height evenly across however many rows the tile count and column-count breakpoint produce; a future 9th or 10th tile just adds another equal-share row, no number to retune. align-items:center then keeps each .practice-tile at its own natural (moderate) size floating centered in that evenly-shared row band, instead of stretching to fill it edge to edge -- Chris, 2026-09-09: "they seem kind of big now" -- so the rows still spread evenly top to bottom across the full card, but the tile boxes themselves don't inflate to match. */ display: grid; grid-template-columns: repeat(2, 1fr); /* minmax(0, 1fr), not plain 1fr -- Chris, 2026-09-10: increasing row-gap pushed the grid taller than #wpl-panel-practice's fixed height and triggered its scrollbar ("that's not what I wanted"). Plain 1fr rows never shrink below their own tiles' natural min- height, so a big enough gap or tile size has no room left and overflows. minmax(0, 1fr) lets rows compress instead, so this grid can never push the fixed card taller no matter how gap/tile-size get dialed in from here. */ grid-auto-rows: minmax(0, 1fr); align-items: center; height: 100%; /* Chris, 2026-09-10: "the inner gap of both, needs to be the same outer gap" -- the outer gap is #wpl-wrapper'''s own left/right padding (10px at this width, see the <=520px #wpl-wrapper rule), which is the actual outer boundary around this grid since neither #wpl-panel-practice nor .practice-hub add any padding of their own. Matching row-gap/column-gap to that same 10px makes the spacing between tiles read as the same rhythm as the spacing around them, instead of tiles nearly touching inside a much wider border. */ row-gap: 12px; column-gap: 2px; } .practice-tile { display: flex; flex-direction: column; align-items: center; justify-content: center; gap: 4px; /* Chris, 2026-09-10: "when i say reduce the gap, i mean make the modules bigger to make the gap smaller" -- growing the tile itself (not shrinking row-gap/column-gap) is now the standing way to close up perceived empty space on this grid. */ padding: 17.82px 8px; width: 92%; justify-self: center; border-radius: 12px; border: 1.5px solid var(--wpl-line); background: var(--wpl-tan); text-align: center; } .practice-tile-icon { font-size: 21px; line-height: 1; } .practice-tile-label { font-size: 12.5px; font-weight: 700; color: var(--wpl-ink); line-height: 1.25; } /* Chris: "the spacing isn't even between the 6 mods." Some titles are one line, some are a manual two-line break (see SPEED_DRILL_MODULES in ui.js) -- align-items:center on .practice-hub centers each tile's own natural height within its row band, so a one-line tile and a two-line tile in the same row end up with different-looking gaps above/below even though the row bands themselves are equal. Reserving full two-line height for every title (whether it wraps or not) makes all six tiles the same height, so the gaps between them read as even. Chris, follow-up: "the top 2 module titles are 1 line, but they are sitting too high... either center it or move it on the 2nd line, whatever is cleanest" -- a one-line title inside that reserved two-line box was top-aligned by default (plain block flow), so it looked stuck to the top instead of sharing the box evenly the way a two-line title naturally does. flex + center centers it vertically within the same reserved height instead. */ #wpl-speed-drills-grid .practice-tile-label { min-height: 2.5em; display: flex; align-items: center; justify-content: center; } /* All six subtitles are one line now (Chris: "i don't like the sub titles being 2 lines reword them so they fit on 1 line") -- no more two-line reservation needed, just enough for one line so nothing clips. */ #wpl-speed-drills-grid .practice-tile-subtitle { min-height: 1.3em; display: block; } #wpl-speed-drills-grid .practice-tile-label-desktop { display: none; } #wpl-speed-drills-grid .practice-tile-subtitle-desktop { display: none; } /* Chris: "these 6 mods are too tall, shorten them a little bit." Less top/bottom padding than the default tile (17.82px) -- scoped to this grid only, the same way the height reservations above are. */ #wpl-speed-drills-grid .practice-tile { padding-top: 12px; padding-bottom: 12px; } /* Chris, 2026-09-10: gave each Speed Drills module a title + a one-line subtitle describing what it trains -- plain PRACTICE_TILES entries (top-level hub) never set this, so it just doesn't render for them. */ .practice-tile-subtitle { font-size: 11px; /* 2026-09-12 audit: was 10.5 */ font-weight: 500; color: var(--wpl-ink); opacity: 0.65; line-height: 1.2; } /* Soft color per tile (Chris, 2026-09-09: "it's so bland") -- a repeating 4-tint cycle so the grid reads as a coordinated set rather than one flat block of --wpl-tan. data-soon="true"'s existing opacity:0.6 mutes the not-yet-built tiles automatically, same as it already muted the icon/label. */ .practice-tile:nth-child(4n+1) { background: var(--wpl-tile-teal-bg); border-color: var(--wpl-tile-teal-border); } .practice-tile:nth-child(4n+2) { background: var(--wpl-tile-peach-bg); border-color: var(--wpl-tile-peach-border); } .practice-tile:nth-child(4n+3) { background: var(--wpl-tile-sage-bg); border-color: var(--wpl-tile-sage-border); } .practice-tile:nth-child(4n+4) { background: var(--wpl-tile-gold-bg); border-color: var(--wpl-tile-gold-border); } /* Only a tile with real content behind it (Speed Drills, Progression Drills today) is clickable -- everything still marked "soon" gets the same non-interactive treatment the tab bar's own "Soon" pill implies, so there's no dead click to discover on a tile that does nothing. */ .practice-tile[data-soon="false"] { cursor: pointer; transition: border-color 0.15s ease, box-shadow 0.15s ease; } .practice-tile[data-soon="true"] { opacity: 0.6; } .practice-tile .wpl-tab-soon { margin-top: 1px; } /* Sub-views (one per clickable tile) and the hub grid are never both visible -- same idea as .wpl-panel's own active-panel toggle, just nested one level deeper inside the Practice panel. */ .practice-subview { display: none; } /* height:100% so a subview's own .practice-hub grid (Speed Drills' module list) can resolve ITS OWN height:100% against something real, same as the top-level #wpl-practice-hub does directly against #wpl-panel-practice -- otherwise that inner grid has no defined height to stretch against and its tiles just pack tight instead of spreading out with the same rhythm as the top-level hub. Chris: "the speed drills modules spacing need to be the same as the practice modules spacing." */ .practice-subview.active { display: block; height: 100%; } /* Chris: "no small back buttons anywhere. it all needs to be the long one on the other modules." Matches .wpl-back-home-btn's own fix -- a