/* ===== WebYay scroll-wall intro overlay CSS - SHARED, all clients + template ===== Pairs with ../assets/shared/intro.js (that file explains the full architecture). Every client's links this file directly: Nothing in here is client-specific - font/color/timing/motion are all generic, and the reveal text's actual client name comes from JS (window.WEBYAY_PITCH_CLIENT_NAME) at runtime, not from anything here. */ #webyayIntroWall, #webyayIntroWall *{ box-sizing:border-box; } /* Per Dave: hold time bumped 5s -> 6s, and the fade-out itself slowed way down, .8s -> 2.2s. Then bumped to 8s, then 9s, to keep pace with the reveal-text draw getting slowed down repeatedly in earlier rounds. Per Dave (latest): "change the duration total from 6 secs to 5 secs goes on too long" - cut a flat 1s off the hold (9s -> 8s). With round 14's line-2-starts-early fix already in place, both lines are fully drawn and filled by ~6.5s, so an 8s hold still leaves real breathing room before the fade starts - not cut it close. Total intro length (hold + fade) is now 10.2s, was 11.2s. Fix (2026-08-07), per Dave: "make this intro end sooner by 2 seconds pls. and have the fade-out part fade a bit longer by maybe 1 second." Hold cut 8s -> 6s (fade now starts 2s sooner) and fade-out itself lengthened 2.2s -> 3.2s (+1s, longer/more graceful) - so the START of the fade is a full 2s earlier as asked, and the fade duration is 1s longer as asked. NOTE (real tradeoff, not silently glossed over): the comment above says both reveal-text lines finish drawing at ~6.5s for a mid-length client name - a 6s hold means the fade can start ~0.5s before the last character is fully done, instead of the old 1.5s of clear buffer. Not touching the reveal-text draw speed itself to compensate (CHAR_DELAY etc. in intro.js) since that's been explicitly slowed down 4x across multiple earlier rounds per Dave's own repeated asks, and speeding it back up to buy hold-time back would undo that. If a longer client name visibly gets cut off mid-draw, the fix is shortening the fade-out's own ease-in ramp-up (its first ~0.5s is a very gentle opacity change anyway) rather than touching text speed or hold again. Total intro length (hold + fade) now 9.2s, was 10.2s. */ #webyayIntroWall{ position:fixed; inset:0; z-index:99999; overflow:hidden; background:#000; cursor:pointer; pointer-events:auto; animation:iwOverlayOut 3.2s ease-in 6s forwards; } /* Fix (this round): the overlay used to stay fully click-blocking for its entire 9.2s lifetime (6s hold + 3.2s fade), only releasing pointer-events once visibility:hidden landed at the very end. That's a real, legitimate ~9-second window where the real page underneath (slider, buttons, everything) is genuinely non-interactive by design - not a bug, but it reads exactly like "frozen" if anyone touches the page before the fade finishes, which is an easy trap to fall into while rapid-testing a fresh reload. Added an early 1% keyframe stop that flips pointer-events to none as soon as the fade animation itself starts (at the 6s mark), instead of waiting for the fade to finish at 9.2s - the overlay is already visibly disappearing by then, so there's no reason clicks should still be swallowed for another 3.2s. Shortens the real dead-zone from ~9.2s to ~6s. */ @keyframes iwOverlayOut{ from{ opacity:1; visibility:visible; pointer-events:auto; } 1%{ pointer-events:none; } to{ opacity:0; visibility:hidden; pointer-events:none; } } /* Skip state: clicking the intro cancels the CSS-timer animation above (animation:none) and fades out right away via a plain transition instead, whatever point in the 5s it was clicked at. */ #webyayIntroWall.iw-skip{ animation:none; transition:opacity .4s ease, visibility .4s ease; opacity:0; visibility:hidden; } /* Per Dave: "have the intro fade in from black for about 1.5 secs; start black then fade to full." First pass used a plain opacity fade on this wrapper - #webyayIntroWall's own background is solid black, so fading the wrapper's opacity up from 0 made the intro start on black and brighten into the full scene. Per Dave (repeat complaint, with a reference screenshot): "it actually pops into place in the middle rather than animating from the bottom edge; it needs to... move in revealed from the bottom edge - not just appear pop." An opacity fade brightens the WHOLE screen at once with no sense of direction - it doesn't look like motion, just a level going up. Replaced with a clip-path wipe instead: starts fully clipped (nothing visible but the black background underneath), and the visible region grows from a sliver at the very bottom edge upward until it covers the full screen - genuine "revealed from the bottom edge," and it still satisfies the original "starts black" ask for free, since whatever's still clipped just shows #webyayIntroWall's own black background through. */ /* BUG FIX: "solid black with nothing, then it fades away" - .iw-fade-in had no explicit size. Its children (.iw-wall/.iw-vignette/.iw-reveal) are all position:absolute, which takes them OUT of normal flow - they contribute ZERO height to a static-positioned parent. That collapsed .iw-fade-in to a 0-height box, and a clip-path animating on a zero-area box has nothing to ever reveal, at any point in the animation - so it just stayed black for the whole hold, then the unrelated end-of-intro fade-out (iwOverlayOut, on the OUTER #webyayIntroWall) was the only thing anyone ever saw finish. Giving this wrapper position:absolute; inset:0 makes it a real full-size box (same positioning context as its siblings), so the clip-path wipe now has an actual area to reveal. */ .iw-fade-in{ position:absolute; inset:0; } /* Per Dave (round after the clip-path bottom-up-wipe): "you screwed that up, it 'reveals in' with a sliding black coverup moving up - totally not what I wanted; I want a solid black over the screen and fade to zero black over maybe 1sec, NOT a moving black square revealing by moving up." Scrapped the clip-path wipe on .iw-fade-in entirely (it's back to a plain, always-fully-visible, correctly-sized positioned container with no entrance animation of its own). The actual fade-in is now this separate solid black veil layer, painted on TOP of the already fully-rendered/visible scene (last child in the DOM so it stacks above .iw-wall/.iw-vignette/.iw-reveal), which just fades its own opacity from 1 to 0 over 1s - no motion, no reveal-by-wipe, just a flat black sheet dissolving away. */ .iw-black-veil{ position:absolute; inset:0; background:#000; pointer-events:none; animation: iwBlackVeilFade 1s ease-out forwards; } @keyframes iwBlackVeilFade{ from{ opacity:1; } to{ opacity:0; } } .iw-wall{ position:absolute; top:50%; left:50%; width:180vw; height:230vh; transform-origin:50% 50%; display:flex; gap:10px; /* Per Dave (round 6): "kind of bright showing those images without them being super dark out" - nudged up from .97 (with the reduced per-card tint and the vignette now doing the actual darkening work at the edges, the base wall itself can afford to read brighter). */ filter:brightness(1.04) saturate(1.06); animation:iwPan 9s cubic-bezier(.42,0,.58,1) 1 both; } /* Per Dave (round 4): "photos are still just angled in the exact same angle... starts angled to the left then glides to a right angle gracefully, not shaking or jerking back and forth." Root cause of the "jerking" read: the old keyframes reversed direction at the 50% mark (drift one diagonal, then drift back) - ANY animation that reverses course mid-flight reads as a shake/jerk no matter how gentle the easing curve is. Rebuilt as one continuous, single-direction glide: position and scale are now fixed (no more translate drift at all), and only the TILT itself glides - starts rotated left, eases gracefully over to rotated right, once, start to finish, no reversal. That's literally "starts angled left, glides to angled right." */ /* Per Dave (asked 5 times, screenshot provided): "this just 'appears' in the middle of the screen... NEEDS TO GLIDE IN FROM BELOW NOT JUST SNAP IN THE MIDDLE." Tried two rounds of adding a vertical offset to THESE keyframes (16vh, then 70vh) - confirmed via an actual rendered/ screenshotted test (not just reading the CSS) that BOTH were invisible in practice, for a structural reason: this wall is 230vh tall, scaled 1.15x, and rotated - its real footprint is so much bigger than the 100vh viewport that it fully floods the screen at literally any offset in a normal range. There's no position you can nudge it to that exposes empty space - you'd need to shift it by ~180vh+ to ever show black at the top, which would look like a violent slam, not a glide. Position-shifting THIS element was never going to produce a visible entrance. Reverted this back to the original approved design (position/scale fixed, only the tilt glides, one direction, no reversal) - the actual entrance now lives on the new .iw-wall-clip wrapper below, which reveals the wall growing up from the bottom edge via a proper clip - a technique that needs a viewport-sized, unrotated box to work, which this element structurally is not. */ @keyframes iwPan{ 0%{ transform:translate(-50%,-50%) rotate(-9deg) scale(1.15); } 100%{ transform:translate(-50%,-50%) rotate(7deg) scale(1.15); } } /* The actual "images glide in from below" entrance: a viewport-sized, unrotated wrapper AROUND .iw-wall (not .iw-wall itself, which is huge/rotated and can't produce a visible reveal via clip-path either - inset() clips relative to the element's OWN box, and .iw-wall's own box is the oversized 180vw/230vh one, so a clip on it would need the same impractically large travel as the position attempt above). This wrapper is a plain 100vw/100vh box matching the viewport exactly, so inset(100% 0 0 0) genuinely means "nothing visible" and inset(0 0 0 0) genuinely means "fully visible" - the reveal window grows from a sliver at the bottom edge upward, and because it's a separate layer from .iw-wall's own rotate/tilt animation, the photo wall keeps doing its own thing underneath while this window opens over it. Deliberately does NOT touch .iw-reveal (headline text) or .iw-black-veil (the screen fade) - those are separate, correctly working effects; the previous rejected attempt ("a sliding black coverup moving up") wiped the WHOLE overlay including text and veil in one motion, which read as a screen transition instead of the images themselves entering. Scoping this to just the wall fixes that. */ .iw-wall-clip{ position:absolute; inset:0; overflow:hidden; -webkit-clip-path: inset(100% 0 0 0); clip-path: inset(100% 0 0 0); animation: iwWallReveal 1.8s cubic-bezier(.22,.8,.36,1) forwards; } @keyframes iwWallReveal{ from{ -webkit-clip-path: inset(100% 0 0 0); clip-path: inset(100% 0 0 0); } to{ -webkit-clip-path: inset(0% 0 0 0); clip-path: inset(0% 0 0 0); } } .iw-col{ flex:1; display:flex; flex-direction:column; gap:10px; will-change:transform; } .iw-col-up{ animation-name:iwScrollUp; animation-timing-function:linear; animation-iteration-count:infinite; } .iw-col-down{ animation-name:iwScrollDown; animation-timing-function:linear; animation-iteration-count:infinite; } @keyframes iwScrollUp{ from{ transform:translateY(0); } to{ transform:translateY(-50%); } } @keyframes iwScrollDown{ from{ transform:translateY(-50%); } to{ transform:translateY(0); } } .iw-card{ position:relative; flex:none; width:100%; border-radius:8px; overflow:hidden; background:#000; } .iw-media{ position:absolute; inset:0; width:100%; height:100%; background-size:cover; background-position:center; } /* Per Dave (round 6): "I'd like it to be kind of bright showing those images without them being super dark out." Backed this off from .45 to .22 - still enough to keep a bright/white source screenshot from reading as a blank patch, but no longer flattening every card into an even dark wash. The rest of the darkening job (edges/corners/top, NOT the middle) now belongs to .iw-vignette below instead of living here uniformly on every single card. */ .iw-card::after{ content:''; position:absolute; inset:0; background:rgba(0,0,0,.22); mix-blend-mode:multiply; pointer-events:none; } /* REMOVED per Dave (round 8): "some kind of black fuzzy vert line zooming left and right horizontally across the screen 3x or 4x? don't know what that is but get rid of it." That's this - a diagonal dark band panning back and forth on a 2.4s loop (originally added to read as "passing in and out of light"). At the intro's current 8s hold, a 2.4s loop repeats ~3.3 times, exactly matching what Dave described. Left the old .iw-lightsweep/.iwSweep rules and the div markup below out entirely rather than just hiding them, since there's no remaining use for either. */ /* Per Dave (round 6): "black gradation darkening so that maybe some of the edges and the tops and corners and stuff are kind of darkened out, but I don't really want darkening right in the middle of the screen." A vignette, not a flat scrim. Per Dave (round 8): "still too much darkening in the center... make that almost no darkening in the middle." Pushed the transparent zone way out and eased the edges down - probably overcorrected. Per Dave (round 11, repeat complaint): "I could barely see it... has to be much more pronounced or nearly totally black near the edges, and then it fades into being almost 0% [darkening] in the center... coming up maybe from bottom right and down from top left." Rebuilt with 3 layers: two corner-anchored radials (top-left, bottom-right - the two corners Dave called out specifically) that go nearly solid black right at the corner and fade out over ~45% of the screen, plus the all-around ellipse vignette underneath for the rest of the edge, its own max darkness raised too. Center (the 55%+ radius the ellipse stays transparent through) is still untouched - that part of round 8's fix was correct, only the edge/corner intensity was off. */ .iw-vignette{ position:absolute; inset:0; pointer-events:none; background: radial-gradient(circle at 8% 6%, rgba(0,0,0,.88) 0%, rgba(0,0,0,0) 46%), radial-gradient(circle at 92% 94%, rgba(0,0,0,.88) 0%, rgba(0,0,0,0) 46%), radial-gradient(ellipse 78% 74% at 50% 48%, rgba(0,0,0,0) 55%, rgba(0,0,0,.68) 100%); } /* Per Dave (round 4): "we have an animation for these headers that are a svg animation build; I want this exact animation for the text in this 4 second intro, have one line at a time come in; Never have centered text like that, it must be justified left and matching font style type weight as the headers inside." Also: "have the text animate in right away not wait for the end of the animation." Reference technique (same one used site-wide for the reverse-header draw-in, see assets/shared/tunnel.js animateHeadlineIn()/ HEADLINE_CHAR_KEYFRAMES and assets/shared/tunnel.css .tunnel-headline-svg): a real SVG built with one per character, each animated via stroke-dasharray/stroke-dashoffset/ fill-opacity/stroke-opacity - the letter's outline draws in stroke- first, then fills solid. Built here (below, inline script) rather than importing tunnel.js, since that file is scoped to the proposal- builder tunnel pages, not this client-facing page. Left-justified (was centered), positioned bottom-left over the wall, no fade-in delay on the container - the JS starts drawing characters within ~120ms of load instead of waiting 2.5s for the wall pan to finish. */ /* v85, per Dave: "move the animated header and company name so it's centered top/bottom but still on the left side; no matter the browser height it should be centered top/bottom, not couched at the bottom." justify-content flipped from flex-end (bottom) to center - flex layout centers the text block vertically within the wall regardless of viewport height, since .iw-reveal is position:absolute; inset:0 (full height of the wall at any window size). align-items stays flex-start and text-align stays left, so horizontal placement (left side) is untouched - only the vertical anchor changed. Bottom padding (9vh) dropped since it no longer means anything once centered; left/right padding (6vw) kept so horizontal position matches before. */ .iw-reveal{ position:absolute; inset:0; display:flex; flex-direction:column; align-items:flex-start; justify-content:center; text-align:left; padding:0 6vw; } .iw-reveal-bg{ position:absolute; left:6vw; top:50%; transform:translateY(-50%); width:min(70vw,640px); height:260px; background:radial-gradient(ellipse at 0% 50%, rgba(0,0,0,.4) 0%, rgba(0,0,0,0) 72%); } /* Font weight originally matched to the real page h1 (500), then per Dave (round 8): "make the text thinner than the weight you have now" - dropped to 400 (regular). Both lines still the same size - no small label + big headline split. No text-shadow. */ .iw-reveal .iw-line{ position:relative; font-size:clamp(28px,4.4vw,52px); font-weight:400; letter-spacing:-.01em; color:#f5f5f2; line-height:1.3; font-family:"Plus Jakarta Sans", Arial, sans-serif !important; } /* Per Dave: "make the top line an off-white so that the bottom line stays pure white, which is the client and that pops more." Reusing the site's OWN existing two-tone headline convention exactly - see .headline-soft/.headline-punch in styles.css (used on the real h1 everywhere else on this page): soft line is rgba(246,241,232,.76), punch line is solid #fff. Same two colors, same idea, just applied to these two SVG-drawn lines instead of a real

. / .iw-reveal .iw-line{ color:rgba(246,241,232,.76); } .iw-reveal .iw-line--punch{ color:#ffffff; } / The SVG that JS builds inside each .iw-line, replacing its plain text node - mirrors .tunnel-headline-svg / .tunnel-headline-svgtext. No viewBox on purpose: 1 SVG unit = 1 CSS px, so font-size/weight/ family/color above (all inherited) apply with zero coordinate math. Per Dave (round 10): "still WAY too much leading... bring it together by half." The actual lever for that gap is THIS height, not .iw-line's own line-height - .iw-line-svg is display:block, so as the sole child of a flex-column item it doesn't inherit any line-height- driven strut space, the reserved vertical space per line is exactly this box height. Cut from 1.35em to 0.9em. Per Dave (round 12): "WAY too extreme... happy medium, between how it was and what you just did." Split the difference exactly: (1.35 + 0.9) / 2 = 1.125em. overflow:visible stays on, so this can't clip the glyphs either way, only changes how close the next line's box sits. / .iw-line-svg{ display:block; overflow:visible; width:100%; height:1.125em; } .iw-line-svgtext{ fill:currentColor; stroke:currentColor; stroke-width:.011em; stroke-linecap:round; stroke-linejoin:round; dominant-baseline:text-before-edge; } / Per Dave (screenshots): "small parts of the bottom 'outline drawn' text showing up way before that line goes; it shows up when the top line is drawing." Real bug, not a timing/speed issue: each .iw-line div ships with plain fallback text baked into the HTML (the no-JS safety net, e.g. "Elite Therapy Institute"), and it's fully visible with real color from the instant the browser paints it - the overlay markup gets injected into the page synchronously, right at the top of , way before the rest of the (large) page HTML finishes parsing. The JS that actually clears that placeholder and swaps in the animated SVG only runs on DOMContentLoaded, which doesn't fire until the WHOLE page is done parsing - on a big client page that gap is long enough to be very visible, so both lines' raw, plain, already-legible fallback text sat on screen well before their own draw-in ever started. Fixed by hiding the plain text by default and only exposing the JS-built SVG once it exists: nothing shows until the animation is actually ready to draw itself in, on every browser including the no-JS fallback path (that path also builds real text inside the SVG, so it isn't cut off by this). / .iw-reveal .iw-line{ visibility:hidden; } .iw-reveal .iw-line-svg{ visibility:visible; } / Fix per Dave 2026-08-04: the H1 duplicated the intro's own reveal text ("A more refined website for Elite Therapy Institute") and pushed the before/after comparison below the fold. Removing it entirely (rather than hand-tuning padding across the many responsive .copy-block rules in styles.css) so the comparison sits right under the top bar on both desktop and mobile. / .hero .copy-block{ display:none !important; } @media (max-width:640px){ .iw-wall{ width:230vw; height:230vh; } / Per Dave: on mobile the text was "tucked on the bottom" - the desktop treatment (bottom-left, per Dave's original placement call) doesn't work at phone aspect ratios where the wall is much taller than it is wide. Switched to vertically centered (top/bottom) on mobile only - still left-justified horizontally, that instruction stands regardless of screen size, only the VERTICAL position and leading change here. Also less leading per Dave: line-height eased down from 1.3 to 1.14 so the two lines sit tighter together. / .iw-reveal{ justify-content:center; padding:0 7vw; } .iw-reveal-bg{ left:7vw; bottom:auto; top:50%; transform:translateY(-50%); } .iw-reveal .iw-line{ font-size:clamp(22px,6.2vw,32px); line-height:1.14; } } / Every WebYay client page has a redundant H1 ("A more refined website for [Client]") sitting between the top bar and the before/after comparison - it duplicates this overlay's own reveal text and pushes the comparison below the fold. Hidden via a scoped override rather than removed from each client's own copy-block CSS (which has dozens of scattered per-breakpoint rules) - single source of truth, applies everywhere this stylesheet is loaded. */ .hero .copy-block{ display:none !important; }