/* WebYay Payment Tunnel — experimental full-viewport wizard Pulls colors/fonts from the same custom properties already defined in styles.css (--gold, --ink, --muted, --line, --panel, --glass) so it stays in the same visual family as the rest of the WebYay template. Desktop-only experience; see #webyayTunnel[data-active] gating in tunnel.js. */ /* ROUND 30 - "Preview buttons don't work" root cause: the tunnel's Font Changes "Preview" tiles were already correctly wired (see getFontPreviewBtn()/realBtn.click() in tunnel.js) to click the REAL .font-choice-example button and genuinely open the real #fontExampleModal with real live-preview font injection - confirmed via Playwright that the click does fire and the modal does reach display:flex/.is-open. But styles.css only ever raises .font-example-modal to z-index:260 (just enough to clear the z-index:240 .start-modal it's normally opened from - see the z-index comment on .font-example-modal in styles.css). This tunnel overlay (#webyayTunnel) sits at z-index:99999, so whenever the modal is opened FROM INSIDE the tunnel it was rendering successfully but completely hidden behind the tunnel itself - functionally invisible, so it read as "the button doesn't do anything." tunnel.css loads after styles.css, so this plain override wins on cascade order alone (same selector/specificity, later stylesheet) with no !important needed, and it doesn't change anything about the modal's normal non-tunnel behavior (100000 is still comfortably above every other z-index in the stack). */ .font-example-modal { z-index: 100000; } #webyayTunnel { /* Item 7 (per Dave): "too dominant for what we need it for" - the top band (logo + "Your new website." headline + timeline chip trail) is shrunk ~15% overall. This isn't just the outer min-height number below; every internal vertical dimension that contributes to the band's real rendered height (logo size, close-button size, headline font-size/ padding, chip trail padding, chip padding/font-size, and the matching short-viewport @media(max-height:760px) overrides further down) is scaled down by the same ~15% in lockstep, so the content shrinks proportionally with the container instead of the container shrinking around content that stays the same size and overflows/clips. Was 20%. */ /* Per Dave (round 45+): the headline's font-size was just dramatically increased (see .tunnel-top__headline h2 below, now clamp(34px, 4.6vw, 68px) to match Apple.com/store's "Store" headline) - loosened this back up slightly (17% -> 19%) so the much taller glyph box has room without recompressing the band Dave already asked to keep short (was 20% pre-shrink, so this is still meaningfully trimmed from that). */ /* Per Dave (round 46+): "not exactly; don't want this header that bold, match the weight of the smaller headers; and about 20% smaller in type size." The headline's weight/size were walked back in step (see .tunnel-top__headline h2 below - font-weight 800->600, clamp scaled to 80%), so the extra room this var added specifically to fit that bigger/ bolder glyph box is only partly still needed. Scaled 19% back down to 18% - keeps most of the 45+ breathing room (not a full revert to the original 17%) since the headline is still a bit larger than pre-45, but trims the excess now that it's no longer 800-weight/68px-max. */ /* Per Dave (latest round, item 2): the headline's padding-top just grew +13px (22px -> 35px, see .tunnel-top__headline below) to lower it further per his ask - nudged this floor up a hair (18% -> 19%) so the band has enough spare height to absorb that without crowding/ overlapping the chip trail row underneath. */ /* REGRESSION FIX (this round), item 5a: "you made this top color bar taller again... needs to be a little less tall, I'd say 13%." Cut 13% off the 19% figure above: 19% * 0.87 = 16.53%, rounded to 16.5%. The headline-to-trail gap (item 5b) is fixed separately below via the headline's padding-bottom / .tunnel-trail's padding-top - not by this height figure - so this change only affects the band's overall height, not the internal spacing between the two rows inside it. */ /* Per Dave (this round), item 1: "the top band is a little too big/too tall and the middle white tunnel is a little too small - make the top band about 15% shorter and add that 15% to the middle white tunnel." Cut another 15% off the 16.5% figure above: 16.5% * 0.85 = 14.025%, rounded to 14%. No separate action needed to grow .tunnel-mid - it's flex:1 1 auto (see .tunnel-mid below) so it automatically absorbs every bit of height this band gives up, same black-strip-safe mechanism documented on .tunnel-top/.tunnel-mid above. */ --tunnel-top-height: 14%; --tunnel-mid-height: 60%; /* Per Dave (round 36+): a prior pass here misread "less padding around the price text" as "shrink the whole band" and halved this min-height floor from 20% -> 10%. That was wrong on two counts Dave called out explicitly: it shrank the ENTIRE gray band (never asked for) AND pushed the price text almost flush against the top edge with no happy medium. Restored to the original 20% - the band's overall size/floor is back to what it was before that mistake. The actual fix for "less gap above the price text" now lives where it belongs: the vertical alignment of the content INSIDE this band (see `align-content`/padding tuning on .tunnel-bottom below), not this height figure. */ /* Item 5 (this round), per Dave: "still way too much padding between the dollar amounts and the top of the gray bar - fix it by making the gray bar smaller/shorter, by maybe 30-35px" - explicitly the band's overall size this time, not the inner content alignment (already tuned in the round referenced just above). Measured via Playwright at a real 1440x900 render: this 20% floor was rendering at exactly 180px (content inside only needed ~121px, so the 20% floor - not the content - was the actual constraint). Dropped to 16.4% (900px * .164 = 147.6px, a ~32px reduction, inside the requested 30-35px range) - still comfortably above the ~121px the real content needs, so nothing inside gets cramped/clipped. */ --tunnel-bottom-height: 16.4%; --tunnel-ease: cubic-bezier(.22, .8, .32, 1); /* Per Dave (round 49+, item 4): the top band's headline + chip trail were left-aligned to a flat 20px, which sits almost flush against the browser's own left edge - "almost falling off the left edge." The monitor mockup below (.tunnel-mid__preview) doesn't sit at a flat pixel either - it's centered as part of .tunnel-mid__unit (max-width 1440px, centered above that width) with its own 50px padding-left (see .tunnel-mid__unit). This variable reproduces that exact same math so the headline/trail's left edge lines up with the monitor's left edge at every browser width, not just one: below ~1440px .tunnel-mid__unit stretches to fill the row so the monitor's left edge is a flat 50px; above ~1440px the unit centers and its left edge shifts right by (viewport - 1440)/2, so the monitor moves further right too - this calc() mirrors both cases in one value. Verified via Playwright at 1440px and 1920px (see round-49 note). */ /* Per Dave (latest round): "all of this content... too far to the left... needs to shift towards the right, about 80 pixels" - the base 50px floor (and the +50px inside the centered-above-1440px calc) both bumped by 80px: 50px -> 130px. Per Dave (round 52+, item 3): "top header + timeline row... shift right 25px" - bumped again, 130px -> 155px. This is now a DELIBERATE divergence from .tunnel-mid__unit's own left offset (see item 4's note on that rule below) - an earlier round synced the two so the top band and mid content shared one left edge; Dave's two most recent requests (this one: top band right +25px; mid content: left -25px, see below) explicitly break that sync on purpose, so this var is no longer tied to .tunnel-mid__unit's padding-left at all. */ /* Per Dave (this round): "move this content to the left by 25 pixels throughout" - top band (headline + chip trail) shifted back left, 155px -> 130px. */ /* Per Dave (latest round): "the reverse white header needs to move to the left by 30 pixels... a little bit more [in line with] the monitor below it, for desktop." Same lever, one more shift left: 130px -> 100px. Desktop only (this var's whole formula is desktop-scaled; the dedicated mobile block elsewhere in this file overrides the headline's left padding separately and is untouched). */ --tunnel-content-left: max(100px, calc((100vw - 1440px) / 2 + 100px)); /* Per Dave (round 52+, item 4): the middle band's monitor+text column (.tunnel-mid__unit padding-left below) used to reuse this same --tunnel-content-left value to stay in sync with the top band. Dave now wants the middle content 25px further LEFT while the top band moves 25px further RIGHT (item 3 above) - a deliberate one-time divergence - so it gets its own independent variable here instead: prior shared 130px, minus 25px = 105px. */ /* URGENT REGRESSION FIX (this round), item 2: Dave reported the monitor + text column "pushed way to the left again" after the Login/Create Account feature landed. Root-cause investigation via Playwright getBoundingClientRect(): the Login/Create Account buttons and .tunnel-top__actions (position:absolute, confirmed still intact - see that rule above) have ZERO effect on this value or on sizeMonitorPreview()/any other JS layout math - none of those functions read .tunnel-top's width or this element at all. The monitor's measured left edge (104.28px at 1440px width) matched the 105px value here exactly, with no discrepancy. So this was NOT a new regression caused by the buttons - it's the round-52 105px value, still in effect, just reading as "too far left" now that Dave's expectation has settled back on the ~130-155px range the top band (--tunnel-content-left, 155px) uses. Restored to the pre-round-52-split shared baseline of 130px so the mid content sits back inside that established range instead of 105px. */ /* Per Dave (this round), item 4: "all of this content in the white tunnel - the buttons, the text, and monitor - need to shift towards the left by 20 pixels, it feels way too shifted off to the right." Monitor + right-side text/buttons both hang off this one shared padding-left (.tunnel-mid__unit below), so shifting it left 20px here moves both together. --tunnel-content-left (top band: logo/close/ step-nav) is a fully independent var (see above) and is deliberately left untouched - Dave's screenshot only showed the middle content area. 130px -> 110px. */ /* Per Dave (this round), desktop only: "all of this content needs to shift 25 pixels to the left on desktop" - same lever as the round-above 20px shift (this var drives .tunnel-mid__unit's padding-left, which moves the monitor + right-side text/buttons together as one unit). Mobile is untouched - .tunnel-mid__unit's own mobile override zeroes this padding-left out entirely (see mobile block below), so this var has no effect there regardless. 110px -> 85px. */ /* Per Dave (latest round): "everything inside the white metal tunnel... shift over to the left by 25 pixels, as one unit... don't change anything else just the positioning of it." Same lever again - one more 25px left shift, nothing else touched. 85px -> 60px. */ --tunnel-mid-content-left: 60px; /* Per Dave (round 20): "the headers and the super wide text... need to be less wide by at least 25%" - headers, bullet lists, body copy, and notes were all reading too wide/stretched across every slide type. This var drives .tunnel-card's own width (see .tunnel-card below), which is the single source of the right-hand content column's overall line-length, so trimming it here narrows ALL of those text elements consistently in one place rather than patching each one's own max-width separately. Was 620px; cut by 25% to 465px. */ --tunnel-card-w: 465px; /* No dedicated "Lewis teal" custom property exists in styles.css - the closest palette references are the slate/blue-gray tones labeled "teal" there (#49596a, rgba(60,91,123,*)), which read more blue-gray than true teal. Using a genuine teal here that still sits in the same cool-accent family as --gold (#5e7387); flagging per Dave's request. */ --tunnel-teal: #1c6b6b; --tunnel-teal-bg: #7E3187; /* Per Dave (latest round, item 3): darkened variant of the warm-gray/ taupe palette color above, for spots that need a deeper shade of the same family (e.g. the completed-step timeline dot below) rather than the flat base tone - roughly 20% darker per channel. */ /* Item 6 (this round), per Dave: the completed-step timeline dots (and the Secure Checkout button, which reuses this same value - see .tunnel-checkout-btn below) read as too dark/heavy at #67645e. Lightened one moderate step up toward the base --gold (#7E3187) tone, not all the way back to it - still clearly darker/more "done"-reading than the base palette, just a touch more subtle/subdued as asked. UPDATED (Plum/Jade recolor follow-up): this token was never part of Dave's original literal find-and-replace list (#817D76/#6E6A64 only), so it kept rendering the old discarded beige on every hover state and "eyebrow"/subheader that referenced it, even after the rest of the palette moved to Plum/Jade. Now set to the same secondary/darker plum (#66266E) already used everywhere else in the palette for hover/ pressed states, so it's consistent instead of a leftover one-off. */ --tunnel-teal-bg-dark: #66266E; --tunnel-bottom-gray: #eef0f0; --tunnel-bottom-ink: #1c242a; position: fixed; inset: 0; z-index: 99999; display: none; flex-direction: column; /* Bug fix, per Dave: scrolling the embedded "your new website" preview (a real, separately-scrollable iframe) on a phone was snapping the whole tunnel closed - overscroll-behavior wasn't set anywhere, so once that inner scroll hit its own end, the leftover touch-scroll gesture chained through this fixed overlay to the real page underneath (a documented iOS WebKit quirk with nested scrollers inside fixed overlays). The matching JS-set overscroll-behavior on documentElement/ body in openTunnel()/closeTunnel() is the primary fix (Safari has been inconsistent about which element it honors); this is the same fix applied directly to the overlay itself as a second layer. */ overscroll-behavior: none; /* Was #202020 (dark charcoal). Root cause of an intermittent black strip at the bottom of the viewport: the top/mid/bottom bands' heights didn't always sum to exactly 100% (see .tunnel-mid / .tunnel-bottom flex-basis fix below), so any leftover sliver let this root background peek through as an alarming black bar. Switched to white as a defensive fallback - even if a rounding/layout edge case ever reintroduces a sliver, it now reads as harmless white instead of a black bar, on top of the real fix (bands always summing to 100%). */ background: #ffffff; color: var(--ink); font-family: "Plus Jakarta Sans", Arial, sans-serif; } #webyayTunnel.is-open { display: flex; } #webyayTunnel * { box-sizing: border-box; } /* ---------- CHECKOUT REDIRECT INTERSTITIAL ---------- */ /* Fix, per Dave: Secure Checkout used to briefly reveal the real homepage underneath the tunnel while the create-checkout fetch was in flight (see showTunnelRedirectScreen()/finishTunnel() in tunnel.js for the full root- cause writeup). This screen is a plain absolutely-positioned sibling inside #webyayTunnel (which stays open/on top for the whole redirect now) so it can cover the entire tunnel - top/mid/bottom bands all at once - the instant Secure Checkout is clicked, and never lets anything else show through while we wait on Stripe. */ .tunnel-redirect-screen { /* REBUILT FROM SCRATCH (per Dave, "asked 14 times, start over and do it correctly"). Previous version stacked TWO centering mechanisms on top of each other (parent flex centering + child position:absolute/ transform centering) - that never should have been necessary and was genuinely confusing to reason about, even though every measurement agreed. Torn out entirely and replaced with the simplest possible single mechanism: this screen is a CSS Grid with place-items:center, full stop. One rule, one job, nothing else touching position/left/top/ transform anywhere in this block or its child. */ position: absolute; inset: 0; z-index: 50; display: grid; place-items: center; text-align: center; /* Per Dave (this round, explicitly BOTH desktop and mobile - not scoped to the mobile-only media block the rest of this file's recent rounds have used): "that thank you screen... boring in white background and dark text - change that to the primary dark beige background with white type instead." Reuses the same --tunnel-teal-bg dark beige already used for the tunnel's own top header band, and swaps the ink/muted text-color variables below to their light equivalents so every child (.tunnel-redirect-screen__title/__text, which just reference var(--ink)/var(--muted)) picks up readable light text automatically, no per-child overrides needed. */ background: var(--tunnel-teal-bg); opacity: 0; pointer-events: none; --ink: #ffffff; --muted: rgba(255,255,255,.72); transition: opacity .12s ease; } .tunnel-redirect-screen.is-open { opacity: 1; pointer-events: auto; } .tunnel-redirect-screen__inner { /* Plain, static, in-flow block - centered purely because its grid parent centers it. No position/left/top/transform here at all. */ max-width: 420px; width: 100%; box-sizing: border-box; padding: 0 24px; margin: 0 auto; } .tunnel-redirect-screen__eyebrow { display: block; font-size: 11px; letter-spacing: .14em; text-transform: uppercase; /* Bug fix, per Dave ("it ALL must be white text"): was var(--gold), which resolves to #7E3187 - the exact same value as this screen's own background (--tunnel-teal-bg). That made this line invisible (not literally black, but unreadable/blended into the background, the same underlying complaint), confirmed via screenshot showing a blank gap where "Order Received" should read. Switched to white so it's visible and consistent with every other line on this screen. */ color: #ffffff; margin-bottom: 14px; } .tunnel-redirect-screen__title { /* ACTUAL ROOT CAUSE FOUND (this round), per Dave's ~15th report on this, finally traced by measuring THIS element's own rect instead of just its parent's: styles.css has a GLOBAL `h2{...max-width:11ch}` rule (line 208) that this override never reset. This title IS an

- so it was silently capped to an 11-character-wide box the whole time. A block box narrower than its container left-aligns by default (text-align:center only centers the TEXT INSIDE a box, it does nothing for the box's own position unless margin is auto) - so the title box itself was sitting flush against the left edge of the otherwise-correctly-centered .tunnel-redirect-screen__inner container, while the eyebrow/subtitle (a /

, neither affected by the h2 rule) rendered correctly centered right below/above it. That's exactly the "message reads skewed left" Dave kept seeing - every prior check measured .tunnel-redirect-screen__inner's own box (genuinely centered, hence always passing) and never checked this specific child's box width. max-width:none removes the inherited cap so this title fills the same width as its siblings and centers correctly like they do. */ max-width: none; margin: 0 0 12px; font-family: "Plus Jakarta Sans", Arial, sans-serif; font-weight: 600; font-size: clamp(24px, 2.6vw, 30px); line-height: 1.2; color: var(--ink); } .tunnel-redirect-screen__text { margin: 0 auto 28px; font-size: 15px; line-height: 1.5; /* Bug fix, per Dave: "half the text in white and the other half text in black - it ALL must be white text." Root cause: this was hardcoded to a dark value (rgba(28,36,42,.82), left over from before the screen's background was switched to dark beige) instead of picking up the light --muted variable set on the .tunnel-redirect-screen parent - that hardcoded dark literal is exactly what was rendering as the "black" half of the text against the now-dark background. Switched to a genuine white so it matches the __title/__eyebrow, which already read correctly. */ color: rgba(255,255,255,.86); } .tunnel-redirect-screen__logo { /* Added per Dave, explicitly BOTH desktop and mobile: WaltersGroup logo centered above the "Thank you for your order" text on this screen. Bumped 50% larger (34px -> 51px) per Dave's latest ask - same both-platform scope as the original addition, no mobile-only reason to split it. */ display: block; height: 51px; width: auto; margin: 0 auto 22px; } .tunnel-redirect-screen__spinner { width: 26px; height: 26px; margin: 0 auto; border-radius: 50%; /* Was rgba(28,36,42,.14) - a dark ring, nearly invisible against this screen's dark-beige background (same stale-dark-literal issue as __text above). Lightened so the ring itself is visible; the gold top-color (the actual spinning accent) is unchanged. */ border: 2.5px solid rgba(255,255,255,.22); border-top-color: var(--gold); animation: tunnelRedirectSpin .8s linear infinite; } @keyframes tunnelRedirectSpin { to { transform: rotate(360deg); } } /* ---------- TOP BAND ---------- */ .tunnel-top { position: relative; /* Was "flex: 0 0 var(--tunnel-top-height)" + hard height + overflow:hidden, which clipped the chip trail whenever the headline wrapped/grew and the combined content height exceeded the rigid 20% band. flex-basis is now "auto" (content-based) with min-height as a floor, so the band sizes to its real content and only ever grows past 20%, never clips it. Root-cause fix for the intermittent black-strip bug: the mid/bottom bands used to have their OWN hard fixed percentage heights too (e.g. 60% + 20%), which combined with this band's min-height could sum to more or less than 100% of the viewport (most visibly when the max-height:760px query dropped this band's min-height to 14% but left mid/bottom at their desktop 60%/20% figures - 14+60+20 = 94%, leaving a real 6% gap of the dark root background exposed at the bottom of the window). The mid band is now `flex: 1 1 auto` (see .tunnel-mid below) so it always absorbs whatever space this band and the bottom band don't use - the three bands mathematically always sum to exactly 100% of the container's height, with no percentage arithmetic to keep in sync and no rounding gap possible. */ flex: 0 1 auto; /* Per Dave (round 26): "make top bar about 40 pixels taller (goes lower) and you could remove that amount from the middle tunnel, the white tunnel." The top band's height was purely --tunnel-top-height (a % of the viewport); adding a flat +40px on top of that (rather than just bumping the percentage) grows it by a consistent ~40px at any viewport height, matching "40 pixels" literally instead of a height-relative amount that would vary by window size. No change needed to .tunnel-mid or .tunnel-bottom to compensate - .tunnel-mid is flex:1 1 auto (see its block below) and always absorbs whatever's left after top+bottom, so it automatically shrinks by the exact same ~40px this line adds, and the three bands still always sum to exactly 100% of the container (the black-strip fix from an earlier round stays intact). This calc() also picks up the @media (max-height:760px) override of --tunnel-top-height below automatically, so the short-viewport clipping fix from that round stays in effect too, just +40px taller in that mode as well. */ /* Per Dave (round 28): the +40px added in round 26 made the top band "too tall" - trimmed by 25px (down to +15px net) per his explicit ask ("make it like 25 pixels shorter than you have it"). */ /* Per Dave (round 45+): bumped from +13px to +26px in step with the bigger headline (see --tunnel-top-height and .tunnel-top__headline h2 above/below) so the band's floor still comfortably fits the much taller glyph box plus real breathing room below it before the chip trail, without stretching the band back toward its original tall size. */ /* Per Dave (round 46+): headline walked back to 600-weight/80%-size (see h2 rule below) - trimmed the +26px floor addition down to +22px in step, same partial-revert logic as --tunnel-top-height above (keeps most of the 45+ room since the headline is still bigger than pre-45, but no longer needs the full amount added purely for the 800/68px version). */ /* CORRECTED (this round), per Dave's diagram: the headline stays right here in this band - it's the chip TRAIL that moved down into the gray .tunnel-bottom band instead (see .tunnel-bottom__header in this file). This band now only has to fit the logo bar + headline (no trail row below it anymore), so the old +22px floor - sized to clear headline AND trail together - is trimmed back, but headline itself is UNTOUCHED (still its full original size/weight, per Dave's explicit "keep the header [size] the same, all else remaining equal" - only this band's own floor height and the headline's own bottom padding below changed, to let it settle a bit lower and fill the space the trail used to occupy, not to shrink it). */ /* Per Dave (this round): "top banner is too tall... shorter by about 25 pixels, keeping the reverse header and everything in that bar in the exact same place - just a shorter header - and put the space you're gaining into the middle white tunnel." Trims this floor by 25px (14px -> -11px net) rather than touching any padding/logo/headline rule above, so the logo bar and headline stay pinned exactly where they already are - only the empty space below the headline, before the band's bottom edge, shrinks. .tunnel-mid is flex:1 1 auto (see its own rule further below) and always absorbs whatever this band and .tunnel-bottom don't use, so the reclaimed 25px goes straight to the white middle band automatically - no separate change needed there. Untouched: the 768-1023px tablet breakpoint's own separately- tuned min-height override further below (a different, deliberately tuned value for that range, not part of this ask). */ min-height: calc(var(--tunnel-top-height) - 11px); height: auto; /* Plum -> Jade color change (this round), per Dave's design-review spec: the flat --tunnel-teal-bg fill + translucent-black depth overlay (both from the earlier "gradation darkening" experiment, see prior comment history) are replaced with the new diagonal plum->jade gradient below. The gradient carries its own depth, so the old black-to-transparent overlay layer is removed entirely rather than layered on top of it - layering it back on would mute the jade end and muddy the plum. The 128% on the last stop is intentional (per spec) - it pushes the brightest jade just past the lower-right corner so the band stays mostly plum and only picks up green at the very corner; do not normalize it to 100%. */ background: linear-gradient(135deg, #6A2A84 0%, #438094 58%, #1BD6A3 128%); border-bottom: 1px solid rgba(255,255,255,.16); display: flex; flex-direction: column; } .tunnel-top__bar { display: flex; align-items: center; justify-content: space-between; /* Reverted (per Dave, latest round): back to zero top padding so the logo's orange/gold divider line sits flush against y=0, matching the original pre-regression state. The prior round's 14px "clearance" fix is undone per explicit instruction. */ padding: 0 28px 0 28px; } .tunnel-top__logo { /* Dave: "miniature, needs to be twice that big" - was 26px, now 52px. Still the same WaltersGroup mark (assets/img/wg-logo.svg), not swapped for the WebYay logo per his explicit "keep it WaltersGroup" note. */ height: 44px; width: auto; filter: brightness(1.05); opacity: 1; } /* Per Dave (latest round, item 4): "change this closing box up here to a pill button that says 'Close'... make it the same size pill button as most of the other pill buttons you have, like a Yes/No pill button." Swapped the small circular icon-only "x" for a text pill sized to match .tunnel-yesno__btn's own convention (same font-size/weight/letter-spacing/ padding/border-radius) - just tinted for this band's white-on-#7E3187 translucent-glass button language (matching the close button's own prior background/border tokens) instead of the yesno buttons' solid-white card treatment. Click behavior (closeTunnelAndModal in tunnel.js) is completely unchanged - this is a pure visual/markup swap. */ .tunnel-top__close { appearance: none; border: 1.5px solid rgba(255,255,255,.28); background: rgba(255,255,255,.08); color: var(--ink); width: fit-content; min-width: 0; height: auto; font-family: "Plus Jakarta Sans", Arial, sans-serif; font-size: 11px; font-weight: 600; letter-spacing: .02em; padding: 10px 22px; border-radius: 999px; line-height: 1; cursor: pointer; text-align: center; transition: background .2s ease, border-color .2s ease; /* REGRESSION FIX (latest round), item 4: the narrow-viewport-only fix below (added in an earlier round) used a `transform: translate(...)` that only applied under the max-width:1180px query - at normal/wide desktop widths this button was still governed purely by .tunnel-top__bar's align-items:center (that row's own height is set by the 44px logo, and this button's own ~52px-tall box, centered, landed only ~5-6px from the viewport top - confirmed live via Playwright getBoundingClientRect() at 1280/1440/1920px: closeBtn.top was 5.5px at all three, well under the 25-30px Dave asked for). Root-cause fix: align-self:flex-start pulls this button out of that row-height-driven centering so its own margin-top becomes the ONLY thing controlling its distance from the viewport top, at every desktop width - not just the narrow range. 26px lands comfortably in the requested 25-30px band (re-verified via Playwright after this change). */ align-self: flex-start; margin-top: 26px; } .tunnel-top__close:hover { background: rgba(255,255,255,.16); border-color: rgba(255,255,255,.4); } /* Item 11 (this round), per Dave: "below this Close button... we need to have a Login button and we need to have a Create Account button." Simple stacked column in the top-right corner - Close stays first/top exactly where it already was (align-self:flex-start + margin-top:26px on .tunnel-top__close is untouched), Login/Create Account stack directly beneath it at a smaller gap. */ /* URGENT REGRESSION FIX (this round), item 1: this column was left as a normal-flow flex-row CHILD of .tunnel-top__bar (sibling of the logo). .tunnel-top__bar's row height is governed by its tallest child under align-items:center - once this became a 3-button stacked column, IT became the tallest thing in the row (taller than the 44px logo), so the whole bar grew to fit it, and since .tunnel-top's own height is purely content-driven (flex:0 1 auto + min-height floor, see .tunnel-top above), that growth dragged the entire band's height with it - roughly doubling it and pushing the logo/headline/timeline down. Root cause confirmed live via Playwright getBoundingClientRect(): .tunnel-top__bar's own height tracked this column's stacked-button height 1:1, not the logo's 44px. Fix: take this column COMPLETELY out of normal flow with position:absolute, anchored to .tunnel-top (already position:relative, see that rule above) rather than participating in .tunnel-top__bar's row layout at all - same technique .tunnel-top__close itself used to use before this group existed (align-self:flex-start + margin-top, i.e. "float in the corner without affecting row height"), just formalized as true absolute positioning now that it's a 3-item column instead of a single button. top/right values reproduce the exact same visual position the close button had pre-regression: 40px = .tunnel-top__bar's own 14px padding-top + the close button's former 26px margin-top; 28px matches .tunnel-top__bar's own left/right padding so the column's right edge lines up with the logo's left padding on the opposite side. Because this is now absolute, it can never again influence .tunnel-top__bar's or .tunnel-top's height, no matter how tall its content gets. */ /* Fix (this round), item 1, per Dave: "this needs to move up at least 20px" - still position:absolute (unchanged, see regression-fix comment above), so nudging top has zero effect on .tunnel-top__bar's row height or .tunnel-top's min-height floor - confirmed via Playwright getBoundingClientRect() after this edit (top band height + logo position unchanged). 40px -> 20px (-20px). */ .tunnel-top__actions { position: absolute; top: 20px; right: 28px; display: flex; flex-direction: column; align-items: flex-end; gap: 8px; margin-top: 0; } /* Fix (this round), item 11: .tunnel-top__close's own align-self:flex-start was written for when it was a direct row-child of .tunnel-top__bar (to opt out of that row's vertical centering) - now nested one level deeper inside the .tunnel-top__actions COLUMN above (itself absolutely positioned, see the regression-fix comment above), that align-self property would instead push it to the column's opposite (left) cross-axis edge, misaligning it from the Login/Create Account pills below it. Reset back to the column's own flex-end alignment (matching its siblings) and drop the now-redundant margin-top (the column's own top/right positioning carries the clearance for the whole group now). */ .tunnel-top__actions .tunnel-top__close { align-self: flex-end; margin-top: 0; } /* SIMPLIFIED (this round), per Dave: "the new buttons (Login and Create Account) need to be side-by-side, on a different layer so they do NOT push everything around... I do not want them to be equal-sized buttons as 'Close' - in fact they can just be side-by-side text links, not enormous buttons that blow up the page." Replaces the old .tunnel-top__auth-btn pill recipe entirely - Login/Create Account are now plain small text links, not bordered/filled pill buttons at all. They still live inside .tunnel-top__actions (position:absolute, see above), so this row can never influence .tunnel-top's layout - and being tiny text instead of two more ~52px-tall pills makes the group's total footprint smaller than ever, not bigger. */ .tunnel-top__auth-links { display: flex; align-items: center; gap: 7px; } /* BUG FIX (this round), per Dave: "Hi [Name]!" and "Login • Create Account" were both rendering at once (screenshot showed "Create Account" sitting directly above "Hi Dave!"). Root cause: syncTunnelAuthUI() in tunnel.js correctly sets the `hidden` attribute/property on whichever of these two elements should disappear, but this rule above sets `display: flex` unconditionally on .tunnel-top__auth-links (author-stylesheet origin) - author CSS always wins over the browser's built-in `[hidden]{display:none}` UA-stylesheet rule regardless of selector specificity, so `hidden` was being silently overridden and the links stayed visually flex/visible even while `hidden` was true. .tunnel-top__greeting never had this problem (it has no explicit `display` override), which is why only the links half of the toggle was stuck showing. Adding an explicit `[hidden]` rule here (same specificity fight, but now on our side) restores the intended mutually-exclusive behavior. */ .tunnel-top__auth-links[hidden] { display: none; } .tunnel-top__auth-link { appearance: none; border: none; background: none; color: rgba(255,255,255,.72); width: fit-content; min-width: 0; height: auto; font-family: "Plus Jakarta Sans", Arial, sans-serif; /* Fix (this round), item 1, per Dave: Login/Create Account "don't have to be that massive, could be smaller" - 12px -> 10px. */ font-size: 10px; font-weight: 500; letter-spacing: .01em; padding: 0; margin: 0; line-height: 1; cursor: pointer; text-align: center; text-decoration: underline; text-underline-offset: 2px; transition: color .2s ease; } .tunnel-top__auth-link:hover { color: #fff; } .tunnel-top__auth-sep { color: rgba(255,255,255,.4); font-size: 11px; line-height: 1; } /* Greeting fix (this round), per Dave: when the visitor is already logged in, "Hi [FirstName]!" replaces the Login/Create Account links in the exact same spot - a plain sibling inside the same .tunnel-top__actions column (still position:absolute, see above), toggled via [hidden] by tunnel.js's syncTunnelAuthUI(). Styled to match .tunnel-top__auth-link's size/color/weight so swapping the two never changes the column's footprint or the top band's height. */ .tunnel-top__greeting { color: rgba(255,255,255,.72); font-family: "Plus Jakarta Sans", Arial, sans-serif; /* Fix (this round), per Dave: "Hi [Name]!" was rendering too small next to the Close button - "this needs to be larger text greeting the person." Bumped from 11px (matching .tunnel-top__auth-link) up to 14px, a clearer/friendlier size. .tunnel-top__actions stays position:absolute (unchanged - see its rule below), so this has zero effect on .tunnel-top's own height. */ font-size: 14px; font-weight: 500; letter-spacing: .01em; line-height: 1; white-space: nowrap; /* Fix (this round), item 3, per Dave: "Hi [Name]!" had no way back to Login/Create Account. This element now holds two children - the name text (data-tunnel-greeting-name) and a small "Log out" link (data-tunnel-logout, reuses .tunnel-top__auth-link's own size/color/ underline styling) - display:flex + a small gap lays them out side-by-side in the exact same corner spot, same as Login • Create Account did before. */ display: flex; align-items: center; gap: 6px; } /* Defensive pairing with .tunnel-top__auth-links[hidden] above: explicit [hidden] override here guarantees the two states stay mutually exclusive now that the base rule above sets an explicit `display: flex`. */ .tunnel-top__greeting[hidden] { display: none; } /* Item 3 (this round): thin vertical divider between the "Hi [Name]!" text and the "Log out" link, matching the same bullet-separator idea already used between Login and Create Account (.tunnel-top__auth-sep) so the two states read as visually consistent siblings, not different patterns. */ .tunnel-top__greeting-logout { padding-left: 6px !important; border-left: 1px solid rgba(255,255,255,.3); } /* Latest round, item 4, per Dave: on a narrow/mobile viewport the "Close" pill was sitting right up against/touching the browser's own top chrome - .tunnel-top__bar deliberately has 0 top padding (see its comment above, so the logo's gold divider line touches y=0), which left this pill with no real clearance either since it shares that same row. IMPORTANT: the tunnel is hard-gated to desktop-only widths elsewhere in this file (`@media (max-width: 1023px) { #webyayTunnel { display: none !important; } }`, further down) AND at open-time in tunnel.js (isDesktop(), DESKTOP_MIN_WIDTH = 1024) - it never renders at all below 1024px, true phone widths included. So "narrower/mobile" here can only mean the narrow end of the tunnel's own real, reachable range (a small/ non-maximized desktop or laptop window just above that 1024px floor), not an actual phone viewport. Breakpoint set at 1180px accordingly - comfortably covers that narrow-desktop range while leaving the normal/ wide desktop layout untouched. REGRESSION FIX (latest round), item 4: switched from a `transform: translate(-15px, 25px)` layered on top of the (then-centered) base position to an explicit margin-top, now that the base rule above already uses align-self:flex-start + margin-top:26px as its own real vertical anchor - transform would have stacked on top of that new base offset and pushed this button too far down. translateX still handles the pure-horizontal 15px nudge left; margin-top is set directly (not added via transform) so the two breakpoints don't compound. URGENT REGRESSION FIX (this round), item 1: the base rule above is now position:absolute (top/right), so this narrow-width override is rewritten to nudge those same top/right values directly instead of layering a transform + margin-top on top of a flow-based position - avoids any compounding between the two breakpoints. */ @media (max-width: 1180px) { .tunnel-top__actions { /* Fix (this round), item 1: matched the -20px nudge applied to the base rule above (44px -> 24px) so narrow-desktop widths get the same upward move Dave asked for. */ top: 24px; right: 13px; } } .tunnel-top__headline { flex: 1; display: flex; align-items: center; /* Per Dave (round 44+): "I don't really think I like that header... dead center. I think it wants to be justified left to the buttons below it" - was centered; now left-aligned so its text starts at the exact same left edge as the timeline row underneath it. Both this element and .tunnel-trail share the same 20px left padding (see .tunnel-trail below), so their content naturally lines up without needing a separate shared-variable hack. */ justify-content: flex-start; text-align: left; /* Extra top padding + the h2's own line-height below give ascenders/ tall punctuation (g, &, capital letters with overshoot) breathing room above the glyph baseline so they never touch the band's edge. Per Dave: bottom padding raised from 4px so the headline isn't nearly touching the chip trail below it (see .tunnel-trail's top padding, bumped in tandem) - comfortable normal spacing between the two. */ /* Per Dave (round 28): "the reverse headline is floating out on its own, it should be a little closer to the buttons [chip trail], but not like touching them like you had before" - a prior round bumped this bottom padding (and .tunnel-trail's top padding, in tandem) from 4px to 14px to fix a clipping bug. Trimmed back partway (14px -> 9px here, 14px -> 9px on .tunnel-trail below) - a moderate middle ground between the old touching/clipped 4px and the too-loose 14px, not a full reset. */ /* Per Dave (round 45+): the headline's font-size just jumped dramatically (see h2 rule below) - bumped bottom padding from 8px to 18px so the now much larger, heavier text doesn't crowd the chip trail underneath it (see .tunnel-trail's matching top-padding bump below). */ /* Per Dave (round 46+): headline text shrunk back down (see h2 rule below) - trimmed 18px back to 15px in step, same partial-revert as --tunnel-top-height/.tunnel-top's min-height above (still a bit more than the pre-45 8px since the headline is still a little larger than that original size, but no longer needs the full 18px added purely to clear the 800-weight/68px version). */ /* Per Dave (round 49+, item 4): left value switched from the flat 20px to --tunnel-content-left (see #webyayTunnel above) so this headline's left edge tracks the monitor mockup's left edge instead of the browser's own edge. Top/right/bottom untouched. */ /* Per Dave (latest round): "all these headers are too high - lower position by 15px" - top padding bumped 7px -> 22px. .tunnel-top's own flex-basis is content-driven (min-height only, see .tunnel-top above), so the band grows to absorb this instead of clipping/crowding the chip trail underneath. */ /* Per Dave (round after that): still too high - "lower by another 12-13px". Bumped 22px -> 35px (+13px). --tunnel-top-height's floor was nudged up in step (see #webyayTunnel above, 18% -> 19%) so this extra padding has real room to land without crowding/overlapping the chip trail row underneath. */ /* REGRESSION FIX (this round), item 5b: "that header needs to be positioned closer to the timeline - about half as much padding between the headers... and the timeline." The headline-to-trail gap is the SUM of this padding-bottom (15px) and .tunnel-trail's padding-top (8px, below) = 25px total. Halved this side: 15px -> 7px (paired with .tunnel-trail's 8px -> 5px below, total gap 25px -> 12px, ~half). */ /* Per Dave (this round), item 1: "make the top band about 15% shorter." Root-cause check via Playwright: .tunnel-top's flex-basis is "auto" (content-driven, see .tunnel-top above) with min-height only acting as a FLOOR - measured the real rendered top band at 1440x900 at 222.16px, while the --tunnel-top-height-driven floor was only ~170.5px (16.5% * 900 + 22px). Since content already exceeds the floor, changing --tunnel-top-height alone (done above, 16.5% -> 14%) produces ZERO visible change - the floor was never the actual constraint. This padding-top is the single largest real contributor to the band's rendered height, so it's the lever that actually moves the needle: trimmed 35px -> 13px (paired with .tunnel-trail's padding-bottom below, 8px -> 3px), landing the measured top band at ~188.7px - a genuine ~15% cut from the 222.16px baseline, verified via a fresh Playwright measurement + screenshot (logo/headline/timeline all still comfortably fit, nothing clipped/cramped). */ /* Per Dave (this round), item 2: "still floating too far from the tabs/ timeline below - halve the gap again." The prior 12px combined-padding figure above referred only to the CSS source values, not the real rendered gap - measured live via Playwright getBoundingClientRect() at 1440x900: the ACTUAL visible gap from the headline text's own glyph bottom (a Range over the h2's text node, not the line-box) down to the first timeline dot's top edge was 13.27px, not 12px - line-height leading below the glyph (~1.27px) plus this padding-bottom (7px) plus .tunnel-trail's padding-top (5px, below) all stack up to that number. Halved the real 13.27px target (~6.6px): trimmed this side 7px -> 3px (paired with .tunnel-trail's 5px -> 2.5px below), leaving the ~1.27px line-height leading untouched (it's baked into the font metrics, not a spacing value) for a new measured total of ~6.3px, genuinely half of the old 13.27px - re-verified via a fresh Playwright measurement after this change. */ /* REGRESSION FIX (this round), item 3: repeated rounds chasing "move the header down closer to the timeline" kept cutting padding-TOP (35px -> 13px over several passes) while padding-BOTTOM (the actual header-to- timeline gap) was separately being cut too - conflating two independent properties. The steadily shrinking padding-top made the header sit pinned near the top edge of the band, which read as "smaller/moved up" even though the h2's own font-size clamp was never reduced (still the large clamp(27px,3.7vw,54px) below - actually bigger than the older "unified" size, not smaller). Restored padding-top to a middle-ground 17px (not all the way back to the original 35px, but enough that the headline reads big/prominent again instead of cramped against the top edge) while leaving padding-bottom untouched at its current small 3px so the close gap to the timeline (the thing Dave actually wanted kept) is preserved. */ /* Latest round, item 3 (4th+ round on this exact gap): re-measured live via Playwright getBoundingClientRect() rather than trusting the CSS source (per Dave's explicit ask, given the documented history of the visual gap not matching what these padding values implied). At 1440x900: the real distance from the headline h2's own rendered bottom edge down to the first timeline dot's slot top (.tunnel-chip__ dot, .tunnel-trail's first child) measured 5.5px - made up of this padding-bottom (3px) + .tunnel-trail's padding-top (2.5px, below). Halved both sides of that real total: 3px -> 1.5px here (paired with .tunnel-trail's 2.5px -> 1.25px below), landing a new measured total of ~2.75px, genuinely half of the confirmed 5.5px - re-verified via a fresh Playwright measurement + before/after screenshot after this change (see tunnel_test.js in this round's working notes). */ /* Per Dave (this round): "these heads are slightly too high, move them down about nine pixels throughout" - bumped padding-top +9px (17px -> 26px), applies to every category's headline since they all share this one rule. .tunnel-top's own height is content-driven (min-height only, not a hard cap - see #webyayTunnel above), so it absorbs the extra 9px without crowding/clipping the chip trail underneath. */ /* Fix (this round), per Dave's diagram: the chip trail that used to sit directly below this headline moved down into the gray .tunnel-bottom band instead (see .tunnel-bottom__header). Nothing follows this headline in this band anymore, so its old tight 1.5px bottom padding - tuned purely to keep it close to that trail - now just reads as "headline crammed near the top with empty space below it." Bumped to 20px so it settles down a bit into the room the trail used to occupy, per Dave's explicit "scoots down a bit to compensate." Font-size/ weight/color on the h2 itself (below) are completely untouched - this is a spacing-only change, not a resize. */ /* Fix (this round), per Dave: "move these headers down 10px throughout" - bumped padding-top +10px (26px -> 36px), applies to every category's headline since they all share this one rule. .tunnel-top's own height is content-driven (min-height only, not a hard cap - see #webyayTunnel above), so it absorbs the extra 10px without clipping anything. */ /* Fix (this round), per Dave: "the reverse header up above is a little bit high within that dark beige background bar... lower that throughout about 7 pixels." Same "throughout" convention as the fix above - bumped +7px again (36px -> 43px); see the matching max-height:760px short-viewport variant of this same padding-top, updated in step below. */ /* Per Dave (this round): "it doesn't look any different... needs to be shorter, maybe 15px shorter; header not shifting." The earlier attempt this round trimmed .tunnel-top's min-height floor, but that band's real height is content-driven (flex:0 1 auto - min-height only acts as a floor, see .tunnel-top above) and this headline's own padding is what actually determines the band's real rendered height, so the min-height edit alone had zero visible effect - same root-cause pattern documented in this block's history above. This padding-bottom (the empty space below the headline text, before the band's own bottom edge) is the real lever: trimmed 20px -> 5px, a genuine 15px cut. padding-top (43px) is untouched so the logo bar and the headline text itself stay pinned exactly where they are - only the trailing space shrinks, and .tunnel-mid (flex:1 1 auto) automatically absorbs the reclaimed 15px into the white middle band. */ padding: 43px 20px 5px var(--tunnel-content-left); } .tunnel-top__headline h2 { margin: 0; font-family: "Plus Jakarta Sans", Arial, sans-serif; /* Per Dave (round 45+): referencing Apple.com/store's giant bold "Store" headline as the target - "big and bold... left justified to the timeline buttons." Bumped from 600 to 800 (Plus Jakarta Sans' heaviest practical weight before Black starts looking off in this font at this size) to match that dense, heavy look. */ /* Per Dave (round 46+): "not exactly; don't want this header that bold, match the weight of the smaller headers." Reverted 800 back to 600 - the exact same font-weight already used on .tunnel-card__question (the main slide question headers), so this headline now reads at the same weight/density as those instead of the ultra-bold Apple.com/store treatment. */ /* Per Dave (round 50+): "the headers are still too heavy weight, needs to be less bold." Dropped 600 -> 500 (Plus Jakarta Sans' Medium weight renders cleanly - it's a variable font with real weight steps from 200-800, so 500 isn't a fake/synthetic weight) - reads clearly lighter than the old 600 while still dense enough to hold up as a headline at this large clamp() size, not flimsy/thin. Fix (this round), per Dave: "made those headers throughout slightly less heavy than they are (on desktop)" - one more small step down, 500 -> 450 (still a real weight step on this variable font, not synthetic). No separate mobile/narrow-breakpoint override sets its own font-weight for this element, so this single change already covers every width, matching "throughout." */ font-weight: 450; /* Per Dave (round 45+): a prior round shrank this ~15% in step with the rest of the top band (18->15, 28->24). Dave has now asked for the headline itself to be dramatically bigger regardless of that band trim - "the same size as what you're seeing here with 'Store'... kind of big and bold" - so this clamp jumps well past even the original pre-shrink 24/40px ceiling, into the 56-72px range he referenced, using the same clamp() pattern already established on .tunnel-card__question elsewhere in this file. Reusing nowrap + ellipsis below still keeps any real headline text on one line so it can't wrap and blow out the band's height. */ /* Per Dave (round 46+): "about 20% smaller in type size" - each clamp() number scaled to exactly 0.8x (34->27.2->27px, 4.6vw->3.68vw->3.7vw, 68->54.4->54px), same proportions, just 20% smaller across the board. */ font-size: clamp(27px, 3.7vw, 54px); /* Was unset (browser default ~1.2), which is tighter than this font's real ascent+descent box - combined with `overflow:hidden` below (kept for the ellipsis truncation to work), the line box clipped the very top of ascenders and tall glyphs like "g" and "&" on headlines such as "Want ongoing hosting & care?". A slightly taller line-height gives the full glyph, including overshoot, room inside the line box so `overflow:hidden` never crops it. */ /* Per Dave (round 50+): even at 1.15, descenders (the tail of "g" in "Website Changes", etc.) were still visibly cropped flat along the bottom edge - confirmed via computed box model that the line box (line-height * font-size) was shorter than Plus Jakarta Sans' real ascent+descent metrics at this font-size, and `overflow:hidden` on this element clips to that too-short line box. Bumped 1.15 -> 1.3 so the line box has enough room for the font's full descent (matches the analogous 1.2 -> bump on the short-viewport clamp below). */ line-height: 1.3; letter-spacing: -.01em; color: var(--ink); white-space: nowrap; overflow: hidden; text-overflow: ellipsis; max-width: 100%; transition: opacity .28s ease, transform .32s var(--tunnel-ease); } /* BUG FIX, per Dave's screenshots: "Website Chan..." / "Your new web..." were getting cropped on the right edge. Root cause: this element's own `overflow:hidden` (set above) was tuned for the OLD plain-text content, where it paired with `text-overflow:ellipsis` to truncate a genuine text node that ran too long. Now that the content is the animated SVG (see animateHeadlineIn() in tunnel.js and .tunnel-headline-svg below, which already sets its OWN overflow:visible), that ancestor overflow:hidden was clipping the SVG's rendered text at this element's box edge - the child's own overflow:visible can't escape a hidden ancestor. Scoped via :has() to only the SVG-content case, so the (extremely old-browser-only) plain-text fallback path in animateHeadlineIn keeps the original ellipsis-truncation behavior untouched. */ .tunnel-top__headline h2:has(.tunnel-headline-svg) { overflow: visible; text-overflow: clip; } .tunnel-top__headline h2.is-swapping { opacity: 0; transform: translateY(8px); } /* Per Dave: "have [the reverse headers] be animated exactly like the animation in this attached [logo] file" - and (round 2) "that animation isn't even close... not just zipping it across." See animateHeadlineIn() in tunnel.js for the full round-1-bug/round-2-rebuild story - this is now a REAL SVG stroke-dasharray draw animation (same technique the reference file used), just built on a live SVG / per character instead of pre-drawn letterforms, since this headline text is dynamic (different per category, different per breakpoint). .tunnel-headline-svg: the outer SVG replaces the h2's plain text node. No viewBox is set on purpose - with no viewBox, 1 SVG user unit = 1 CSS pixel, so the / children below can just use normal font-size units directly with no coordinate-system math. `overflow:visible` so stroke width and any glyph ascender/descender overshoot never clips (deliberately more permissive than the old plain-text h2's own overflow:hidden, which existed for its now-unused text-overflow:ellipsis - this replaces that with generous height instead, see below). */ .tunnel-headline-svg { display: block; overflow: visible; width: 100%; /* Tall enough to clear this headline's full clamp(27px,3.7vw,54px) range plus real descender/ascender room at every size in that range, so nothing from the animated stroke ever clips even though overflow is visible (visible just means IF it clipped it wouldn't - height is still the real safety margin). */ height: 1.4em; } /* Font-family/weight/size/letter-spacing and color are all deliberately left unset here - see animateHeadlineIn()'s comment in tunnel.js: these are inherited CSS properties, so this SVG text picks up exactly what the real

ancestor (and its many existing per- breakpoint font-size overrides throughout this file) already renders, with zero duplicated sizing logic to keep in sync. fill/stroke are set to currentColor so they follow that same inherited `color`. */ .tunnel-headline-svg__text { fill: currentColor; stroke: currentColor; /* BUG FIX, per Dave: "too thick line." Miscalculated the reference's proportion the first time around - the reference's stroke-width:.9 is relative to its viewBox's ~58-unit CAP-HEIGHT, not the full em box (cap- height is roughly 0.7 of font-size for most sans fonts, this one included) - 0.9/58 = ~1.55% of cap-height, which converts to ~1.55% * 0.7 = ~1.1% of font-size, not the 3.5% originally used here (a real ~3x-too-thick error). Relative to font-size (em) rather than a flat px value so the stroke still reads proportionally consistent across the whole clamp(27px...54px) range instead of looking too thick at the small end or too thin at the large end. */ stroke-width: .011em; stroke-linecap: round; stroke-linejoin: round; dominant-baseline: text-before-edge; } /* Timeline trail sits along the bottom edge of the top band. Round 44+, item 3: fully rebuilt from a row of individually-bordered pill/chip buttons into a minimal dot-and-line progress timeline, per Dave's reference images - a thin horizontal line connects small round step dots, and each category's label sits BELOW its dot (not beside it inside a pill anymore). Built as: [chip][seg][chip][seg]...[chip], all siblings in one flex row (see buildTrail() in tunnel.js), so the line segments are real connected geometry rather than a background-image trick, and can independently be marked "traveled" or not. */ .tunnel-trail { display: flex; align-items: flex-start; /* Per Dave (round 48+): was justify-content:center with chips/segs set to flex-grow, which stretched the whole timeline edge-to-edge across the band. Switched to flex-start so it reads as a compact, left- aligned cluster instead (starting from the same 20px left padding as the headline above it), with growth disabled on the children below. */ justify-content: flex-start; gap: 0; /* Per Dave (round 49+, item 4): left value switched to --tunnel-content-left in tandem with .tunnel-top__headline above, so the two keep sharing one left edge - just now that shared edge is the monitor mockup's left edge instead of the browser's. */ /* REGRESSION FIX (this round), item 5b: paired with .tunnel-top__headline's padding-bottom halving above (15px -> 7px) - this side's top padding halved too (10px -> 5px) so the headline sits noticeably closer to this trail row, ~half the old 25px combined gap. */ /* Per Dave (this round), item 2: paired with .tunnel-top__headline's padding-bottom cut above (7px -> 3px) - this side's top padding cut in step (5px -> 2.5px) so the real measured text-to-dot gap drops from ~13.27px to ~6.3px, genuinely half. See the headline's padding note above for the full Playwright measurement. */ /* Per Dave (this round), item 1: paired with .tunnel-top__headline's padding-top cut above (35px -> 13px) - this side's bottom padding (below the trail row, before the white .tunnel-mid band starts) cut in step (8px -> 3px) so the real height reduction lands close to the requested ~15% band-height cut instead of just the min-height floor (which turned out not to be the actual constraint - see the padding- top note above for the full root-cause explanation). */ /* Latest round, item 3: paired with .tunnel-top__headline's padding- bottom halving above (3px -> 1.5px) - this side's top padding halved too (2.5px -> 1.25px) so the real measured headline-to-dot gap drops from the confirmed-live 5.5px to ~2.75px, genuinely half. */ /* Fix (this round), item 9, per Dave: the trail row was sitting right up against the bottom edge of the dark teal top band with no breathing room below the label text. Bumped bottom padding +7px (3px -> 10px) so the whole row effectively lifts ~7px away from the band's bottom edge, leaving real clearance between the labels and the white .tunnel-mid band that follows. */ padding: 1.25px 20px 10px var(--tunnel-content-left); flex-wrap: nowrap; /* Fix (this round), per Dave: "10px LESS padding between header and dots in timeline" - the header-to-trail gap (this padding-top, 1.25px, paired with .tunnel-top__headline's own tiny padding-bottom, 1.5px above) was already trimmed to near-zero by prior rounds, so there was no more room to cut from padding alone (padding can't go negative). Pulls the whole trail row up 10px via negative margin-top instead - the single property that actually controls this gap now - landing the dots directly under the header's glyphs with zero visible whitespace between them. Verified via Playwright: real measured header-text-to-first-dot gap dropped by exactly 10px (glyph baseline area now sits right against the dot row, no clipping of the header's own text). */ /* Per Dave (this round): reversed direction - "more padding between buttons and header." The -10px pull above had the trail sitting right against the header's glyphs with zero breathing room; this is the same property that actually controls the gap (see the note above), so it's the lever to open it back up. Set to a real, comfortable positive gap - a moderate value, not a maximal swing back to any of the old double- digit padding figures this gap has cycled through in past rounds. */ margin-top: 14px; } .tunnel-chip { appearance: none; border: none; background: none; color: var(--muted); font-family: "Plus Jakarta Sans", Arial, sans-serif; padding: 0; cursor: default; display: flex; flex-direction: column; align-items: center; /* Per Dave (round 48+): was flex:1 1 0 (equal-width columns that grew to fill the whole row, stretching the timeline across the page). Now fixed-width based on content only - no grow - so the cluster of dots+labels stays compact instead of spreading out. Still capped at a max-width so a long label ("Hosting & Care") can't blow out the tight spacing. */ flex: 0 0 auto; min-width: 0; /* Per Dave (round 51+, item 3): 96px was clipping "Website Changes" into "Website Chang…" via the label's ellipsis below - "the text box needs to be wider." Widened to 148px, generous enough for the longest real labels ("Website Changes", "Hosting & Care") to render on one line without truncating. */ max-width: 148px; transition: opacity .25s ease; } /* Thin connecting line between each pair of dots. margin-top lands it on the dot slot's vertical center (34px slot / 2, minus half this 2px line) - that offset is constant across every state because the dot SLOT (.tunnel-chip__dot) never changes size, only the circle drawn inside it via ::before does (see below), so the line never has to be re-tuned per state. */ .tunnel-trail__seg { /* Per Dave (round 48+): was flex:1 1 28px, which grew to soak up all leftover row width and was the main reason the timeline stretched across the full band. Fixed at ~1/3 of the old 28px base width and no longer grows, so dot/label groups now sit close together as a tight cluster. */ /* Per Dave (round 49+, item 1): 9px read as "literally a couple pixels apart" - too tight, the opposite extreme from the old edge-to-edge stretch. Dave explicitly warned against another maximal swing, so this is a deliberate middle ground (~2.4x the old 9px, not the original flex:1 1 28px full-width behavior) - checked visually via Playwright screenshot before finalizing, not just picked by formula. */ /* Per Dave (round 51+, item 4): "these categories need to be about twice as much [separated] as you have now, they're still a little bit tight." Doubled from the round 49 value of 22px to 42px - checked via Playwright screenshot before finalizing to make sure this reads as a comfortable, deliberate gap and not another maximal swing back toward the pre-48 edge-to-edge stretch. */ /* Per Dave (latest round, item 3a): "the padding in between these buttons... about 20% less than what you have it - they're just a tad spread out." 42px * 0.8 = 33.6px, rounded to 34px. */ /* Per Dave (this round): "these are not aligned correctly; they must be perfectly aligned, and spread out about 2x as much as you have it." Doubled 34px -> 68px. (Alignment itself is handled by positionTrailSegments() in tunnel.js, which measures each dot's real rendered circle edges via getBoundingClientRect on every layout change - it's fully dynamic, not hardcoded to this gap value, so it re-centers the connecting line correctly at the new spacing with no JS changes needed. .tunnel-chip__dot's fixed 34x34px slot, same margin on every chip regardless of done/current/future state, is what keeps the dots themselves on one consistent baseline.) */ flex: 0 0 68px; margin-top: 16px; position: relative; pointer-events: none; /* Per Dave (round 49+, item 3): unfilled segments (the connector to a step not yet reached) are now fully hidden, not just ghosted - see .is-filled below and updateTrail() in tunnel.js, which only marks a segment filled once the user has actually reached its far end. visibility:hidden (not display:none) keeps this segment's flex-basis reserving its layout space, so nothing shifts/reflows as the user progresses and later segments become visible. This div itself no longer draws anything (see ::before below) - visibility:hidden here still hides the pseudo-element too, since visibility is inherited. */ visibility: hidden; } /* Per Dave (round 50+): "looks ridiculous, like a dash... needs to be much thinner and more subtle, and needs to almost be touching the dots - maybe five pixels away, not just a short thing floating in the middle with a big gap on both sides." Investigated via Playwright getBoundingClientRect on the real rendered trail: the 22px slot above was never actually shrinking the old line - it already filled that slot edge to edge. The real gap came from .tunnel-chip itself (not just its 34px dot) growing up to 96px wide to fit longer labels like "Website Changes" or "Hosting & Care", with the dot centered inside that wider box - so the actual dot could sit up to ~31px past the slot's edge. Drawing the visible line as this ::before (instead of directly on .tunnel-trail__seg) lets it bleed out past the 22px slot via left/right offsets without changing the slot's own flex-basis - so the chip-to- chip spacing/rhythm Dave locked in at round 48-49 stays untouched, only the drawn line gets closer to each dot. Also cut from 2px tall/rgba(..., .65) - a solid, chunky bar - down to a 1px hairline at a much lower opacity, matching the muted-text convention used elsewhere in this band, so it reads as a subtle connector instead of a dash. -12px each side checked against real label pairs via Playwright before landing here: closes the ~30px gap seen on the widest pairs (e.g. "Your Website" -> "Website Changes") down to a clean ~5-8px from the dot, without the line's edge reaching far enough to visibly cross into a dot's circle on the tightest pairs (e.g. "Pages" -> "Logo", which already sit almost dot-to-dot with very little slack to spare). */ /* Per Dave (round 51+, item 2): the fixed -12px/-9px bleed above still read as inconsistent - "close to the dot on the left and far away from the dot on the right" - because chip widths vary a lot based on label text length (e.g. "Website Changes" vs "Logo"/"Pages"), so a single symmetric bleed value can't land at the same 5px clearance from every dot when its neighboring chips are very different widths. Replaced the fixed bleed with two custom properties (--seg-left / --seg-width) that positionTrailSegments() in tunnel.js computes PER SEGMENT from each dot's real rendered circle edge (via getBoundingClientRect + the dot's actual ::before circle diameter, which itself varies by state - 21px done, 10px current/base), inset exactly 5px from each dot on both ends regardless of the chips' widths. The -12px/1px values below are only a pre-JS-measurement fallback (e.g. very first paint tick). */ /* Item 11 (this round), per Dave: "when you click next, that line kind of grows and glides... it doesn't move, it just kind of opens up from nothing on the left side and opens up over to the new dot - and once it gets there, the new dot fades in." Was an instant visibility:hidden -> visible pop (see .is-filled below) with no entrance transition at all. scaleX(0) -> scaleX(1) with transform-origin:left is a genuine "grow from the left edge outward" - NOT a translate/move, which is what Dave explicitly ruled out - so the line visibly opens up left-to-right toward the dot it's connecting to, rather than sliding in as a whole already- full-width bar. The line's own left/width position (via --seg-left/ --seg-width) is unaffected by this - only its rendered scale changes. */ .tunnel-trail__seg::before { content: ''; position: absolute; top: 0; left: var(--seg-left, -12px); width: var(--seg-width, 46px); right: auto; height: 1px; /* Per Dave (this round), item 5: "the connecting line between each one is a little too distracting - needs to be a little more translucent/ subtle." Was .28 - dropped to .18, a moderate reduction (not the ::after label-hairline just below, which is a separate element/value per an earlier round and stays untouched). */ background: rgba(255,255,255,.18); transform: scaleX(0); transform-origin: left center; /* Per Dave (this round), item 1: "still going too fast, about half that speed" - doubled again from 1s (itself already doubled from an original .5s) to 2s. Doubled in lockstep with goNext()'s is-dot-pending timeout in tunnel.js (1040ms -> 2080ms) so the dot still only fades in once this longer grow finishes. */ transition: background .3s ease, left .15s ease, width .15s ease, transform 2s var(--tunnel-ease); } .tunnel-trail__seg.is-filled { visibility: visible; } .tunnel-trail__seg.is-filled::before { transform: scaleX(1); } /* Fixed-size slot that holds each step's dot - centers the visual circle (::before) and, once completed, the checkmark icon inside it, and is what the connecting line's margin-top above is measured against. */ .tunnel-chip__dot { width: 34px; height: 34px; flex: 0 0 34px; display: flex; align-items: center; justify-content: center; position: relative; /* Per Dave (round 51+, item 1): "dots + connector line sit too high above the label text... bring them much closer together." Was 6px, which combined with the label's own line-height read as a large floating gap between the dot/line row and the labels below it. Cut to 2px so the dot reads as tightly attached to its label. Latest round, item 2: still too much gap per Dave - cut this by half again, from 2px to 1px. This round, item 4a: "lower their position... less by 7 pixels" - cut a further 7px from 1px, which pushes past zero into a small negative margin (-6px) so the dot slot overlaps slightly closer to the label text below it, as explicitly requested. */ margin-bottom: -6px; color: #ffffff; } .tunnel-chip__dot::before { content: ''; position: absolute; width: 10px; height: 10px; border-radius: 50%; background: rgba(255,255,255,.32); opacity: 1; /* Item 11 (this round): opacity added to this same transition list so the "new dot fades in" half of the line-grow-then-dot-fade sequence (see .tunnel-chip.is-dot-pending below, driven from goNext() in tunnel.js) animates smoothly rather than snapping. */ transition: width .28s var(--tunnel-ease), height .28s var(--tunnel-ease), background .28s ease, box-shadow .28s ease, opacity .3s ease; } .tunnel-chip__dot svg { position: relative; z-index: 1; /* Per Dave (this round), item 5: "these checkmarks are a little too large, make them 20% smaller to scale (80% scale)." Was 14px x 14px - 80% of 14 = 11.2, rounded to 11px. */ /* Per Dave (this round), item 4b: "make the checkmarks... 20% smaller... more subtle." Was 11px (already an 80%-scale cut from an earlier round) - another 20% off: 11 * 0.8 = 8.8, rounded to 9px. */ width: 9px; height: 9px; opacity: 0; transform: scale(.4); transition: opacity .2s ease, transform .28s cubic-bezier(.34, 1.56, .64, 1); } /* Item 11 (this round): the NEW step's dot stays hidden (opacity:0) while its connector line is mid-grow (see .tunnel-trail__seg.is-filled above) - goNext() in tunnel.js adds this class to the arriving chip right before calling goToIndex(), then removes it ~520ms later (after the line's own .5s scaleX transition has finished), letting the dot fade in via the opacity transition just added to .tunnel-chip__dot::before above. Only used for the forward Next-click path - Back navigation and jumping to an already-completed step via a trail-chip click are unaffected, matching Dave's "when you click next" framing. */ .tunnel-chip.is-dot-pending .tunnel-chip__dot::before { opacity: 0; } .tunnel-chip__label { /* Per Dave (latest round, item 3b): "slightly larger for that type overall" - bumped +2px from 11px. Font-weight used to be left unset here (or overridden per-state below) - see the is-current/is-done rules further down, which used to bump weight to 700 on the active step only; that per-state weight swap is exactly what Dave asked to remove ("I don't want it to be bold on the active and then go back to non-bold... same font weight... whether it's active, past, or future"). Every state still inherits this one weight uniformly. Per Dave (round 52+, item 2): "this text is too heavy, needs to be a bit of a lighter weight" - even at the unset/inherited normal (400) weight, Plus Jakarta Sans' variable-font 400 still read visually heavy at this small size, so weight is now explicitly set below 400 (350) rather than left to inherit. Per Dave (this round): "let's see what this text looks like smaller, thinner, and all caps please" - font-size trimmed 13px -> 11px, weight trimmed further 350 -> 300 (the lighter end of the "350 for lightness" convention used elsewhere in the app), and text-transform: uppercase added since the labels ("Your Website", "Website Changes", etc.) are authored in the CATEGORIES chip strings as normal title-case text. letter-spacing left at its existing .04em - already comfortably within the ~0.03em all-caps-readability range this pairing usually calls for, so no change needed there. Per Dave (this round): "smaller type" - moderate further trim per the session's no-extreme-moves rule, 11px -> 9px. */ font-weight: 300; font-size: 9px; letter-spacing: .04em; text-transform: uppercase; color: var(--muted); text-align: center; /* Per Dave: text not centered top/bottom in the pill. 1.3 line-height built in extra leading below the caps (no descenders in this all-caps label to balance it), which read as sitting high in the 18px pill even with align-items:center on the flex row. Tightened to 1 so the line box hugs the glyphs and centers cleanly. */ line-height: 1; /* Per Dave (round 51+, item 3): "why does 'Website Change[s]'... cut off with an ellipsis? I guess the text box needs to be wider." Removed the nowrap+ellipsis truncation entirely (paired with the wider 148px chip max-width above) so every real label - including "Website Changes" and "Hosting & Care" - renders in full instead of getting clipped. white-space:normal lets a label wrap to a second line only if it's ever still too long for the widened box, rather than silently cutting text off. */ white-space: normal; overflow: visible; text-overflow: clip; max-width: 100%; transition: color .25s ease, font-weight .1s ease; } /* Per Dave (latest round, item 3b): "very faint, short vertical separator lines... between just the text part - not the text in the bubble above [the dots], but just little hairline, faint vertical separator lines between each of the word blocks." .tunnel-trail__seg already sits exactly in the gap between two adjacent .tunnel-chip elements (it's the same flex-row spacer the connector line above uses - see its ::before), so a second pseudo-element on this same spacer, positioned lower down at the LABEL row's vertical position instead of top:0, naturally lands centered between each pair of adjacent label text blocks without any extra markup or JS measurement. Kept as its own ::after (distinct from the dot-row ::before connector line above) so it never overlaps/ interferes with that line. .tunnel-trail__seg itself is visibility:hidden by default (only shown once .is-filled, see above) - explicit visibility:visible here overrides that inherited value for this pseudo only, since Dave wants these separators between every label pair regardless of done/current/future state, not just completed steps. */ .tunnel-trail__seg::after { content: ''; position: absolute; left: 50%; transform: translateX(-50%); /* Vertical centering: measured via Playwright against the real rendered boxes (seg's own top sits at the dot row; the label row's vertical center lands ~21px below that) so the hairline centers on the label's own text line rather than spanning the dot row above it or falling below the trail band entirely. */ /* Fix (this round): per Dave - "I moved the text up for this which I'd like, but you did not move the corresponding separator lines equally up, so now they're hanging way down below the text." Confirmed via Playwright getBoundingClientRect: label's own text-block vertical center measured ~169.46px from viewport top, while this hairline (segTop 149.02px + old top:20px + half its 14px height) centered at ~176.02px - 6.56px too low, reading as "hanging below" the label. top cut 20px -> 13.45px so this pseudo's center now lands on that same ~169.46px line as the label text, matching exactly. Fix (this round), per Dave's "smaller, thinner, all caps" pass on .tunnel-chip__label (13px -> 11px): shrinking the label text pulled its own vertical center up slightly, re-measured via Playwright getBoundingClientRect at a >760px-tall viewport (so the short-viewport media override below doesn't interfere) - label center now lands ~1.3px above the hairline's old center. top trimmed 13.45px -> 12.15px to close that gap and keep the hairline centered on the new, smaller label text. Fix (this round), per Dave's "smaller type" pass on .tunnel-chip__label (11px -> 9px): shrinking the label text again pulled its own vertical center up ~1.31px more, re-measured via Playwright getBoundingClientRect (segTop 137.078px + old top 12.15px + half the 14px pseudo height = 156.228px vs. label's own text-block center at 154.922px). top trimmed 12.15px -> 10.84px to close that gap and keep the hairline centered on the new, smaller label text. */ top: 10.84px; width: 1px; height: 14px; /* RE-FIX (this round), item 3: Dave's fresh screenshot showed NO visible separator at all, even though this rule (and the reduced .tunnel-trail __seg gap below) was already present in the file from an earlier round - the CSS itself was never missing. Root cause was almost certainly the cache-buster: index.html's tunnel.css query string was never bumped past ?v=64 when that earlier round landed, so browsers that already had v=64 cached kept serving the PRE-fix file and never re-fetched this change - a caching miss, not a broken rule. This round's cache-buster bump to ?v=65 (see index.html) forces a real re-fetch. Also hardened the rule itself against the "too faint to notice" theory raised in the brief: bumped from rgba(255,255,255,.15) to .3 - still a genuinely faint hairline against this band's dark teal background, but noticeably more visible than .15 in a real screenshot, confirmed via Playwright getBoundingClientRect + pixel-sampling zoomed into the trail row. */ /* Latest round, item 7, per Dave: "make it a little more faded/subtle" - a small, moderate reduction from .3, not a big change. */ background: rgba(255,255,255,.22); visibility: visible; pointer-events: none; } /* ROOT-CAUSE FIX (this round), item 1, per Dave: "on this breakpoint, the separator lines in the tab bar are too low, they didn't rise up with the words." This override was ALWAYS meant for the short-viewport (max-height) layout - its own comment says "Matches the short-viewport dot-slot shrink (26px)" - but it was mistakenly gated on `@media (max-width: 900px)` instead of `@media (max-height: 760px)`. Two consequences, both confirmed by hand-measuring the box model against the real CSS values: (1) on a normal-width-but-short window (e.g. 1280x720, or a laptop with a small non-maximized browser - width > 900px so this rule never applied), the short-viewport .tunnel-chip__dot shrink (34px->26px, margin-bottom -6px-> -5px) and .tunnel-chip__label shrink (9px->8px) plus .tunnel-trail__seg's own margin-top cut (16px->12px, all set inside the max-height:760 block below) all fired, but the ::after separator kept using the un-adjusted base top:10.84px/height:14px meant for the taller 34px-dot layout - landing its center ~3.6px BELOW the label's real text center, exactly Dave's "too low, didn't rise up with the words." (2) meanwhile a merely NARROW-but-tall viewport (<=900px wide, >760px tall) got this override even though it doesn't need it - the base top:10.84px/height:14px value already centers correctly against the un-shrunk 34px dots/9px label used at that breakpoint, so applying the 26px-dot-tuned values there pulled the line too high instead. Moving this block to `@media (max-height: 760px)` (alongside the actual dot/label/seg-margin overrides that create the 26px-dot layout) fixes both: short-but-wide viewports now get the correctly-tuned override, and narrow-but-tall viewports fall back to the already-correct base rule. top nudged 8.45px -> 8.2px, hand-recomputed against the max-height block's own real numbers below: dot content-top = 26px height - 5px margin-bottom = 21px; label line box = 8px font * 1.3 line-height = 10.4px, so label center = 21 + 10.4/2 = 26.2px from the trail row's top. seg's own top offset there is margin-top:12px, so solving 12 + top + height/2 = 26.2 with height:12px gives top = 8.2px - an exact center-on-center match, not just a close approximation. */ @media (max-height: 760px) { .tunnel-trail__seg::after { top: 8.2px; height: 12px; } } /* Small scale/fade-in pop when a category is first completed - only played once at the moment the dot becomes "done" (triggered via .is-popping in tunnel.js), not on every re-render of the trail. */ @keyframes tunnelCheckPop { 0% { transform: scale(0); opacity: 0; } 65% { transform: scale(1.3); opacity: 1; } 100% { transform: scale(1); opacity: 1; } } .tunnel-chip__dot.is-popping { animation: tunnelCheckPop .38s cubic-bezier(.34, 1.56, .64, 1); } /* Completed step: solid-filled dot (item 3's "15% larger" ask applies to this and the current dot below - both sized up from a smaller first pass so they read clearly at a glance). When the category was genuinely answered "yes" with content configured, updateTrail() in tunnel.js injects the checkmark SVG into this same dot (INSIDE it, not to its left as before); a "no" answer leaves the dot's solid fill with no icon - same underlying logic as the old chip row, just relocated. */ .tunnel-chip.is-done { opacity: 1; cursor: pointer; } .tunnel-chip.is-done .tunnel-chip__dot::before { /* Fix (this round), item 4, per Dave: an earlier round scaled the CHECKMARK ICON inside this dot down (14px->11px, see the svg rule above) but left the actual circle/background itself untouched at 21px - Dave wants the CIRCLE genuinely smaller, not just the icon inside it. 20% smaller than the real 21px diameter: 21 * 0.8 = 16.8, rounded to 17px. */ /* Per Dave (this round), item 4b: another 20% off the completed-dot circle, matching the checkmark icon's own cut just above: 17 * 0.8 = 13.6, rounded to 14px. (This also finally matches what the short-viewport media-query rule below already claimed the base value was - that comment was aspirational/incorrect until now, since base was still actually 17px.) */ width: 14px; height: 14px; /* Per Dave (latest round, item 3): was rendering blue (a leftover rgba(94,115,135,*)-family hex that never got swept up when the palette moved to the --gold/#7E3187 warm-gray family) - now a darkened shade of that new palette color instead of the flat base tone. */ background: var(--tunnel-teal-bg-dark); } .tunnel-chip.is-done .tunnel-chip__dot svg { opacity: 1; transform: scale(1); } .tunnel-chip.is-done .tunnel-chip__label { color: var(--ink); } .tunnel-chip.is-done:hover .tunnel-chip__dot::before { background: var(--tunnel-teal-bg-dark); filter: brightness(1.12); } .tunnel-chip.is-done:hover .tunnel-chip__label { color: #ffffff; } /* Current/active step: the single largest dot in the row, solid white so it reads clearly against the teal band, with a soft halo ring. Label goes bright + bold. */ .tunnel-chip.is-current { opacity: 1; } .tunnel-chip.is-current .tunnel-chip__dot::before { /* Per Dave (round 48+): the 25px dot + 5px/.16-alpha halo read as "too bright and distracting". Scaled down to 19px and the halo trimmed to a much smaller, softer ring so it's still clearly the active step without glaring. */ /* Per Dave (round 49+, item 2): "the active button... should be about half that large" - 19px cut to 10px (roughly half), halo ring trimmed in step so it stays proportional rather than looking oversized next to the now-smaller dot. Still clearly bigger than the 10px is-done/is-future dots below so it reads as the active step at a glance. */ /* Per Dave (round 51+, item 7): the active dot was a solid filled white circle - now a hollow ring/donut instead. Same ~10px overall diameter as the prior solid version, but drawn with a transparent center and a 2px white border/stroke so it clearly reads as an outline rather than a filled dot. box-sizing:border-box keeps the 10px a true outer diameter (the border is drawn inward, not added on top of it). */ /* Per Dave (latest round, item 2): thinner stroke - 2px read as too heavy/chunky for a 10px ring. Cut to 1.5px (not the full 1px Dave floated) since 1px checked via Playwright screenshot actually did read as too faint against this band's dark teal background at this small a diameter - 1.5px is the thinnest weight that still stays clearly visible. */ /* Per Dave (this round), item 8: "make these throbbing dots about half that size and slightly thinner - too distracting now." Halved the 10px diameter down to 5px and thinned the stroke 1.5px -> 1px. */ width: 5px; height: 5px; box-sizing: border-box; background: transparent; /* Per Dave (this round), item 2: "too wide [thick stroke]... needs to be somewhat translucent so the color behind it shows through a little." Stroke trimmed 1px -> .75px (thinnest weight that still renders as a visible line rather than disappearing) and switched from solid #ffffff to a translucent rgba white so the band's teal background shows through the ring a bit instead of reading as a solid opaque line. The soft halo box-shadow is trimmed from a 2px spread to 1px so it doesn't itself read as extra ring "width" stacked on top of the border. */ border: .75px solid rgba(255,255,255,.72); box-shadow: 0 0 0 1px rgba(255,255,255,.07); /* Per Dave (round 52+, item 1): the tunnelNextPulse glow (box-shadow based, reused from the Secure Checkout button) was invisible on this small hollow ring - "I don't think you're having a pulse." Swapped for a dedicated transform:scale breathing animation instead (see @keyframes tunnelDotBreathe below, near tunnelNextPulse) so the ring itself visibly grows/shrinks. tunnelNextPulse itself is left untouched - Secure Checkout still uses it. transform-origin:center keeps the scale centered on the ring rather than growing off to one side. */ /* Per Dave (this round), item 8: at the new smaller 5px size, the old 1->1.25 scale range (see @keyframes tunnelDotBreathe below) still read as visually loud, so the keyframe's own scale ceiling was tempered too (1.25 -> 1.15) alongside this size/stroke cut. */ animation: tunnelDotBreathe 2.4s ease-in-out infinite; transform-origin: center; } .tunnel-chip.is-current .tunnel-chip__label { color: #ffffff; } /* Upcoming/not-yet-reached step: small pale dot, ghosted label - matches the muted-text convention already used elsewhere against this band. */ .tunnel-chip.is-future { /* Per Dave (latest round, item 3a): "might be a little too ghosted, hard to read - make them a little less ghosted." Moderate bump from .55 to .68 (combined with this label's own --muted color, already at .68 alpha, the old .55*.68≈.37 effective opacity is now .68*.68≈.46 - noticeably more legible without going anywhere near fully opaque, which would stop reading as "upcoming/not yet reached" at all). */ opacity: .68; pointer-events: none; } /* Per Dave (round 49+, item 3): "I don't want to see the ghosted dashes or the ghosted circles above [future labels]... only show when you're there." The dot for a not-yet-reached step is now fully hidden - only its label (already ghosted via the .55 opacity above) stays visible. visibility:hidden (not display:none) keeps the 34px dot slot's layout space reserved, so the label doesn't jump upward and nothing reflows when the step later becomes current/done (see .tunnel-trail__seg's matching visibility approach above for the connecting line). */ .tunnel-chip.is-future .tunnel-chip__dot { visibility: hidden; } .tunnel-chip.is-future .tunnel-chip__label { color: var(--muted); } /* ========================================================================== PILL-STYLE TRAIL RESTYLE (this round) - EXPERIMENTAL, per Dave: "very thin white pill boxes around each one, eliminate the vertical separators, and [the] checkmark... would be in that same darker circle to the left of the words inside the pill button... future are ghosted out... past are pure white text and if they chose no, it would be the pure white text without the checkmark just that... maybe not pure white, a little translucent so they're a little more subtle." Dave explicitly flagged this as something he might want to revert ("I guess... we'll come back to this"). Kept as a clean, self-contained override block AFTER every rule above (all of that original column/dot- above-label styling, animations, etc. is left completely intact) so reverting is just deleting this block - nothing above needs to change either way. Everything below wins the cascade purely by appearing later in the file at equal specificity. */ /* Vertical connector lines removed entirely, per Dave. */ .tunnel-trail__seg, .tunnel-trail__seg::before, .tunnel-trail__seg::after { display: none !important; } .tunnel-trail { /* Fix (this round), per Dave: "these must be perfectly aligned... 2x as much padding on those words too" - doubled the inter-item spacing, same convention used everywhere else in this file when Dave asks for "2x" (see .tunnel-trail__seg's own doubling history above). */ gap: 16px; } .tunnel-chip { flex-direction: row; align-items: center; justify-content: center; gap: 5px; /* Per Dave (this round): "no pill button shapes at all" - the fixed- height/border/border-radius/background box that made each step read as a little bordered button is removed entirely. What's left is plain text sitting in the flex row (still spaced/aligned the same way via the rules above) - no box chrome of any kind, on any state. */ height: auto; /* ROOT-CAUSE FIX (this round), per Dave: "the previous item is not aligned, it's several px lower than the rest." Confirmed the cause: the done+checkmarked chip's .tunnel-chip__dot box (11px) was the only state that kept `display:flex` - is-current/is-future/is-done-no-check all set `display:none` on that same dot span below, which REMOVES it from layout entirely (zero height contribution), so those chips' own row height collapsed to just the 9px label line box while the checkmarked chip's row stayed 11px tall. Since .tunnel-trail top-aligns every chip (align-items:flex-start), that height difference pushed the checkmarked chip's vertically-centered label ~1-2px lower than every other chip's label, which sat flush at the row's own top with no centering offset to apply. min-height pins every chip's row to the same 11px regardless of which state's dot is actually visible, so every label centers against the identical row height - see the matching display->visibility fix on the three dot rules below, which is what actually keeps that reserved height in the layout. */ min-height: 11px; padding: 0; border-radius: 0; border: none; background: none; transition: opacity .25s ease; } /* The dot slot becomes the small circle sitting to the left of the label, inside the pill - only actually painted (see the is-done rule below) once a step is done AND genuinely checkmarked. Sized to sit comfortably inside the fixed 18px chip height above (never taller than the chip itself). */ .tunnel-chip__dot { width: 11px; height: 11px; flex: 0 0 11px; margin-bottom: 0; } .tunnel-chip__dot::before { display: none; } .tunnel-chip__label { text-align: left; /* Per Dave (this round): "no all caps, initial caps... slightly less light text weight." The base rule earlier in this file sets text-transform:uppercase + font-weight:300 for the old dot-timeline design - overridden here so the labels render exactly as authored in the CATEGORIES chip strings (already proper title case: "Your Website", "Changes", "Pages", etc.) at a slightly heavier weight than the old 300. Letter-spacing trimmed too - the old .04em was tuned for tight all-caps tracking and reads too loose on normal mixed-case text. */ text-transform: none; font-weight: 450; letter-spacing: .01em; /* Fix, per Dave: "the type in the Wizard needs to be a little bit larger. It's hard to see at some monitor[s]." The base rule (much earlier in this file) had trimmed this all the way down to 9px over several rounds - bumped back up to 11px here. */ font-size: 11px; } /* Done + genuinely checkmarked (yes-answered yesno, or any non-yesno "done" kind - matches the same showCheck logic already in updateTrail()): pure white label text, dark circle to the left holding the white checkmark icon, pill slightly more visible than the base translucent fill. The circle only shows once the checkmark SVG is actually injected (:has() - falls back to a plain label-only pill on old engines, which is still correct for the "no" case just below). */ .tunnel-chip.is-done { /* Per Dave (this round): "no pill button shapes at all" - the translucent fill/border chrome this state used to paint is gone; nothing left to set here (the base .tunnel-chip rule above already has no box). */ } .tunnel-chip.is-done .tunnel-chip__label { color: #ffffff; } /* Per Dave (this round): "remove the circles behind the checkmarks and just have checkmarks" - dot slot still occupies its layout space (so the checkmark keeps its usual position/spacing) but no longer paints a circle behind it. Check color set explicitly to white here since it can no longer lean on the old dark-circle background for contrast. */ .tunnel-chip.is-done:has(.tunnel-chip__dot svg) .tunnel-chip__dot { visibility: visible; display: flex; align-items: center; justify-content: center; background: none; color: #ffffff; } .tunnel-chip.is-done .tunnel-chip__dot svg { opacity: 1; transform: scale(1); } /* Answered "no" (or any done step with no checkmark): per Dave, "just the pure white text without the checkmark" - no circle at all, dot slot collapses out of the layout so the pill hugs the label alone. */ .tunnel-chip.is-done:not(:has(.tunnel-chip__dot svg)) .tunnel-chip__dot { /* Fix (this round): was display:none, which drops this box out of layout entirely and shrinks this chip's row height relative to the checkmarked-done chip - see .tunnel-chip's min-height note above for the full alignment root-cause. visibility:hidden keeps the 11px slot reserved (invisible, but still occupying space) so every chip's row height - and therefore its label's vertical position - stays identical regardless of state. */ visibility: hidden; } .tunnel-chip.is-done:hover .tunnel-chip__label { /* Per Dave (this round): no pill fill/border to darken on hover anymore - the click affordance now reads purely through the label's own opacity lift (still fully white/legible, was already white at rest too). */ color: #ffffff; opacity: .75; } .tunnel-chip.is-done:hover .tunnel-chip__dot::before { background: none; } /* Current step: no checkmark yet (nothing to show in the circle), but should still read as "here" rather than ghosted - white text, a slightly brighter pill border than the base/future state, dot slot collapsed (same reasoning as the "no" case above - nothing to put in it yet). */ .tunnel-chip.is-current .tunnel-chip__dot { /* Fix (this round): same display->visibility swap as the is-done-no-check rule above and for the same reason - see .tunnel-chip's min-height note. */ visibility: hidden; } /* Per Dave (this round): "no pill button shapes at all" - the old active state was a pulsing box-shadow drawn around the pill's own border/fill box; with that box gone there's nothing left for a box-shadow to outline (it would just draw a ghost rectangle around the bare text, which still reads as an unwanted button shape). The active step now reads purely through its own label styling instead: full white (already set via the base, non-override .tunnel-chip.is-current .tunnel-chip__label rule earlier in this file) plus a bit of extra weight here so it's clearly the current step at a glance, no glow/box needed. tunnelChipCurrentPulse keyframes block removed - nothing references it anymore. REVERSED (this round), per Dave: "DON'T have the current/active text bolder than the rest of the text - make it identical to the treatment of the previous ones - the differentiator now is the horizontal line, not heavier - so we don't have 50 different font styles going on." The .tunnel-active-indicator bar (added since the above 650 was written) already marks the current step visually - this extra weight is redundant on top of it and is exactly the "different font style" Dave's flagging. Dropped to match the shared base .tunnel-chip__label weight (450) so is-done/is-current/is-future all render at the identical weight; only color (white vs ghosted) and the indicator bar tell them apart now. This rule intentionally left in place (rather than deleted) so it's obvious at a glance that is-current's weight is a deliberate match, not an oversight. */ .tunnel-chip.is-current .tunnel-chip__label { font-weight: 450; } /* Future step: ghosted text only, no box. */ .tunnel-chip.is-future { } .tunnel-chip.is-future .tunnel-chip__dot { /* Fix (this round): same display->visibility swap as above, same reason. */ visibility: hidden; } /* ========================================================================== */ /* Per Dave: on short browser windows (a laptop with a small, non-maximized browser window - not just a narrow one) the top band's content ("You're all set." + the chip trail) was getting clipped at the bottom of the viewport. The top band's min-height is a percentage of the *viewport*, so on short viewports it never actually shrinks - only the padding/ font-sizes/gaps inside it do here, so the logo, headline, and full chip trail reliably fit without clipping even at ~650-700px tall windows. */ @media (max-height: 760px) { #webyayTunnel { /* Item 7: same ~15% trim applied here in step with the base value. */ /* REGRESSION FIX (this round), item 5a: same 13% trim as the base value above, applied here in step: 12% * 0.87 = 10.44%, rounded to 10.5%. */ /* Per Dave (this round), item 1: same 15% trim as the base value above, applied here in step: 10.5% * 0.85 = 8.925%, rounded to 8.9%. */ --tunnel-top-height: 8.9%; } .tunnel-top__logo { height: 32px; } .tunnel-top__close { padding: 8px 18px; font-size: 10px; } .tunnel-top__headline { /* Proportionally tighter than the base 8px/14px (round 13's headline- to-trail spacing bump) but still a real, non-zero gap - keeps the short-viewport clipping fix from an earlier round intact while still giving the headline and chip trail some breathing room. */ /* Left value switched to --tunnel-content-left in step with the base rule above, so short-viewport windows keep the same monitor-aligned left edge (round 49+, item 4). */ /* Per Dave (this round), item 3: same padding-top restoration as the base rule above, scaled down proportionally (short-viewport windows still need to conserve vertical space) - 2px -> 6px. Latest round, item 3: paired with the base rule's padding-bottom halving (3px -> 1.5px) - halved here too. */ /* Per Dave (this round): "throughout" - same +9px headline-down nudge as the base rule above (17px -> 26px), applied here too so short browser windows get the same lowered header. */ /* Per Dave (latest round): "lower that throughout about 7 pixels" - same +7px bump as the base rule above (15px -> 22px), kept in step so short browser windows get the same lowered header. */ padding: 22px 20px 1.5px var(--tunnel-content-left); } .tunnel-top__headline h2 { /* Per Dave (round 45+): scaled up in step with the new base clamp (34-68px) so short-viewport windows still get a visibly big/bold headline, just proportionally smaller than the full-height version. */ /* Per Dave (round 46+): scaled back down 0.8x in step with the base clamp's 20% reduction (24->19.2->19px, 3.4vw->2.72vw->2.7vw, 40->32->32px). */ font-size: clamp(19px, 2.7vw, 32px); /* Per Dave (round 50+): bumped in tandem with the base h2 rule above (1.15 -> 1.3) so descenders don't clip on short-viewport windows either. */ line-height: 1.3; } .tunnel-trail { /* Left value switched to --tunnel-content-left in step with the base rule above (round 49+, item 4). Latest round, item 3: top padding halved (5px -> 2.5px) in step with the headline's own padding-bottom halving above, so the short- viewport headline-to-dot gap is cut proportionally too. */ padding: 2.5px 20px 5px var(--tunnel-content-left); /* FIX (this round), per Dave: "header is now so low it's on top of the pill buttons." Root cause: the base (non-short-viewport) .tunnel-trail rule picked up a new +14px margin-top this round (see that rule above, "more padding between buttons and header") - but this max-height override never explicitly reset margin-top, so on a short browser window that same +14px kept applying on TOP of this block's already-tight padding, pushing the header/trail combo taller than the shrunk --tunnel-top-height ceiling here and causing the overlap Dave saw. Scaled proportionally smaller for this tighter layout instead of inheriting the full-height value unchanged. */ margin-top: 8px; } .tunnel-chip__label { /* Per Dave (latest round, item 3b): bumped +2px in step with the base rule above (10px -> 12px). Per Dave (this round): trimmed back down 2px in step with the base rule's 13px -> 11px cut, so short-viewport windows stay proportionally smaller/thinner too (12px -> 10px). Per Dave (this round): "smaller type" - trimmed in step with the base rule's 11px -> 9px cut (10px -> 8px). Fix, per Dave: "the type in the Wizard needs to be a little bit larger" - bumped back up in step with the base rule's 9px -> 11px fix (8px -> 10px). */ font-size: 10px; } /* FIX (this round), per Dave: "the dark circle is huge here and blowing out of the pill button." Root cause: this override is a leftover from the OLD column-layout timeline (dot stacked above the label, in its own 34px-tall slot) - it was never updated when the trail was redesigned into the current compact row-layout pills (13px dot inline with the label, see the base, non-media .tunnel-chip__dot rule earlier in this file). On a short browser window this 26px override was winning over that 13px base value, rendering a checkmark circle roughly 2x the height of the 22px-tall pill it sits inside - genuinely "blowing out" of it. Matches the base rule's 13px now (no separate short-viewport shrink needed - the pill itself is already a fixed, small size at every window height) and margin-bottom is 0, not negative - that offset only ever made sense for the old stacked layout. */ .tunnel-chip__dot { width: 13px; height: 13px; flex: 0 0 13px; margin-bottom: 0; } .tunnel-trail__seg { margin-top: 12px; } /* Per Dave (round 51+, item 2): the fixed -9px bleed here is now dead - positionTrailSegments() in tunnel.js measures real dot/segment geometry at runtime (including on this short-viewport layout, since it re-measures on resize) and sets --seg-left/--seg-width directly, so no separate short-viewport override is needed here any more. */ .tunnel-chip.is-done .tunnel-chip__dot::before { /* This round, item 4b: matches the base rule's further 20%-smaller cut above (now genuinely 17px * 0.8 = 13.6, rounded to 14px - the base rule has been corrected to match this value this round). Since the base is now also 14px, this short-viewport override stays the same number but is left explicit for clarity. */ width: 14px; height: 14px; } /* Per Dave (round 49+, item 2): halved in step with the base is-current rule above (17px -> 9px) so the short-viewport active dot stays proportionally half-sized too, not just the base one. */ .tunnel-chip.is-current .tunnel-chip__dot::before { /* Per Dave (round 51+, item 7): matches the hollow-ring treatment set on the base is-current rule above, just at the short-viewport's slightly smaller 9px diameter. */ /* Per Dave (this round), item 8: same ~half-size + thinner-stroke cut as the base is-current rule above, scaled to this short-viewport's proportionally smaller dot slot (9px -> 5px, matching the base). */ width: 5px; height: 5px; box-sizing: border-box; background: transparent; border: 1px solid #ffffff; } .tunnel-chip__dot svg { /* This round, item 4b: matches the base checkmark's 20%-smaller cut above (11px -> 9px). */ width: 9px; height: 9px; } } /* ---------- MIDDLE BAND (the tunnel) ---------- Per Dave (v6): the laptop-mockup + live-site preview that used to only exist on the intro slide is now a PERSISTENT fixture pinned to the left of .tunnel-mid for the ENTIRE tunnel flow, not just the first few panels. .tunnel-mid is now a two-column flex row: a fixed-width left column (.tunnel-mid__preview) holding that laptop/iframe, and a right column (.tunnel-mid__content) holding the existing card track/carousel. The preview column is built once in tunnel.js's buildRoot() as a sibling of the card track (never inside any one .tunnel-card), so it never re-renders, reloads, or animates away as the user moves between slides - only the right-hand card content transitions. */ .tunnel-mid { position: relative; /* Was `flex: 0 0 var(--tunnel-mid-height); height: var(--tunnel-mid-height);` (a hard 60% of viewport). Changed to flex-grow so this band always fills exactly whatever space the top/bottom bands don't use - see the black-strip root-cause note on .tunnel-top above. This is what guarantees the three bands sum to 100% in every case (any viewport height, any media-query breakpoint, any content-driven top-band growth), not just the specific percentages that happened to add up before. */ flex: 1 1 auto; min-height: 0; overflow: hidden; display: flex; align-items: stretch; /* Per Dave (round 23): was flex-start, which pinned the monitor+content pair to the left edge - any extra browser width just widened the gap between them as .tunnel-mid__content (flex:1 1 auto) grew to fill it. .tunnel-mid__unit below now wraps both columns together with a capped max-width, so centering it here turns any extra width into symmetric outer whitespace on both sides instead. */ justify-content: center; background: #ffffff; } /* Per Dave (round 23) - MAJOR LAYOUT FIX: the monitor (.tunnel-mid__preview) and the card content (.tunnel-mid__content) used to be direct children of .tunnel-mid itself - a fixed-width left column plus a flex:1 1 auto right column that simply absorbed whatever width was left over. That meant the monitor stayed pinned to the left edge at any browser width while the gap to the content column stretched or shrank independently as the window resized - sometimes way too far apart, sometimes crowded. This wrapper groups both columns into one flex row with a single FIXED gap between them that never grows or shrinks on its own, capped at a max-width so the pair doesn't stretch apart on ultra-wide windows either. .tunnel-mid above centers this unit (justify-content:center), so the whole monitor+content pair now moves and recenters together as one block - extra browser width becomes equal outer whitespace on the far left and far right, never extra space between the two columns. Per Dave (round 27): the round-23 56px gap read as "incredibly wide / ridiculous" on a narrower browser window, where he asked for the monitor and text to sit no more than ~40px apart. Verified via Playwright (getBoundingClientRect on .tunnel-intro__visual's right edge vs. .tunnel-mid__content's left edge, i.e. the REAL rendered gap, not just this CSS `gap` value) at 1024x800 up through 1920x900 and 600-900px viewport heights: .tunnel-mid__preview is flex:0 0 auto with no width of its own set in CSS, so its box already hugs .tunnel-intro__visual's JS-computed calc(587px * var(--intro-scale)) width exactly at every size tested - the measured visible gap always matched this `gap` value 1:1, never more. So there was no separate width/flex-basis mismatch bug to fix here (the column was never wider than the monitor graphic it holds); the whole 56px was genuinely just wider than Dave wants. Dropped straight to 40px, which the same Playwright pass confirms now measures as a true ~40px monitor-graphic-edge-to-text-column gap at every tested size. Round 31, per Dave: "they need to be maybe 30 pixels apart from each other no matter how big or small the browser window is." Re-verified via Playwright across every category (intro, website-changes, pages, logo, care, payment, summary) at 1024/1150/1280/1440/1680/1920px - both .tunnel-mid__preview (flex:0 0 auto, content-sized, never stretches) and .tunnel-mid__content (flex:1 1 auto, but the card inside it is anchored left:0 per the round-30 fix below, so it never re-centers into leftover width) hug this `gap` value exactly at every width tested, with zero drift - so a single fixed 30px value here is sufficient on its own; no per-slide overrides were found or needed. Round 32, per Dave: the whole monitor+content unit sat too close to the browser's left edge ("shift all of that stuff inside the white tunnel together, about 50 pixels to the right"). Added padding-left:50px here rather than touching the `gap` (which controls the 30px monitor-to- content spacing Dave already likes and explicitly wants kept). Because the page has a global box-sizing:border-box reset, this padding is absorbed inside the existing max-width:1440px box instead of growing it - so the fix behaves identically in both layout modes this unit runs in: below ~1440px viewport width the unit still stretches to fill .tunnel-mid (flex:1 1 auto) and the padding simply pushes the monitor 50px off the true left edge; above ~1440px the unit is centered via .tunnel-mid's justify-content:center and the padding shifts the monitor 50px off the unit's own (still-centered) left edge. Either way the monitor's on-screen left edge moves right by a consistent ~50px at every width, the .tunnel-mid__content column simply absorbs the 50px out of its own flex:1 1 auto space, and the 30px gap value below is completely untouched. Verified via Playwright at 1024/1280/1440/1680/1920px. */ .tunnel-mid__unit { display: flex; align-items: stretch; flex: 1 1 auto; max-width: 1440px; min-width: 0; /* Per Dave (latest round, item 8): "too much padding between the monitor and the text on the right... make it half that much" - halved from 30px to 15px. This is the single shared gap between .tunnel-mid__preview (monitor) and .tunnel-mid__content (text column); reducing it here pulls the text column left toward the monitor (monitor itself is untouched - it's flex:0 0 auto and never moves). Verified via Playwright at 1440px and 1920px: the rendered gap is now visibly half what it was, with no text/button overlap onto the monitor art. */ gap: 15px; /* Per Dave (latest round): shifted right 80px in step with --tunnel-content-left above (50px -> 130px) so the monitor/text column kept sharing the same left edge as the top band's headline/timeline. Per Dave (round 52+, item 4): "middle content... shift LEFT 25px" - a separate, deliberate request from item 3's top-band-right-25px above. This deliberately BREAKS the previous sync with --tunnel-content-left, so this rule now uses its own independent variable (--tunnel-mid-content-left) instead of a hardcoded value tied to that var, set to 130px - 25px = 105px. The top band's offset now increases independently (see --tunnel-content-left above), so the two no longer share a left edge - a ~50px gap between them (25px + 25px in opposite directions from the old shared 130px position). */ padding-left: var(--tunnel-mid-content-left); } /* Per Dave (v8): the monitor now scales to fill nearly the full HEIGHT of the white .tunnel-mid band (~15px clearance top/bottom - see sizeMonitorPreview() in tunnel.js), which at the monitor art's fixed 587x435 aspect ratio makes it considerably wider than the old fixed-37% column could hold without clipping/overflowing into the content column. Switched this column from a fixed 37% width to flex:0 0 auto (content- sized) with a little horizontal padding, so its width always exactly matches whatever the height-driven scale computes, and the right-hand .tunnel-mid__content column (flex:1 1 auto) simply absorbs whatever width remains - no fixed percentage to fall out of sync with the JS scale math. sizeMonitorPreview() still caps the scale against .tunnel-mid's total width as a safety ceiling so the content column never gets starved. */ .tunnel-mid__preview { flex: 0 0 auto; position: relative; height: 100%; /* Per Dave (round 23): the old 8px symmetric padding + 20px extra left margin (ad hoc nudges from earlier rounds to control the monitor-to- content gap and keep it off the browser edge) are both gone - the fixed 56px gap now lives once on .tunnel-mid__unit's own `gap` (see above), and .tunnel-mid centering that whole unit is what keeps it off the edge, so neither hack is needed here anymore. */ display: flex; /* Per Dave (round 22): the "View Your New Site" pill is no longer a stacked flex sibling below the monitor art (that pushed/shrank the monitor to make room for it, which Dave explicitly did not want). It's now absolutely positioned INSIDE .tunnel-intro__stage, overlapping the monitor graphic itself in the gap between the bezel and the stand base (see .tunnel-view-newsite-pill below) - so this column goes back to simply centering the one visual child, same as before the pill existed. */ align-items: center; justify-content: center; background: #ffffff; } /* Per Dave (round 22): the "View Your New Site" pill moved from below the monitor art (which forced sizeMonitorPreview() to shrink the monitor to reserve room for it - Dave explicitly said don't shrink the monitor) to sitting directly ON TOP of the monitor graphic, in the flat open gap between the bottom of the bezel and the stand's base, beside the narrow neck. It's a child of .tunnel-intro__stage (like .tunnel-intro__frame and .tunnel-intro__screen), so the SAME scale(var(--intro-scale)) transform that sizes the whole monitor also scales this button's position, padding and font proportionally at any viewport height - no separate JS math needed, and it can never push or resize the monitor since it no longer participates in that flex layout at all. Per Dave (later round): moved from the RIGHT flank of the stand neck to the LEFT flank, still below the bezel's bottom edge - measured off assets/img/desktop-monitor-v2.jpg's native 587x435 canvas (bezel bottom edge ~y354, stand neck spans x233-357/y356-412, monitor's left edge ~x16). The open flank to the LEFT of the neck is x16-233, centered at x124 - mirrors the old right-side x467 position onto the left third of the canvas, same y384 depth below the bezel. */ .tunnel-view-newsite-pill { position: absolute; /* Per Dave: moved up 4px and left 20px (top 384->380, left 124->104). */ left: 104px; top: 380px; transform: translate(-50%, -50%); z-index: 4; display: inline-flex; align-items: center; justify-content: center; /* Fix (this round), per Dave: "remove pill outline on this button and have a '+' to the right of the text, just like the below buttons, with same exact size/styling as the 7 [Foundation] buttons below it (mobile and desktop)." Border/background/pill-shape chrome removed entirely (same "flat text + plus icon" treatment as .tunnel-foundation-pill), and font-size/padding matched to that same desktop rule's values (9.4px / 6.8px-22px-6.8px-12px) instead of this pill's own old 10.8px/7.2px-19.2px pair. gap added for the new plus icon (markup updated in tunnel.js to include a .tunnel-foundation-pill__plus span, reusing that exact shared icon rather than a new one-off). The transform:translate(-50%,-50%) above still keeps it centered on the same anchor point on the monitor graphic regardless of this size change. */ padding: 6.8px 12px; /* Fix (this round), per Dave, desktop only: "move the text 'View Your New Site' over to the right four pixels so it's closer to the plus button... right now the plus symbol and the text are too spread apart." Same fix already applied to the mobile version of this pill below (gap 15px -> 11px, see the --intro-scale-compensated mobile override) - this brings the desktop base rule in line with that same 4px trim. */ gap: 11px; border: none; background: none; /* Per Dave: "ALWAYS use pill shape instead of square in these circumstances on hover, never square." No visible radius needed while background:none above, but the hover rule below fills a solid color - without this, that fill paints as a hard-edged rectangle instead of a pill. Set here so it's always pill-shaped the instant a background appears, on hover or otherwise. */ border-radius: 999px; /* NOT var(--ink) - this pill lives inside .tunnel-intro__stage, a sibling of .tunnel-card rather than a descendant of it, so it never picks up .tunnel-card's local --ink redefinition (light cream -> dark). Using the root-scoped var(--ink) here would render near-invisible light text on this pill's white background - hardcoding the same #1c242a dark ink .tunnel-yesno__btn effectively resolves to instead. */ color: #1c242a; font-family: "Plus Jakarta Sans", Arial, sans-serif; font-size: 9.4px; /* Per Dave: "too bold - make this a thinner font, lighter weight." 600 -> 400 (regular). Mobile has its own separate rule further down this file (see the intro-scale-compensated override) - untouched here, scoped to desktop only per this being the desktop base rule. */ font-weight: 400; letter-spacing: .02em; text-decoration: none; cursor: pointer; white-space: nowrap; transition: all .22s ease; } /* The shared .tunnel-foundation-pill__plus icon defaults to position:absolute (right:8.5px off its OWN button's edge) - correct for the still-bordered desktop Foundation pills it was built for, but wrong here: this pill is inline-flex with a real `gap` above (matching the Foundation pills' now-flattened mobile treatment), so the plus needs to be a normal flex child instead, flowing right after the label with that gap, on every viewport - not anchored to a fixed spot on the button's own edge. */ .tunnel-view-newsite-pill .tunnel-foundation-pill__plus { position: relative; top: auto; right: auto; transform: none; flex: 0 0 7.7px; } .tunnel-view-newsite-pill:hover .tunnel-foundation-pill__plus, .tunnel-view-newsite-pill:focus-visible .tunnel-foundation-pill__plus { transform: rotate(45deg); } /* Per Dave: "the + should be off-white on hover." The plus bars default to a dark, muted rgba(28,36,42,.35) (see the shared base .tunnel-foundation-pill__plus::before/::after rule) - fine at rest against this pill's white/transparent background, but nearly invisible once the hover fill below paints the whole pill solid teal. The other 7 buttons already get a hover color swap (see .tunnel-foundation-pill:hover .tunnel-foundation-pill__plus::before/ ::after elsewhere in this file) - this pill needed its own copy since it doesn't share the .tunnel-foundation-pill class itself. */ .tunnel-view-newsite-pill:hover .tunnel-foundation-pill__plus::before, .tunnel-view-newsite-pill:hover .tunnel-foundation-pill__plus::after, .tunnel-view-newsite-pill:focus-visible .tunnel-foundation-pill__plus::before, .tunnel-view-newsite-pill:focus-visible .tunnel-foundation-pill__plus::after { background: #f5f4f1 !important; } /* Fix (this round), per Dave: "on hover this button needs to be the solid primary color and the text needs to be white on hover" - overrides the previous faded-outline hover (matches this session's established "hover = solid accent + white text" convention used on the other pills/ buttons, e.g. .tunnel-care-handoff-pill:hover below). */ .tunnel-view-newsite-pill:hover, .tunnel-view-newsite-pill:focus-visible { background: var(--tunnel-teal-bg); color: #ffffff; } /* Per Dave (this round), item 6: only on the Website Changes slide, this pill's text swaps to "Check Site for Changes" (see syncNewSitePill() in tunnel.js) and gets a pulsing/throbbing effect to draw attention - reuses the EXACT same tunnelNextPulse keyframe already established on the Secure Checkout button (.tunnel-checkout-btn), same as Dave's reference ("like we did on some of the other [buttons]"), rather than inventing a new animation. Reverts (class removed) on every other slide. */ /* Item 3 (this round), per Dave: "a little bit more faint or faded on the throbbing here, it's a little bit much I think" - re. this exact pill's "Check Site for Changes" pulse. tunnelNextPulse (the shared keyframe this used to reuse) is also used by .tunnel-nav__btn--next and .tunnel-checkout-btn, which Dave did NOT flag - editing it directly would have quietly changed those two as well. Split off a dedicated, fainter keyframe just for this pill instead: peak shadow opacity dialed down (.55 -> .3) and the spread trimmed (10px -> 7px), a moderate reduction per this session's "no extreme moves" standard, not a near-invisible one. */ @keyframes tunnelNewSitePulse { 0%, 100% { box-shadow: 0 0 0 0 rgba(94,115,135,.3); } 50% { box-shadow: 0 0 0 7px rgba(94,115,135,0); } } .tunnel-view-newsite-pill.is-pulsing { animation: tunnelNewSitePulse 2.2s ease-in-out infinite; } /* Right column - holds the card track. Narrower than the old full-width .tunnel-mid now that the left column is permanently occupied; the .tunnel-card width/max-width rules below were updated to fit within it (percentage-based max-width instead of a viewport-relative one, since this column is narrower than the full viewport). */ /* Per Dave (supersedes the earlier "never allow scrolling" rule): this column must be scrollable vertically in case content is taller than the available space (e.g. a short browser window), but WITHOUT a visible scrollbar - wheel/trackpad/touch scrolling still works, the track/thumb itself just never renders. overflow-y:auto still lets an absolutely positioned, overflowing .tunnel-card (see .tunnel-card below) be reached by scrolling even though this column's own height is fixed. */ .tunnel-mid__content { position: relative; flex: 1 1 auto; height: 100%; overflow-y: auto; overflow-x: hidden; scrollbar-width: none; /* Firefox */ -ms-overflow-style: none; /* legacy Edge/IE */ } /* Item 10 (this round): one-time entrance animation for the tunnel's very first open only (see playIntroEntrance() in tunnel.js) - the text/question column glides in from the right (same direction as the regular slide-to- slide card transition), while the persistent monitor+"View Your New Site" column glides in from the left, timed to finish together so they visibly "meet in the middle." Duration/easing matches the main card transition (.65s var(--tunnel-ease), see .tunnel-card's `transition`, item 12 this round) for a consistent feel. Classes are added/removed by JS around a single playback - not a permanently-attached rule - so no later slide navigation (which leaves both of these elements static/persistent per buildRoot()'s design) is affected. */ @keyframes tunnelIntroContentIn { from { opacity: 0; transform: translateX(70px); } to { opacity: 1; transform: translateX(0); } } @keyframes tunnelIntroPreviewIn { from { opacity: 0; transform: translateX(-70px); } to { opacity: 1; transform: translateX(0); } } .tunnel-mid__content.tunnel-intro-anim-content { animation: tunnelIntroContentIn .65s var(--tunnel-ease) both; } .tunnel-mid__preview.tunnel-intro-anim-preview { animation: tunnelIntroPreviewIn .65s var(--tunnel-ease) both; } .tunnel-mid__content::-webkit-scrollbar { display: none; width: 0; height: 0; } .tunnel-track { position: relative; width: 100%; height: 100%; display: flex; align-items: center; justify-content: center; } /* Per Dave (round 45+, latest of several relocations this session - moved from the "Hosting & Care" slide to "Logo Design", then to a card-content position, then to the gray .tunnel-bottom band, and now here): reuses the same looping client-logo marquee already on the stock landing page's Logo Add-on card (.logo-addon-marquee in landingpage-template/assets/css/ styles.css - same client-logo-strip.png asset, same scroll/loop behavior). Per Dave's latest, most specific instruction: it belongs "in the 'Do you need a new logo?' section, BEFORE they click yes... underneath that yes/no question... in between the computer frame and the right side of the browser window." It's now built directly inside the Logo Design card's .tunnel-qa markup (see the 'logo' category's kind:'yesno' branch in buildCards(), tunnel.js) as a normal in-flow block below the question + Yes/No buttons - NOT absolutely positioned/pinned to the bottom band anymore, since .tunnel-qa's own containing column (.tunnel-mid__content) IS already "between the monitor and the right edge of the browser." Because it's a plain child of .tunnel-qa, it disappears automatically the instant `.tunnel-qa.is-collapsed` is applied on "Yes" (see the click handler in tunnel.js) - no separate show/hide toggle is needed, and it can never reappear once the card expands into the textarea/upload fields. Per Dave: kept noticeably lighter/more subtle than a plain grayscale treatment - grayscale plus a low opacity so the logos read as a faint gray watermark rather than a bold logo strip. */ .tunnel-logo-marquee { /* Fix (this round), per Dave (repeat complaint on the Logo Design slide's Yes/No buttons sitting too high/low vs. every other slide): this element used to be `position:relative` (plain in-flow), which meant its 68px height + 42px margin-top counted toward .tunnel-card's own total height - and since that card is vertically CENTERED (top:40% + translateY(-50%)), the extra height shifted the Yes/No row above it up relative to every other yesno-kind slide (none of which have a marquee). A prior attempt compensated with a big margin-top on the eyebrow instead of fixing this - that overshot at shorter browser windows (added height pushed the whole box past this column's max-height, triggering a scroll). Root-cause fix instead: position this absolutely so it NEVER contributes to .tunnel-card's height at all - the card (the nearest positioned ancestor) centers itself exactly like every other yesno slide, no compensation needed anywhere. `top:100%` (of the card's own, now-marquee-free height) + the same 42px margin-top lands this in the identical on-screen spot it always occupied, directly below the Yes/No row. */ position: absolute; top: 100%; left: 0; /* Per Dave (latest round): "You have this logo animated banner incredibly tiny... it stops in the middle. It needs to go from the monitor over to the right side of the browser." The old `max-width: var(--tunnel-card-w)` capped this at the same ~465px narrow text-column width as the question/buttons above it - nowhere near wide enough to read as a real banner, and with only ~2 small logo images' worth of scrollable content inside a box nearly as wide as they were, the translateX(-50%) loop had almost no room to visibly travel before resetting, which is what read as "stops in the middle" rather than a genuine bug in the loop math itself. FIX (this round): width is now set inline (px) by sizeLogoMarquee() in tunnel.js, which measures the LIVE rendered width of .tunnel-mid__content (the actual monitor-edge-to-browser-edge column) on load/resize and lands the marquee's right edge flush with that column's real right edge - this CSS width:100% is just the fallback before JS runs. That alone wasn't enough while this element lived inside .tunnel-qa (~445px wide, overflow:hidden) - no CSS overflow combination lets one axis stay clipped while the other is genuinely "visible" (mixing overflow-x:visible with overflow-y:hidden computes to 'auto', which still clips). So this element is no longer a child of .tunnel-qa at all - it's built as a sibling appended directly to .tunnel-card in tunnel.js's buildCards() (which has its own overflow:visible), so its wide inline width is never clipped back down to the narrow question/button column. It still visually sits directly below the Yes/No row via normal document flow. Show/hide on Yes/No is now handled explicitly via the .is-collapsed class below (previously free-rode qa's own collapse, since it was qa's child). */ width: 100%; /* Doubled from 26px (per Dave: "at least twice that big") - the logo images below are height:100%/width:auto, so this single value also doubles their rendered width proportionally, giving the loop far more real scrollable distance to travel, which combined with the wider container above is what actually fixes the "stops in the middle" look. */ /* Per Dave (latest round): scaled up another 30% (52px -> ~68px) and nudged 20px further down (22px -> 42px margin-top) - the images below are still height:100%/width:auto so this single height change scales the whole marquee (track + logos) proportionally, same trick as the original doubling above. */ height: 68px; /* Per Dave (this round): "a little bit low, raise it about 28 pixels" - 42px -> 14px. Everything else about this element (width/height/timing/ the is-collapsed toggle) is untouched. */ margin-top: 14px; overflow: hidden; opacity: 1; visibility: visible; pointer-events: none; z-index: 1; max-height: 68px; transition: opacity .3s ease, max-height .42s var(--tunnel-ease), margin-top .42s var(--tunnel-ease); } /* Per Dave: the marquee no longer lives inside .tunnel-qa (see the class comment above), so it no longer disappears for free when qa collapses on "Yes" - this class is toggled explicitly alongside qa.is-collapsed in tunnel.js's data-answer click handler, using the same fade treatment. */ .tunnel-logo-marquee.is-collapsed { opacity: 0; max-height: 0; margin-top: 0; pointer-events: none; } .tunnel-logo-marquee__track { display: flex; align-items: center; height: 100%; width: max-content; /* Per Dave: "just a tad faster" - 84s -> 70s (~17% shorter duration, i.e. faster) at the same distance/loop, not a drastic change. The keyframes below already animate a full, seamless 0 -> -50% loop across the two duplicated .tunnel-logo-marquee__img tracks (see the markup in tunnel.js's 'logo' category branch) - two copies of the same strip laid side by side, translated left by exactly one copy's width, so it wraps with no visible seam/reset. That loop was already mechanically seamless; only the container/image size (above) was making it imperceptible. */ animation: tunnelCareMarquee 70s linear infinite reverse; will-change: transform; } .tunnel-logo-marquee__img { display: block; height: 100%; width: auto; flex: 0 0 auto; filter: grayscale(1); /* Per Dave (latest round): logos were reading as too faint/washed out at .35 - bumped up modestly to .55 so they're noticeably more visible while still staying a subtle, muted watermark-style strip (not a bold logo bar). */ opacity: .55; } @keyframes tunnelCareMarquee { from { transform: translateX(0); } to { transform: translateX(-50%); } } /* Round 36+: the old max-height:760px override (originally compensating for less vertical room in the tall white mid-band card) no longer applies now that the marquee lives in the fixed-role gray .tunnel-bottom band at a slim 30px instead of the card-relative 68px - nothing left to compensate for. */ .tunnel-card { position: absolute; /* REAL ROOT CAUSE (this round) of the Secure Checkout button's left-edge crop, per Dave's 8th report on this: every prior attempt (raising .tunnel-checkout-btn's own z-index to 20, then switching .tunnel-summary off overflow-x:hidden) treated this as either a stacking-order problem on the BUTTON or a clipping problem on its SCROLL ANCESTOR - both real things to check, neither was the actual cause. The actual cause: this card has `transform` set unconditionally below (translateY/translateX/ scale), and ANY non-none `transform` creates a brand new CSS stacking context for the element - so .tunnel-checkout-btn's z-index:20 has only ever been compared against OTHER elements inside .tunnel-card's own local context, never against elements outside it (like the persistent monitor mockup in the sibling .tunnel-mid__preview column, which sits in a DIFFERENT branch of the tree). What actually decides whether the monitor paints over the card (or vice versa) is where THIS ELEMENT itself - the whole stacking context, as one unit - ranks in ITS OWN parent's stacking order. This card never had an explicit z-index of its own (auto = stacking level 0), while .tunnel-intro__mask (part of the monitor graphic, see that rule elsewhere in this file) has z-index:5 - so at some widths/selections the mask's higher explicit level won out over this card's implicit "0", clipping a sliver of whatever card content happened to sit near that boundary (the Secure Checkout button, given its position). Giving THIS element - not the button buried inside it - an explicit z-index above the monitor's highest internal value (5) is the fix that actually reaches the real comparison. */ z-index: 10; /* ROUND 30 - ROOT CAUSE of the recurring "huge monitor-to-content gap" bug (reported broken across multiple prior rounds despite each one re-measuring and closing the ticket): every previous round measured the gap as getBoundingClientRect() of .tunnel-mid__content's own box edge vs. the monitor's edge, which is genuinely a fixed 40px (the .tunnel-mid__unit `gap` value) at every width - that measurement was never wrong. But .tunnel-mid__content itself is flex:1 1 auto, so its box keeps growing to absorb all leftover browser width. This card was `left:50%` + `translate(-50%, -50%)` - CENTERED inside that ever- growing box, not anchored near its left edge. At a narrow width where the content column happens to be close to the card's own 465px width, centering looks fine (near-zero slack). At realistic/wide desktop widths (1150px+), the column becomes far wider than the fixed-width card, and centering strands the actual visible text in the middle of that leftover space - which reads as a large blank gap between the monitor and the text, exactly what Dave kept reporting, even though the 40px CSS gap value itself was never the problem. Verified via Playwright: at 1440px the text block was rendered ~134px further right than the content column's own left edge (in addition to the 40px unit gap), i.e. ~174px of visible whitespace - see tunnel-fix-round30/. Fixed by anchoring the card to the LEFT edge of .tunnel-mid__content (left:0, vertical centering only) instead of centering it inside the column, so the text always starts immediately after the fixed 40px gap at any viewport width, matching how it already looked (correctly) at narrower widths. */ left: 0; /* Per Dave (round 35): every card (and its monitor-preview neighbor, both riding this same vertical anchor via translateY(-50%) below) read as "quite low" in the white .tunnel-mid band even though 50% is a true mathematical center of that band - because each card's own content is top-anchored inside itself (heading/tiles/etc. all start at the card's top edge and grow downward), true vertical centering of the CARD puts most of the visible text in the lower half of the band, which is what reads as low. Moved the anchor up to 42% (was 50%) - still centered enough that short cards (e.g. yes/no-only slides) don't look pinned to the top, but the extra ~8% of band height (~40px at this band's ~525px height) now sits below the content instead of above it, pulling text toward the upper-middle of the band as Dave asked. Verified via Playwright across the changes/intro/care slides - no clipping against .tunnel-top or .tunnel-bottom at any of them (see tunnel-fix-round35/). */ /* Round 36+ REGRESSION FIX: 42% (round 35's "pull content up" fix) pushed the tallest cards' eyebrow labels (e.g. Website Changes with its Font Changes panel open) up far enough to visibly touch/overlap the teal top band - a hard visual bug Dave flagged as worse than the original "too low" complaint 42% was meant to solve. Dialed back to 46%, roughly the midpoint between the original 50% (too low) and the 42% overcorrection (touching the top band) - erring slightly toward more top clearance since touching is the harder failure of the two. */ /* Per Dave (this round): "all of this text content on the right needs to move up... too much padding on top, and then it runs into the gray bar at the bottom" - this vertical centering anchor (top + translateY(-50%) below) IS the real "top padding" for this column: there's no literal padding-top on .tunnel-mid__content or .tunnel-card, the gap above short cards (e.g. the Website Changes tile-selection screen, Hc~216px) is purely a byproduct of centering a short box in a much taller column. Root-cause check via Playwright at 1440x900: with the OLD 46%/90% pair, a short card's top gap measured ~158px while its bottom gap was ~204px - confirming the "huge top padding" complaint - but the TALLEST cards (the changes-detail sub-panels, already capped at the old 90% max-height below) measured only ~5-9px of top clearance, i.e. almost zero headroom, which is exactly why round 36 dialed this anchor back from 42% to 46% in the first place (42% + a 90% cap put those same tall panels into negative territory - real overlap with the teal top band). Lowering only this value would reproduce that exact regression, so it's paired with the max-height reduction below: both moved so the capped-panel top clearance stays mathematically the SAME (~0.01 of the column height, matching the old 46%/90% pair almost exactly - verified via Playwright: ~5-9px before, ~5-9px after, no clipping), while every shorter card's top gap drops a genuine ~22% (e.g. ~158px -> ~123px at 1440x900) and its bottom gap grows in step (~204px -> ~239px) - less padding on top, more breathing room before the gray .tunnel-bottom band, exactly as asked. */ top: 40%; width: var(--tunnel-card-w); /* Was 88vw (viewport-relative) - now that .tunnel-card's containing block is the narrower right-hand .tunnel-mid__content column (not the full viewport, since the left column is permanently occupied by the persistent laptop preview - see .tunnel-mid__preview above), the max-width needs to be relative to that column instead of the viewport, so it can't overflow past its own column. */ max-width: 92%; /* Per Dave (updated): if a card's content still exceeds this, the parent .tunnel-mid__content column now scrolls (with its scrollbar hidden - see above) rather than clipping content unreachably. max-height stays as a soft target so most slides never need to scroll at all. */ /* Paired with the `top` anchor change above (90% -> 78%): keeps the tallest/capped panels' top clearance unchanged (still ~0.01 of the column height, non-clipping - see note above) while freeing up real extra room below them before .tunnel-bottom, instead of just shifting the same fixed-size box higher and leaving the reclaimed space stranded above the panel. Content that already scrolled internally at 90% may now start scrolling a little sooner - an accepted trade-off, since this column's overflow-y:auto scroll fallback (above) was already built specifically for this case. */ max-height: 78%; overflow: visible; transform: translateY(-50%) translateX(0) scale(1); opacity: 1; /* Per Dave: no more "boxes within boxes" - the card is a plain, unboxed content container now (no fill, no border, no radius, no shadow). It sits directly on .tunnel-mid's white background and content flows freely; typography/spacing carry the hierarchy instead of container chrome. Only light breathing-room padding remains so text doesn't press against the edges of the mid band. */ background: transparent; border: none; border-radius: 0; padding: 14px 10px; /* Fix (round 44+), item 2 - per Dave: scrolling a tall category's content all the way down left its trailing OK/Next button flush against the gray .tunnel-bottom band with zero clearance. Tried adding padding-bottom here first, but this card's own box is capped by `max-height: 90%` above while `overflow: visible` lets its real content paint past that cap - trailing padding on THIS capped box gets absorbed into the cap and never actually pushes the visually- overflowing content down (confirmed via Playwright: measured a ~0px gap no matter the padding value here). The real, working fix lives on each panel's own last-child wrapper instead - see .tunnel-3tile-ok-row and .tunnel-pages-flow.is-visible - which are not subject to this card's max-height clamp. */ box-shadow: none; /* Per Dave: the slide transition "just very quickly comes in" instead of visibly sliding. Root cause was the incoming/outgoing translateX distance being only 6% of the card's own width (~37px on the 620px card) combined with a scale(.97) - together those read as a quick fade/settle rather than a clear directional slide. Longer duration + a proper ease-out-expo curve (below) plus a real fixed-pixel travel distance (see .is-prev/.is-next) now produce a visible, elegant slide. Per Dave (round 22): even at .52s/64px the motion still read as "snaps in so quick" - verified empirically with Playwright (sampling computed transform/opacity every ~60ms mid-click) that the .52s/64px animation WAS genuinely running exactly as coded, it just wasn't a big/slow enough move to read as an elegant glide to the eye. Bumped to a longer .7s transform duration and roughly double the travel distance (64px -> 120px, see .is-prev/.is-next below) so the incoming card's glide-in and the outgoing card's fade-out are both unmistakable while watching it. Round 31, item 8, per Dave (referencing Warby Parker's quiz flow as the target feel): .7s read as sluggish rather than elegant once the actual bypass bug below was fixed (real snapping was masking this - with every navigation path now genuinely animating, the plain duration itself became the next thing to tune). Settled on .55s - inside Dave's requested 500-600ms "just right" window - with a smoother, more symmetric ease-out-ish curve. Opacity now finishes noticeably faster (.38s) than the .55s transform, so the incoming card visibly materializes partway through its own slide (rather than the two finishing in lockstep, which read as flatter/less alive) and the outgoing card visibly fades before it's finished sliding away - both halves of the motion play concurrently from the same class-toggle tick (see goToIndex()/updateCardPositions() in tunnel.js - there was never a separate "then" step here), so fade and slide are already choreographed together, not sequential. Round 36, per Dave (THIRD+ round on this same complaint - "still the same, like almost immediate"): investigated from scratch instead of re-trusting the prior rounds' numeric transform sampling. First ruled out DOM recreation - buildCards() in tunnel.js runs exactly ONCE at init (confirmed by grep + reading the init sequence), and every navigation (goToIndex -> updateCardPositions) only ever toggles classes on the SAME persistent card nodes, never rebuilds them, so that classic "no prior painted state to transition from" bug was never in play here. Then re-verified the transition mechanism itself two ways: (1) temporarily forced a 3s transition-duration via an injected style tag and polled getComputedStyle().transform every 200ms - it interpolated smoothly through 15 distinct in-between values from 120px down to 0, proving the CSS engine and the class-toggle timing both genuinely work; (2) polled the REAL .55s/120px animation the same way, every 30ms - it also interpolated smoothly and completed in ~600ms real time, matching the authored durations exactly. So the ROOT CAUSE was never a broken/bypassed transition - it's that 120px (the actual travel distance) is only ~8% of a 1440px-wide viewport, and the opacity fade (.38s) reaches ~90%+ before the transform is even halfway done, so almost the entire move is fully-opaque and nearly- arrived within the eye's first glance - technically animating, but too small/quick a move to ever read as a deliberate "glide in from the right edge" to a human watching it, exactly as Dave described. Fixed by making the travel distance genuinely viewport-scaled (see .is-prev/.is-next/.is-hidden-far below - 70vw instead of a fixed 120px), so the incoming card visibly originates from near the browser's right edge and the outgoing card visibly exits toward the left edge, at any window size. Verified via Playwright video recording (frame-by-frame extraction, not just numeric sampling this time) - see tunnel-fix-transition-final/ - multiple distinct in-between frames now show the card clearly mid-flight across the visible content column, not just a before/after pair. */ /* Item 12 (earlier round), per Dave: "the gliding in from right to left of the next category is still a little too rapid - can you slow it down by like 25%." Actual current values (not the .55s the comments above reference - those went stale after a later untracked tweak) were .52s transform / .4s opacity+filter. Bumped ~25%: .52s -> .65s, .4s -> .5s. Item 13 (this round), per Dave: "slow down the glide in when you hit the next button even more, it's still coming too quickly." Bumped again, ~50%: .65s -> 1s transform, .5s -> .75s opacity+filter. Any JS setTimeout()s that wait for this transition to visually settle before re-measuring/resetting state (see scheduleFlushRemeasure() and sizeLogoMarquee()'s own delayed call in tunnel.js) were bumped by the same ratio so nothing fires early and catches the card mid-flight. */ /* Round 37 (REPEAT complaint, 4th+ round on this exact issue), per Dave: "this glides in from left and from right way too quickly... I keep asking you to slow these things down, I don't see a change." Re-verified from scratch rather than trusting round 36's self-report: confirmed via grep that this is the ONLY `.tunnel-card {` rule in the file (no later duplicate/higher-specificity override silently winning the cascade) and that index.html's cache-buster WAS bumped to ?v=98 after round 36 (so Dave's browser should have loaded the 1s/.75s values, not a stale asset) - the 1s/.75s value was genuinely live, it was simply still not slow enough to read as deliberate. Roughly doubled again per this round's instruction: transform 1s -> 1.9s, opacity/filter .75s -> 1.35s. */ /* `top` added (this round, item 3) alongside `transform` so the new top-anchored override below (see .tunnel-card.is-current:has(...) after the is-hidden-far rules) animates smoothly into/out of place when a Website Changes sub-panel opens/closes, instead of snapping - `top` never changes anywhere else in this file, so this is a no-op everywhere except that one state change. */ transition: transform 1.9s cubic-bezier(.16, 1, .3, 1), top 1.9s cubic-bezier(.16, 1, .3, 1), opacity 1.35s ease-out, filter 1.35s var(--tunnel-ease); will-change: transform, opacity; pointer-events: none; /* --ink/--muted (defined in styles.css) are light cream tones meant for text on the site's dark background. Now that the card itself is light, redefine them locally so every rule inside the card that already reads "color: var(--ink)" / "color: var(--muted)" automatically becomes dark, legible text - no need to touch each rule individually. */ --ink: #1c242a; --muted: rgba(28,36,42,.62); /* Root-cause fix for "text renders too light" bugs on this card (e.g. the stepper number): #webyayTunnel sets `color: var(--ink)` using the ROOT-scoped --ink (a light cream tone meant for the dark tunnel shell), and that computed color is what descendants inherit by default. Simply redefining the --ink/--muted CUSTOM PROPERTIES above does not retroactively change that already-inherited `color` - only elements that themselves write `color: var(--ink)` picked up the dark tone. Any element in here that never set an explicit `color` (like .tunnel-stepper__value) kept inheriting the light cream color from the shell, reading as "too light gray" against this card's white background. Setting `color` directly here means every descendant without its own explicit color declaration now inherits the correct dark ink by default. */ color: var(--ink); } .tunnel-card.is-current { pointer-events: auto; opacity: 1; /* ROUND 30: left/horizontal-centering removed - see the root-cause note on .tunnel-card above (was translate(-50%, -50%), now vertical-only). */ transform: translateY(-50%) translateX(0) scale(1); z-index: 3; } /* Per Dave: no more ghost/peek previews of the previous or next card - only the current card is ever visible. Cards leaving to the back (is-prev, i.e. the one just navigated away from) simply fade/slide out to the left; cards about to become current arrive by fading/sliding in from the right (is-next is applied for one frame right before a card becomes is-current - see tunnel.js). Both states are fully transparent and non-interactive, never idle-visible. */ .tunnel-card.is-prev { opacity: 0; /* Fixed-pixel travel distance (was -6%, ~37px on a 620px card - too subtle to read as a slide) so the outgoing card visibly travels left by a moderate, consistent amount regardless of card width. Dropped the scale(.97) - it muddied the pure directional read of the motion. Per Dave (round 22): bumped 64px -> 120px alongside the longer .7s duration above, so the outgoing fade/slide reads as a clear, elegant glide rather than a quick snap. Round 36: 120px is a fixed pixel value regardless of window size - on a wide desktop that's only ~8% of the viewport, nowhere near "the left edge of the browser." Switched to a viewport-relative 70vw so the outgoing card always travels a genuinely dramatic distance toward the browser's left edge, proportional to the actual window width (see the transition-duration comment above for the full investigation notes - the transition mechanism itself was already firing correctly; distance was the real problem). */ transform: translateY(-50%) translateX(-70vw); z-index: 1; pointer-events: none; } .tunnel-card.is-next { opacity: 0; /* See .is-prev above - same viewport-relative distance, opposite direction, so the incoming card visibly slides in from the right edge of the browser. */ transform: translateY(-50%) translateX(70vw); z-index: 1; pointer-events: none; } /* Round 31, item 8 - ROOT CAUSE of the "chip navigation still snaps" bug: .is-hidden-far never set its own `transform`, so it silently inherited the base .tunnel-card rule's translateX(0) - THE EXACT SAME transform value as .is-current. Every trigger (Next, Back, chip click) already funnels through the one goToIndex()/updateCardPositions() path in tunnel.js (verified - there was never a second, separate "jump instantly" code path), but clicking a completed trail chip more than one slide away moves the outgoing card straight from is-current to is-hidden-far (not is-prev/is-next, since it's no longer adjacent to the new currentIndex) - and since translateX(0) -> translateX(0) is not a transform CHANGE, only opacity animated. That read as a flat crossfade with zero slide motion, which is exactly the "snapping" Dave kept seeing even though the underlying code path was already unified. Fix: give is-hidden-far the same directional offset as is-prev/is-next, chosen by the card's index relative to the NEW currentIndex (via .is-before/.is-after, set in updateCardPositions()) - so a far card sitting off-screen already carries the correct-direction offset, and becoming current (or leaving it) now always animates a real slide, at any jump distance, not just +-1. */ .tunnel-card.is-hidden-far { opacity: 0; pointer-events: none; } .tunnel-card.is-hidden-far.is-before { /* Round 36: matches the .is-prev viewport-relative distance above. */ transform: translateY(-50%) translateX(-70vw); } .tunnel-card.is-hidden-far.is-after { transform: translateY(-50%) translateX(70vw); } /* HIGH-PRIORITY FIX (this round), item 3 - REPEAT complaint, per Dave: "you see how when I go into these sub-categories, you have tons of padding on the top, and it's butting up to the gray bar at the bottom... needs to be way higher vertically in the page... I've asked for this a few times." The 4 Website Changes sub-panels (Overall Changes/Font Changes/Social Media/Email - each a .tunnel-3tile-panel.is-visible inside this card) were still reading this way even after an earlier round's general .tunnel-card top:46%->40%/max-height:90%->78% tune. Root cause: that earlier fix only ever adjusted the CENTERING anchor's percentages - .tunnel-card is (and remained) `top:40%` + `transform:translateY(-50%)`, which by definition always splits whatever headroom exists roughly evenly above/below the box. Nudging the percentages can rebalance top-gap vs. bottom-gap against each other, but can never make the TOP gap alone genuinely small while this card's tallest real content (Font Changes' own 2-column font grid + its OK button, the tallest of the 4 sub-panels) still safely clears the gray .tunnel-bottom band - centering is structurally the wrong model for a panel this tall. Fix: when a sub-panel is open, this specific state now uses a TOP- ANCHORED (non-centering) position instead - `top:0` lands the panel's real content right at .tunnel-card's own 14px top padding, i.e. within a few px of the monitor mockup's own top edge (.tunnel-mid__preview's monitor art sits ~15px from the band's top - see that rule's comment), matching Dave's literal "get it up close to the top edge of that monitor" ask, instead of floating in the vertical middle of the band. `transform:translateY(0)` (no vertical translate at all) replaces the -50% centering translate. max-height raised to 96% (was the general 78% cap) since this state no longer needs half its box-height reserved as "space above" - the freed room goes toward the tallest panel (Font Changes) actually having somewhere real to grow into before the bottom band, and .tunnel-mid__content's own overflow-y:auto (scrollbar hidden) remains as a non-clipping safety net for any content that still exceeds this on an unusually short window. Scoped narrowly via :has(.tunnel-3tile-panel.is-visible) so ONLY this exact state is affected - the Website Changes tile-picker screen (no panel open yet) and every other category's card keep the normal centered layout untouched. :has() is unsupported only in very old browsers, where this rule is simply ignored and the pre-existing centered .tunnel-card. is-current rule above still applies - a safe, non-breaking fallback, not a hard dependency. */ .tunnel-card.is-current:has(.tunnel-3tile-panel.is-visible) { top: 0; transform: translateY(0) translateX(0) scale(1); max-height: 96%; } /* Fix (this round), item 2, per Dave (REPEAT complaint): "this content in the Website Changes overall for all four categories is too low in the tunnel window, it needs to go up at least 30 pixels or more." REAL root cause, found via Playwright after the margin trims below alone only reclaimed a few px: the "What kind of changes?" subquestion right above the tile row is SUPPOSED to collapse to 0 height the instant a panel opens (tunnel.js's setHeaderCollapsed(true) adds .is-collapsed to it, exactly like the eyebrow right above it) but a separate cascade- specificity bug (see the .tunnel-detail__heading--subquestion[data-3tile- subquestion].is-collapsed fix further up this file) was silently cancelling that collapse, permanently costing ~47px of dead space on every one of the 4 sub-panels. Fixing that alone delivers the bulk of Dave's requested 30px+ move. The .tunnel-card__question above it is already invisible while a panel is open (it lives inside .tunnel-qa, which is-collapsed already clips to 0 - confirmed via Playwright, no fix needed there). The margin trims below are the remaining, smaller contribution: tightening the eyebrow's/panel's own spacing (tuned for the OLD centered layout, which had slack to spare) now that the card is top-anchored. Scoped entirely inside this :has(.tunnel-3tile-panel. is-visible) state so the tile-PICKER screen (no panel open yet) and every other slide keep their original spacing untouched. Combined effect verified via Playwright: panel content now clears the gray band with a comfortable positive gap instead of clipping into it, and the tile fields sit noticeably higher than before this round. */ .tunnel-card.is-current:has(.tunnel-3tile-panel.is-visible) .tunnel-card__eyebrow { margin-bottom: 4px; } .tunnel-card.is-current:has(.tunnel-3tile-panel.is-visible) .tunnel-3tile-panel.is-visible { margin-top: 4px; } /* Item 5 (prior round), per Dave: "this content is a bit high in that white tunnel... 20 or 30 pixels too skewed high" - referring specifically to the Summary/Review Order slide ("Here's everything you've selected..."). The prior fix nudged the CENTERING anchor (`top:40%` + `translateY(-50%)`) down by a flat 25px - but that's the wrong model for this card entirely. ROOT CAUSE (this round): .tunnel-summary opts into the flush-scroll mechanism (data-flush-scroll in tunnel.js/sizeFlushScrollAreas()), which force-stretches this card's real measured height via min-height to reach almost all the way down to the gray .tunnel-bottom band - i.e. this card ends up nearly as tall as the ENTIRE mid column (measured ~92% of it, matching this card's own max-height:92% override below). Centering a box that tall via `translateY(-50%)` moves its top edge up by roughly HALF THE COLUMN'S HEIGHT - a ~25px nudge to the anchor is negligible against that, which is exactly why Dave's screenshot showed the headline clipped UNDER the top teal band: the box's top edge was landing above the mid column's own top edge, i.e. inside the top band itself. Fixed by switching this state to the SAME top-anchored (non-centering) model already proven safe for the Website Changes sub-panels directly above (`top:0` + `transform:translateY(0)`) instead of trying to tune a centering anchor against a box that's nearly full-column height - the card's own 20px top padding (see [data-summary-detail="true"] padding below) then provides the actual visible gap below the top band, verified via Playwright as a clearly positive, non-clipping gap. Scoped only to the Summary card via its own [data-summary-detail="true"] marker (set in tunnel.js) so no other slide is affected. */ .tunnel-card.is-current[data-summary-detail="true"] { top: 0; transform: translateY(0) translateX(0) scale(1); } /* BUG FIX (this round), per Dave: "flows in at the right height and then glides up too high by the time it stops." Root cause: .tunnel-card's base rule has BOTH `top` and `transform` in its transition list (1.9s!). is-prev/is-next (below) never override `top`, so while this card is mid-transition (arriving from is-next), its `top` is still the base card's 40% - only once the `is-current` class lands does the [data-summary-detail] override above kick top down to 0. Since `top` is a transitioned property, the browser doesn't jump straight to 0 - it genuinely ANIMATES from 40% to 0 over the full 1.9s, which is exactly the extra "glide up" after the card already looked like it had arrived. Fix: give this card's is-prev/is-next states the SAME top:0 (and a transform with no vertical component - translateY(0), only translateX slides) so `top` and the transform's Y component never actually change across ANY state this card can be in. Only translateX (the intentional left/right slide) still animates - the vertical "settle" glitch is gone because there's no longer a vertical value change to animate. */ .tunnel-card.is-prev[data-summary-detail="true"] { top: 0; transform: translateY(0) translateX(-70vw); } .tunnel-card.is-next[data-summary-detail="true"] { top: 0; transform: translateY(0) translateX(70vw); } /* Fix (this round), item 10, per Dave: the embedded account-creation panel's "Step 1A: Create account" label (`.small-label` in the base site's #accountFlowModal markup, index.html) read as an odd one-off "STEP 1A" numbering AND used its own smaller/differently-colored one-off style instead of the shared eyebrow look every other tunnel category uses ("WEBSITE CHANGES", "ADDITIONAL PAGES", etc). Copy simplified to plain "Create Account" (no step numbering) and the markup now carries this same .tunnel-card__eyebrow class directly (see index.html) rather than a one-off style, so it's genuinely the same rule, not a lookalike. */ .tunnel-card__eyebrow { display: block; font-size: 11px; letter-spacing: .14em; text-transform: uppercase; /* Per Dave (this round): same "old discarded dark beige" fix as .tunnel-card__question above - this was a 50% screening of the old --tunnel-teal-bg-dark/#75726c beige tone; now a 50% screening of --ink (#1c242a = rgb(28,36,42)) instead, so the eyebrow stays visually paired with the header's new dark-gray color. */ color: rgba(28, 36, 42, .5); margin-bottom: 10px; /* Per Dave: on slides where a tile's fields expand below (currently just Website Changes), this eyebrow temporarily collapses via .is-collapsed (see JS) to reclaim vertical real estate while filling in the tile's fields, then fades back in once OK is hit. max-height capped generously above the text's real rendered height so the base (non-collapsed) state never clips; same fade+collapse transition idiom as .tunnel-qa.is-collapsed elsewhere in this file. */ max-height: 40px; overflow: hidden; opacity: 1; transition: max-height .42s var(--tunnel-ease), opacity .22s ease, margin-bottom .42s var(--tunnel-ease); } .tunnel-card__eyebrow.is-collapsed { max-height: 0; opacity: 0; margin-bottom: 0; pointer-events: none; } .tunnel-card__question { margin: 0 0 22px; font-family: "Plus Jakarta Sans", Arial, sans-serif; font-weight: 600; /* Item 9 (per Dave): "the type needs to be larger... it's getting lost... needs to be front and center size-wise" - a pure font-size bump, ~18% larger at every step of the clamp (19->22, 25->29, and the vw slope nudged up to match so it scales at the same relative rate across viewport widths), not a position/alignment change. Shared by every slide type that uses this class (plain yes/no questions, the "choice" kind, and the summary/review slide via .tunnel-card[data-summary-detail="true"] .tunnel-card__question further below, which only overrides size at narrow breakpoints and otherwise inherits this base value) - verified via Playwright at several viewport widths that text-wrap:balance still avoids widows and no slide's header collides with content above/below at the larger size. Round 2 (per Dave, same session): "still larger for these headers throughout" - bumped again, ~18% on top of the above (22->26, 29->34, vw slope nudged 2.3->2.7 to match the same relative growth rate). margin-bottom also raised 16->22px so the now-taller line(s) still keep clear breathing room above the Yes/No buttons / tile grids that follow - verified via Playwright across plain yes/no (Logo Design), tile-based (Website Changes), Care/Payment choice slides, and the summary slide at 1280/1440/1920px: text-wrap:balance still balances multi-line headers sensibly at the larger size (no widows), and no header collides with or crowds the buttons/tiles beneath it. */ font-size: clamp(26px, 2.7vw, 34px); /* Item 7a (this round): "the leading/line-space is too loose on all of these headers, needs to be tightened a little." Was 1.25. Tightened to 1.15 - NOT the same floor that bit .tunnel-top__headline h2 in an earlier round (that element clipped descenders at 1.15 because it also has overflow:hidden, cropping the line box tight to its glyphs). This element has no overflow:hidden anywhere in its rule chain, so a shorter line box here just tightens the visual leading - there's nothing for it to clip against. Verified via Playwright across multi-line headers (Logo Design, Hosting & Care, the intro info-card) that descenders ("g", "y") still render fully. */ line-height: 1.15; /* Per Dave (this round): reverted back to plain --ink (#1c242a, dark gray) - the --tunnel-teal-bg-dark/#75726c beige tone this used to sit on (see prior comment, kept for history) was left behind by the Plum/Jade color-change pass and read as "old discarded dark beige" against the new plum palette. Scoped to just this header + the .tunnel-card__eyebrow label right above it (same beige family, same visual header group) - NOT the --tunnel-teal-bg-dark variable itself, which other things (button hover states, the account-embed login panel) still legitimately use and were not part of this ask. */ color: var(--ink); /* Per Dave (round 18): multi-line headers were stretching wide enough that the wrap looked lopsided (a long top line over a short bottom line, or vice versa) - "too oblong". A fixed 30ch cap was tried first, but it kept producing ugly one-word/two-letter WIDOWS instead (e.g. "The foundation everything else below builds / on." with "on." stranded alone on its own line) - the ch cap forces a break point that has nothing to do with where the text actually balances evenly, it just forces an early wrap and whatever's left over (often one short word) spills to its own line. Root-cause fix (round 21, per Dave): drop the guessed ch cap entirely and use the browser's own line-balancing algorithm instead - text-wrap:balance (below) computes the minimum number of lines the text needs at its NATURAL container width, then re-flows the break points so every line in that count is as close to equal-length as possible, which by construction can never leave a lone short word dangling on its own line the way a fixed ch guess could. Tested against several real headline strings in the tunnel (this intro question, the payment-approach question, the review/confirm question, "Want ongoing hosting & care?", etc.) - none produce a widow anymore. Supported in all current Chromium/Safari/Firefox; on any older engine that doesn't understand text-wrap, this simply falls back to normal wrapping at the card's own natural width (still better than the old 30ch cap, which is why it isn't kept as a fallback here either). */ text-wrap: balance; } /* Item 7b (this round), per Dave re: the Logo Design header ("Would you like a custom logo designed for use with your new website?"): "this header can have its text block widened so it's not quite so narrow - but don't do extreme moves... I'd love to have the word 'logo' go up to the first line, and 'with' go up to the middle line, but don't do extreme [moves]." A MODERATE width bump for just this one card (via its new data-cat-id, see buildCards() in tunnel.js) - +55px over the shared 465px --tunnel-card-w (about +12%), not a global change to every slide's card width. Verified via Playwright: at this width text-wrap:balance reflows the header to land "logo" on line 1 and "with" on line 2, as Dave asked, without stretching the card dramatically wider. */ .tunnel-card[data-cat-id="logo"] { width: 520px; } /* Fix, per Dave: "move all of this content down so that the note and the yes buttons are in the exact same positioning as the tiles that came before it... if they just keep clicking, their mouse would be in the same place on all these tiles - this one jumps it up too high." ROOT CAUSE: .tunnel-card is vertically CENTERED (top:40% + translateY (-50%) - see the base .tunnel-card rule), so a taller card's visible content starts higher on screen than a shorter card's, purely because centering splits the extra height evenly above/below the anchor point. This is the one card with genuinely extra height below its Yes/No row: the client-logo marquee (.tunnel-logo-marquee - see .tunnel-logo-marquee's own position:absolute rule and comment elsewhere in this file) used to be a normal in-flow sibling appended after .tunnel-qa, adding a fixed 68px + 42px margin-top = 110px of extra box height that no other yesno-kind slide (Inside Pages, the one immediately before this) carries - that's what pushed this card's Yes/No row up relative to every other slide. FIRST FIX (reverted this round): tried compensating with a big margin-top on the eyebrow to push the visible content down again. Per Dave (repeat complaint): that overshot badly at his actual (shorter) browser window - adding 110px of margin ALSO adds 110px to the box .tunnel-card centers itself around, so at a shorter viewport the box's own max-height cap / this column's overflow-y:auto scroll kicked in, landing the content far lower than intended and requiring a scroll to see the top chip trail - exactly the "moved it all the way down" Dave flagged, not the gentle nudge asked for. REAL FIX (this round): don't inflate the box at all - take the marquee OUT of the flow entirely (position:absolute, no longer contributing to this card's height) so the box centering this card is built around is the SAME height as every other yesno slide, and the Yes/No row lands in the same place with zero compensation needed anywhere. See .tunnel-logo-marquee below for the position:absolute + top:100% swap that keeps it visually in the exact same on-screen spot it always occupied. */ /* Per Dave (earlier round): the Hosting & Care headline was wrapping into a staggered 4-line stack at common desktop widths - .tunnel-mid__content (the text column) is capped hard by the monitor-preview graphic sharing the row, shrinking to as little as ~350-400px at some viewports. This width bump (matches the Logo Design header treatment above) helps at the taller/narrower aspect ratios where the column is wider than 465px. NOTE: a scoped font-size reduction on .tunnel-card__question used to be paired with this to fight the wrap further, but per Dave (later round) that made this header read as a different/smaller size than every other header in the tunnel - removed so this headline always matches the shared base size; if the 4-line wrap resurfaces at narrow aspect ratios, revisit via width/layout, not a font-size cut. */ .tunnel-card[data-cat-id="care"] { width: 520px; } /* Fade group wrapping the yes/no question + buttons. On "Yes" this collapses/fades OUT in place (via .is-collapsed) while .tunnel-detail fades IN right below it on the SAME card - no new slide is inserted. Raised from 320px originally to give the "Primary Base Page Design" slide's (now-removed, round 24) View Proposed Website pill and the "Hosting & Care" slide's fine print room to breathe without ever getting clipped; left as-is since the "Hosting & Care" fine print still needs it. */ .tunnel-qa { max-height: 380px; opacity: 1; /* Per Dave (latest round): tried overflow-y:hidden + overflow-x:visible here to let the wide logo-marquee spill past this ~445px-wide box, but that doesn't work - per the CSS spec, mixing overflow-x:visible with a non-visible overflow-y computes the "visible" axis to 'auto' instead, which still clips/scrolls. Reverted to plain overflow:hidden (both axes, as before). The logo marquee is no longer a child of .tunnel-qa at all (see the 'logo' category branch in tunnel.js's buildCards()) - it's now a sibling appended directly to .tunnel-card, which has its own overflow:visible, so it never needs to escape this element's box. */ overflow: hidden; transition: max-height .42s var(--tunnel-ease), opacity .3s ease, margin-bottom .42s var(--tunnel-ease); } .tunnel-qa.is-collapsed { max-height: 0; opacity: 0; margin-bottom: 0; pointer-events: none; transition: max-height .42s var(--tunnel-ease), opacity .22s ease; } /* Big elegant yes/no pill control. Per Dave (round 14): these were still stretching edge-to-edge to fill the row (flex:1 on each button) even after a prior round shrank their padding/font - "as wide as they were before". Switched to a non-stretching row so each button sizes to its own content/min-width instead of splitting the full row width. */ .tunnel-yesno { display: flex; flex-wrap: wrap; justify-content: flex-start; /* Per Dave (round 28) - belt-and-suspenders alongside the matching .tunnel-yesno__col wrapper now used on BOTH buttons on the Care slide (see tunnel.js): explicit flex-start instead of the default `stretch` cross-axis alignment, so a bare Yes/No button (non-Care slides) can never get stretched taller by a taller sibling either. */ align-items: flex-start; gap: 14px; margin-bottom: 4px; } .tunnel-yesno__btn { flex: 0 0 auto; width: fit-content; min-width: 132px; appearance: none; border: 1.5px solid rgba(28,36,42,.18); background: #ffffff; color: var(--ink); font-family: "Plus Jakarta Sans", Arial, sans-serif; font-size: 11px; font-weight: 600; letter-spacing: .02em; padding: 10px 22px; border-radius: 999px; cursor: pointer; transition: all .22s ease; text-align: center; } /* Per Dave (round 25): wraps just the "No" button on the Hosting & Care slide so its "(handoff html files)" fine print centers under that single button instead of spanning the full Yes/No row. Column sizes to the button's own width (align-items center handles centering the narrower text beneath it) and sits inline with the "Yes" button in the row via the parent .tunnel-yesno's flex/gap - no layout change for any other yesno slide, which still renders a bare button here. */ .tunnel-yesno__col { display: flex; flex-direction: column; align-items: center; gap: 6px; } .tunnel-yesno__finetext { font-size: 11px; font-style: normal; color: var(--muted); text-align: center; white-space: nowrap; } .tunnel-yesno__btn:hover { border-color: var(--gold); background: rgba(94,115,135,.08); } .tunnel-yesno__btn.is-selected { background: var(--gold); border-color: var(--gold); color: #fff; /* Per Dave: "no shadows anywhere" on these yes/no buttons - this was a regression back in, removed for good this round. */ box-shadow: none; } /* Per Dave (round 24): the "View Proposed Website" pill that used to live here (below the Yes/No buttons on the "Website Changes" slide) was removed as redundant now that the persistent "View Your New Site" pill on the monitor graphic covers the same function everywhere in the tunnel - see tunnel.js buildDetail for the "changes" category. Rules removed along with it (.tunnel-view-proposed-wrap / -pill). */ /* Per Dave: short, professional fine print below the Yes/No buttons on the "Hosting & Care" slide, reworded from his rough dictation into one polished sentence - ongoing help keeping the site current, routine maintenance, and staying current with underlying technology/platform changes. Styled consistently with the tunnel's other small-print copy (.tunnel-info-card__note). */ /* ROOT CAUSE FIX (this round), per Dave's repeat complaint that this slide's Yes/No row sits noticeably higher than every other yesno slide's: tunnel.js's own comment above (careFinetextEl) already documented the INTENDED fix as "position:absolute; top:100%" (same root-cause pattern as .tunnel-logo-marquee - an element appended as a sibling of .tunnel-qa specifically so it doesn't count toward .tunnel-card's own height, which drives the card's translateY(-50%) vertical centering) - but this rule itself was only ever given a plain `margin-top`, still fully in-flow, so it silently kept contributing its real height to the card after all, reproducing the exact bug the sibling-element restructuring was supposed to prevent. Actually taking it out of flow now, matching .tunnel-logo-marquee's own positioning exactly. */ .tunnel-care-finetext { position: absolute; top: 100%; left: 0; width: 100%; margin: 14px 0 0; font-size: 12.5px; line-height: 1.5; color: var(--muted); max-width: 48ch; transition: opacity .25s ease; } /* Bug fix, per Dave (screenshot: this paragraph staying on screen and overlapping the Website Access + Domain Information form once a care plan tile is picked): tunnel.js has always toggled an `is-collapsed` class on this element (see careFinetextEl in tunnel.js) the moment Yes is answered, but no CSS rule for `.tunnel-care-finetext.is-collapsed` ever existed - the class was landing on the element and doing genuinely nothing, so it just sat in its normal position:absolute spot forever, permanently overlapping whatever real content rendered below it. This is a real functional bug (broken already-intended behavior), not a style choice, so fixed for both desktop and mobile - same opacity/visibility/pointer-events pattern already used for other collapsed elements in this file (see .tunnel-logo-marquee.is-collapsed above). */ .tunnel-care-finetext.is-collapsed { opacity: 0; visibility: hidden; pointer-events: none; } /* Detail options that fade in below yes/no when "Yes" is picked */ /* Fix (this round), item 6, per Dave (app-wide, every category): "when I click on a Yes button and all the information flows in... it flows too quickly, it needs to gradually gracefully glide up, not snap in." Root cause: this reveal only ever animated max-height (a layout property, not a compositor-friendly one, and one that reads as content "growing downward from nothing" rather than a deliberate upward glide) plus a plain opacity fade - there was never a `transform` in the mix at all, so no matter how the max-height/opacity durations were tuned, the motion could never read as a panel gliding UP into place, only as a box stretching open. Added a genuine translateY glide (starts 22px lower, settles to 0) alongside the existing opacity fade, on a slightly longer duration (.6s, ease-out) so the two together read as the content rising smoothly into place - the classic "fade + rise" reveal idiom - instead of a snap. max-height's own transition is left in place (still needed so the box's LAYOUT space opens up without a hard jump-cut, avoiding a different kind of snap), just no longer the only thing carrying the perceived motion. */ .tunnel-detail { max-height: 0; opacity: 0; overflow: hidden; transform: translateY(22px); transition: max-height .55s var(--tunnel-ease), opacity .6s ease-out, margin-top .55s var(--tunnel-ease), transform .6s ease-out; margin-top: 0; } .tunnel-detail.is-visible { max-height: 360px; opacity: 1; /* Fix (this round), per Dave (Logo Design slide, eyebrow -> "Custom logo design" heading): "make padding between eyebrow and header about half this, need more real estate." This 18px margin-top (plus the eyebrow's own 10px margin-bottom) is the actual gap between the eyebrow and whatever detail heading appears right below it once a Yes/No answer reveals its detail panel - halved to 9px. Shared by every yes/no card's detail reveal (not logo-specific), consistent with today's other space-tightening asks. */ margin-top: 9px; transform: translateY(0); } /* The info slide's detail panel has no yes/no gate to toggle it - it must stay visible even after resetTunnelState() strips ".is-visible" from every ".tunnel-detail" on each fresh open (that reset is written generically for the yes/no cards' fade-in sub-options). Scoping to the info card's own wrapper keeps that shared reset logic untouched. Per Dave (v6): the laptop mockup that used to sit in this same detail panel (two-column flex layout) is now a PERSISTENT fixture in .tunnel-mid's own left column (see .tunnel-mid__preview above) rather than living inside this card - so this panel is back to a plain single-column block, same treatment as the terminal summary slide's counterpart below. */ .tunnel-card[data-info-detail="true"] .tunnel-detail { max-height: none; opacity: 1; overflow: visible; /* Fix (this round), per Dave (repeat complaint): "the padding between the header and the content below it... still twice as much as I want." Measured via Playwright: the real gap between the header's bottom edge and this row's top edge was 44px (question's own 22px margin-bottom + this element's old 16px margin-top). Cut roughly in half (44px -> 22px) by trimming 10px off this margin (see the matching -12px trim on .tunnel-card__question's margin-bottom just below) - together that's the full 22px reduction. Per Dave's explicit instruction, this is NOT done by pulling this content up - see .tunnel-card__eyebrow's new margin-top just below, which pushes the header/eyebrow down by the same 22px this saves, so this row's own screen position is unchanged; only the header moves, closing the gap from above. */ margin-top: 0px; } /* Per the .tunnel-detail comment above: -12px off this header's own margin-bottom (22px -> 10px), paired with the eyebrow's new +22px margin-top below, is the other half of the 22px total gap reduction. */ .tunnel-card[data-info-detail="true"] .tunnel-card__question { margin-bottom: 0px; } /* Fix (this round), per Dave, desktop only: "20px more padding between header and dollar amount." Since the "Website Design" name/checkmark row was hidden entirely this round (see .tunnel-info-card__name's display: none fix elsewhere in this file - a base/unscoped change, so it applies on both mobile and desktop), the header-to-price gap on THIS info slide collapsed down to near-zero (this rule's own 0px margin-bottom, set in an earlier round when "Website Design" still sat directly below the header and needed zero extra gap) - now that the row right after the header is the $57/mo price line instead, that same 0px reads as too tight. Scoped to desktop only (min-width:768px, the inverse of this file's standard 767px mobile breakpoint) since Dave only flagged this on desktop - mobile's own spacing/decluttering is untouched. */ @media (min-width: 768px) { .tunnel-card[data-info-detail="true"] .tunnel-card__question { margin-bottom: 20px; } } /* Per Dave: "do it by moving the header and eyebrow down, which is positioned too high" - NOT by pulling the "Website Design / Transition Questions?" row up. This card is vertically centered (base .tunnel-card's top:40% + translateY(-50%)), so adding this margin-top pushes the eyebrow (and everything after it - question, Yes/No-less detail row - since they're all normal document flow) down within the card by 22px, while the matching -12px/-10px trims above keep the card's TOTAL height unchanged - so the detail row below stays anchored at the same screen position. Net effect verified via Playwright: header/eyebrow visibly shift down, header-to-content gap is now ~22px (was ~44px), and the detail row's own on-screen Y position is unchanged (within 1px). */ .tunnel-card[data-info-detail="true"] .tunnel-card__eyebrow { margin-top: 32px; } /* ---- Persistent desktop-monitor mockup (left column of .tunnel-mid) ---- Per Dave (v7): swapped the laptop mockup for a real desktop-monitor asset he supplied (desktop-computer.jpg/.png, ~587x435 native, an iMac-style monitor on a stand). Same lightweight opaque-JPEG-behind / iframe-in- front pattern as the laptop version it replaces. ROUND 21, per Dave: after five rounds of chasing a recurring white-line artifact along the screen-cutout edge (see the long history below, kept for context), Dave supplied a brand-new asset - desktop-monitor-v2.jpg (copied verbatim from his desktop-computer-nowhite.jpg, same 587x435 canvas) - where the ENTIRE monitor face (bezel AND screen together, not just the screen cutout) is painted solid black, with no separate lighter bezel color to distinguish from. His reasoning: any leftover sub-pixel gap between the iframe's edge and the screen box's clip edge now exposes more solid black bezel underneath instead of a lighter bezel color or raw white iframe background - so it blends away instead of reading as a jarring hairline, even if the coordinates are never pixel-perfect. Measured fresh via PIL color-diffing (this is a DIFFERENT source photo than the old desktop-monitor.jpg, not just a recolor - dimensions happened to match at 587x435 but the black shape's own edges do not line up with the old screen-cutout box, so the old 28/26/534/312 numbers were NOT reused): the solid-black monitor-face rectangle's innermost safe bounds (i.e. the tightest edge found scanning every row/column, which accounts for the shape's slightly rounded corners) are left>=16, right<=573, top>=11, bottom<=352 in native 587x435 px - confirmed pure (0,0,0) at every one of those boundary coordinates. Since the whole face is one uniform black (no inner screen-vs-bezel distinction to hit exactly), and Dave explicitly asked for a MORE generous margin this round ("err on the side of slightly over-cropping rather than under-cropping ... a black gap is far less visible than white was"), the screen box below is inset well past those measured bounds - 12-19px of pure-black margin on every side - rather than hugging the tightest safe edge the way the old white-bezel version had to. Verified via automated Playwright pixel-sampling (zero light/white pixels along any of the 4 edges) at 1440x900, 1440x800, 1440x700, 1280x800 and 1680x1000 - see tunnel-fix-round21/ output. ---- Prior history (v3-v20, kept for context, superseded by the above) ---- desktop-monitor.jpg (copied from his desktop-computer.jpg) was a flat, fully opaque JPEG with the screen area painted plain white, so no transparent-PNG mask/alpha channel was needed. The companion desktop-computer.png (transparent-cutout mask version) was only used to MEASURE the screen-cutout coordinates via a flood-fill of its alpha channel. Measured screen-cutout bounding box on that 587x435 native canvas: left 30px, top 28px, width 530px, height 308px, later tightened to left 28 / top 26 / 534 wide / 312 tall after repeated white-hairline reports traced to the box landing 1-2px short of the JPEG's actual border-to-screen transition. No native-canvas cropping/offset trick was ever needed (unlike the old device-frame-laptop.jpg, which packed a laptop+phone on one shared canvas) - .tunnel-intro__stage is sized to the exact 587x435 native canvas with a plain scale() transform, no translate offset. Built ONCE in tunnel.js's buildRoot() as a persistent sibling of the card track (inside .tunnel-mid__preview), not re-created per slide, so the iframe never reloads/re-renders as the user moves through the tunnel. */ .tunnel-intro__visual { /* Per Dave (v8): the monitor now scales to nearly fill the full height of the white .tunnel-mid band, leaving ~15px clearance above/below - see sizeMonitorPreview() in tunnel.js, which measures the live .tunnel-mid__preview column height on open + resize and writes the matching --intro-scale value here as an inline style (overriding this 0.87 fallback, which only applies before JS runs / if JS fails). */ --intro-scale: 0.87; position: relative; flex: 0 0 auto; width: calc(587px * var(--intro-scale)); height: calc(435px * var(--intro-scale)); overflow: hidden; } /* Touch-scroll fix (round: WebKit transform+touch bug): the monitor's live iframe sits under TWO stacked CSS transform scale() layers (this .tunnel-intro__stage's own scale(--intro-scale), AND the iframe's own inner scale(.38281) - see .tunnel-intro__screen iframe below). iOS Safari/WebKit has a long-documented bug where native touch-to-scroll coordinate math breaks down on any element sitting under a CSS transform: scale() ancestor - confirmed via direct A/B test: the exact same live iframe scrolls perfectly fine with no transform ancestor (font-preview iframes, the real above-the-fold page), and crashes/ glitches every time specifically inside this doubly-transformed monitor. Fix: this untransformed sibling div (a DIRECT child of .tunnel-intro__visual, NOT nested inside .tunnel-intro__stage's transform) sits visually on top of the screen cutout and captures the real, untransformed touch coordinates - which WebKit computes correctly since nothing here is transformed - then tunnel.js manually drives the iframe's own contentWindow scroll position from that real touch delta. The iframe itself is pointer-events:none (see .tunnel-intro__screen iframe) so it never receives a raw native touch event at all - scrolling only ever happens programmatically, so the buggy native-touch-on-transformed- element path is never exercised. Sized as a % of .tunnel-intro__visual (which is NOT itself transformed, just width/height calc()'d off the same --intro-scale) so it tracks the screen cutout's real on-screen box at any --intro-scale with pure CSS, no JS resize math needed. */ .tunnel-intro__touchcatch { position: absolute; left: calc(35 / 587 * 100%); top: calc(28 / 435 * 100%); width: calc(525 / 587 * 100%); height: calc(312 / 435 * 100%); z-index: 6; background: transparent; touch-action: none; } .tunnel-intro__stage { position: absolute; left: 0; top: 0; width: 587px; height: 435px; /* Per Dave (this round): a thin black line persisted along the monitor's bottom, or right+bottom, edges even on an already-settled/deployed page (not just mid-resize - see .tunnel-intro__mask's own comment above for that separate, already-fixed timing issue). Root cause here is different: .tunnel-intro__visual's clipping box is sized by a layout calc() (`587px * var(--intro-scale)`, computed by the browser's layout engine), while this element's own size comes from an independent CSS transform: scale() (computed by the compositor). Both use the exact same --intro-scale value, but layout-rounding and transform-rounding don't always land on the same fractional pixel - at certain scale factors the transformed content is a hair SMALLER than its clipping box, exposing a sliver of whatever sits behind it (this stage's own dark bezel/screen content bleeding into a gap reads as the black line reported). Fix: scale a fraction of a percent (1.006x) larger than --intro-scale actually calls for, so the rendered content is always guaranteed to fully cover its clipping box regardless of which way the rounding goes - the extra sliver (well under a pixel at this element's size) is silently clipped by .tunnel-intro__visual's overflow:hidden instead of ever leaving a gap. transform-origin stays top left so the tiny overscan grows toward the right/bottom edges - exactly where the line was reported, and consistent with every other edge-safety margin already used in this file (the iframe's 5% overscan, the mask's border) rather than chasing pixel-perfect alignment. */ transform: scale(calc(var(--intro-scale) * 1.006)); transform-origin: top left; background: transparent; } /* Screen box coordinates, in the same native 587x435 stage-pixel space as .tunnel-intro__frame (assets/img/desktop-monitor-v2.jpg). ROUND 21 (do not regress to the old 28/26/534/312 box - that was measured against a DIFFERENT source photo, desktop-monitor.jpg, whose bezel/screen edges do not line up with this new asset): re-measured fresh against desktop-monitor-v2.jpg via PIL color-diffing. Unlike the old asset (a light bezel around a white screen cutout, where the exact bezel/screen boundary had to be hit precisely or a hairline of the wrong color leaked through), this new asset paints the ENTIRE monitor face - bezel and screen together - one uniform solid black, so there's no internal boundary to hit at all; only the OUTER edge (black monitor shape vs. the white page background around it) matters, and any imprecision on this box just crops a little more/less of the harmless black bezel, never white background. Measured innermost safe bounds of that solid-black shape (tightest edge found scanning every row 15-345 / column 20-569, i.e. safely clear of the shape's slightly rounded corners): left>=16, right<=573, top>=11, bottom<=352 - confirmed pure (0,0,0) at each boundary. Per Dave's explicit round-21 ask ("apply a MORE generous overscan margin than before ... err on the side of slightly over-cropping"), this box is inset well past those measured bounds rather than hugging them the way the old white-bezel box had to: left 35 / top 28 / 525 wide / 312 tall (covers native x 35-560, y 28-340) - 12-19px of solid-black margin on every side. Verified via automated Playwright pixel-sampling (zero light/white pixels found along any of the 4 edges) at 1440x900, 1440x800, 1440x700, 1280x800 and 1680x1000 - see tunnel-fix-round21/. */ .tunnel-intro__screen { position: absolute; left: 35px; top: 28px; width: 525px; height: 312px; overflow: hidden; /* FIX (2026-07-29), per Dave: this monitor screen (the "your new website" mockup inside the paid tunnel) showed pure white for 1-3 seconds before the live-preview iframe's delayed (600ms in tunnel.js) src assignment finished loading/painting - a jarring blank-white flash every time the tunnel opens. Screen box + iframe (see .tunnel-intro__screen iframe below) both default to black instead, matching the monitor bezel's own solid black face (desktop-monitor-v2.jpg) so the "empty" state reads as an off monitor, not a broken white one. Once the iframe's real content finishes loading it paints over this background exactly as before - no JS/timing logic changed, this is a pure background-color swap on the two elements behind the iframe. */ background: #000; z-index: 3; /* Second layer of the overscroll-chaining fix (see #webyayTunnel above) - contained directly on the box that actually holds the scrollable iframe, so the fix applies right at the source, not just the outer overlay. */ overscroll-behavior: contain; } /* Monitor screen (530x308, ~1.72:1) is a wider/shorter ratio than the live site's 1440x900 (1.6:1) iframe viewport, so a uniform scale that fills the screen's width exactly (530/1440 = .36806) overflows slightly on height (~331px of scaled content into a 308px-tall box) rather than leaving any gap on the sides - the parent's overflow:hidden trims that small excess off the bottom, same crop-not-gap idiom the laptop version used, just tuned to this screen's own aspect ratio instead of reusing the laptop's .89 figure. Per Dave (scroll request): `pointer-events: none` used to sit here, which blocked ALL mouse interaction with the iframe - including wheel/ trackpad scroll, not just clicks. That was the actual reason hovering the monitor and scrolling did nothing. Switched to `pointer-events: auto` so wheel events reach the embedded page and it scrolls natively; the `scrolling="no"` attribute that used to sit on the