/* =================================================================== Word for Word — design tokens Palette is faithful to the brand swatch (hex codes as supplied). =================================================================== */ :root { --color-dark: #60362A; /* backdrop / footer / deep text */ --color-tan: #F1D7BC; /* warm cream square */ --color-cream: #F9F5EC; /* lightest square / page background */ --color-red: #B93E2D; /* brand accent square */ --color-grey: #9A9EAA; /* muted blue-grey square */ /* One-off, explicitly requested addition — NOT part of the 5-color brand swatch above. Used only by the intro splash's cream-bg variant (screens 01-04), for asterisk/caption 03 ("darker beige," between --color-tan and --color-dark). Darkened ~10% from the original #DBB388 per explicit follow-up request — safe to darken directly (not via a scoped override) since this variable is a one-off used ONLY by splash screen 03, nowhere else on the site. */ --color-tan-dark: #C5A17A; /* One-off, explicitly requested — the backdrop behind section 3's illustration (.split-cta__illustration-wrap) only. */ --color-illustration-bg: #0e1316; /* One-off — matches the baked-in color of "Asterisk 2 (nav).png" exactly (sampled from the asset itself), used only for screen 02's .page-flash caption text. Lighter/warmer than --color-tan, so kept separate rather than reusing that variable. */ --color-beige-nav: #FFE3C6; /* Splash screen 02's own darkened variant of --color-grey (~10% darker), per explicit request. NOT a replacement for --color-grey itself — that variable is shared across ~10 other things sitewide (squares, page-flash, publication cards, etc.), so darkening it globally would have darkened all of those too. Scoped to just the 2 splash-02 rules that use it (see .intro-splash__caption--2/ .intro-splash__asterisk--2 below) instead. */ --color-grey-splash-dark: #8B8E99; --font-display: "Instrument Serif", Georgia, "Times New Roman", serif; --font-body: "Newsreader", Georgia, serif; /* The only 2 sizes body/UI text should ever use (display/headline text — section labels, titles, quote blocks — is its own thing and intentionally varies per section for hierarchy, not part of this scale). Anywhere text needs to be smaller than paragraph copy (nav, captions, meta, footer, card sub-text), use --text-small — never a one-off rem value or an opacity fade on --text-body. */ /* clamp()'d, not a fixed px value: the min end is what these actually shrink to on a real phone (checked against 320-430px viewports), the preferred vw component is what makes them keep scaling smoothly in between rather than jumping only at breakpoints, and the max end pins them back to the original desktop value so nothing above 720px changes. */ /* clamp()'d per explicit request, matching --text-small's own pattern right below — the comment above already documented this as the intent ("checked against 320-430px viewports") but this was left as a flat value. 17px floor holds through small phones (up to ~378px, where 4.5vw crosses it), then grows back to the original 22px by ~489px — bigger phones/phablets read at the same size as desktop; only genuinely narrow screens get the reduction. */ --text-body: clamp(17px, 4.5vw, 22px); --text-small: clamp(12.5px, 3.2vw, 15px); /* The marquee strips' own unique size (see .marquee-banner) — a deliberate third value roughly midway between --text-body and the marquees' old 40px display size, promoted to a shared root token so other spots (e.g. .square__role, the Get Involved roles grid's default role-name text) can reuse the exact same size on request, not just the marquees themselves. */ --marquee-text-size: clamp(21px, 6.5vw, 32px); --page-margin: 10px; /* Logo is 52px tall, centered 38px from the top (see --nav-item-center below) — so it needs at least 64px of bar before it'd start clipping. 70px keeps a small 6px breathing gap below it (down from the old symmetric 12px/12px at 76px total). */ --nav-height: 70px; /* Where the logo/nav text sit, measured from the bar's top edge — kept as its own fixed value (half of the OLD 76px height) rather than 50% of --nav-height, specifically so shrinking the bar (to tighten the gap before .viewport-frame takes over) doesn't also drag the nav items up with it. The bar shrinks from the BOTTOM only: top of items unchanged, less empty space below before the frame begins. */ --nav-item-center: 40px; /* How tall .site-header grows to while the Publications dropdown is open — tall enough to fit .nav__dropdown's own 5-item vertical list (see that rule for its own sizing/padding) below the main nav row. Value confirmed against the list's actual rendered height via Playwright, not just estimated from font metrics. */ --nav-height-expanded: 312px; /* Shared by the hero asterisk (13% of .hero__wordmark-wrap's own clamp(220px,22vw,380px)) and the intro splash's cream asterisk — computed out to a fixed clamp so both are guaranteed the exact same size rather than two independently-derived percentages that could drift apart. */ --hero-asterisk-size: clamp(28.6px, 2.86vw, 49.4px); } /* Newsreader (swapped in for a previously self-hosted font whose license didn't actually cover web serving — see the Kapakana @font-face below for the same reasoning). Both files are the real variable fonts (wght 200-800, plus an opsz axis left on its automatic default), not static instances, so one upright + one italic file covers every weight the site uses — 300 (body default), 400, 700, and the splash caption's 360 — via plain font-weight, no font-variation-settings needed. */ @font-face { font-family: "Newsreader"; src: url("../assets/Newsreader-Variable.woff2") format("woff2-variations"); font-weight: 200 800; font-style: normal; } @font-face { font-family: "Newsreader"; src: url("../assets/Newsreader-Italic-Variable.woff2") format("woff2-variations"); font-weight: 200 800; font-style: italic; } @font-face { font-family: "Kapakana"; src: url("../assets/Kapakana-Regular.ttf") format("truetype"); font-weight: 400; font-style: normal; } /* =================================================================== Reset =================================================================== */ *, *::before, *::after { box-sizing: border-box; } html, body { margin: 0; padding: 0; } html { background: var(--color-cream); scrollbar-width: none; /* Firefox */ -ms-overflow-style: none; /* legacy Edge */ } /* overscroll-behavior-y:none (both here and on body below) kills the rubber-band/bounce overshoot at the top/bottom of the page — per explicit request, wanted on DESKTOP only, where it read as fighting Lenis's own smoothed wheel scroll (see initLuxuryScroll() in main.js). Mobile never actually goes through Lenis in the first place — Lenis's smoothTouch defaults to false, so touch scrolling is already 100% native there — meaning this rule was the ONLY thing suppressing the bounce on phones too, not a deliberate mobile choice. (hover: hover), not a max-width breakpoint: this is genuinely about which input the device has, same reasoning as .applications-toast::before's own hover-only reveal elsewhere in this file — a touch tablet at desktop width should still get the native bounce back, same as a phone. */ @media (hover: hover) { html { overscroll-behavior-y: none; } } html::-webkit-scrollbar { display: none; /* Chrome / Safari */ } html.lenis, html.lenis body { height: auto; } html.lenis.lenis-smooth { scroll-behavior: auto; } /* Set synchronously in index.html's , before the intro splash's own screen-01 animation starts covering the page (see that inline script) — removed by initIntroScrollLock() in main.js once the splash has genuinely finished sliding away. Plain overflow:hidden is enough to block scroll regardless of Lenis: Lenis (initLuxuryScroll() in main.js) drives the browser's own native scroll position under the hood (just smoothed), so there's no separate transform-based scroll layer here for this to fight — no scrollable overflow means Lenis has nothing to move either. */ html.intro-scroll-locked, html.intro-scroll-locked body { overflow: hidden; } body { background: var(--color-cream); color: var(--color-dark); font-family: var(--font-body); font-size: var(--text-body); /* Newsreader Light (300) — the lighter weight, alongside 400/700 still available for anything that explicitly asks for them (e.g. none currently). */ font-weight: 300; line-height: 1.4; padding: var(--page-margin); } /* See html's own (hover: hover)-scoped override above — same reasoning, just the body side of the same property. */ @media (hover: hover) { body { overscroll-behavior-y: none; } } /* Per explicit request: body text "the slightest bit thicker" on mobile. Newsreader is a real variable font (weight axis 200-800, see the @font-face comment above), so this isn't limited to jumping to the next named weight (400/Regular, a much bigger jump from 300) — 360 is a small step up, already used elsewhere on this site (the intro splash caption) as an established "a bit heavier than the default Light" value, reused here rather than inventing a new one-off number. */ @media (max-width: 720px) { body { font-weight: 360; } } a { color: inherit; text-decoration: none; } h1, h2, h3, p { margin: 0; } img { max-width: 100%; display: block; } ul { list-style: none; margin: 0; padding: 0; } /* =================================================================== Intro splash — full-viewport asterisk flip-through, covering everything on load. Flips through 4 placeholder asterisks with hard cuts at a CONSTANT pace (350ms hold each — was an accelerating 600/350/200/150ms cadence, per feedback that it should stay steady instead of speeding up), each hold followed by a tiny 70ms blank gap before the next one cuts in — a beat between swaps rather than one appearing the instant the other disappears. The background cuts through a color per asterisk too (see the intro-splash-bg-* animations below) — deliberately paired with a DIFFERENT palette color than the asterisk's own, Monogatari-title-card style, not a single flat color or a same-family "wash": cream bg/red asterisk (01) / grey bg/tan asterisk (02) / tan bg/dark asterisk (03) / dark bg/grey asterisk (04) / red bg/cream asterisk (00, the real logo). Lands on the real one at 1680ms, lingers 250ms, then the whole screen slides up (opacity untouched — no fade) over 1s starting at 1930ms, same easeOutCubic curve as the hero slide-ins (cubic-bezier(0.33,1,0.68,1)). That reveals a brown layer sitting right behind it (see .intro-splash-layer), which itself slides up over 0.4s starting at 2430ms — halfway through red's own slide — to reveal a blue-grey layer behind THAT (2630ms, 0.4s, halfway through brown's) — a rapidfire cascade rather than a single reveal. Every other intro-delay on the page is set relative to the LAST layer finishing — see the HTML comment above
. =================================================================== */ .intro-splash { position: fixed; inset: 0; z-index: 9999; background: var(--color-cream); /* Lets the cream->red flip below (splash.style.backgroundColor, set by initSplashScreens() in main.js) crossfade instead of snapping — a `transition` reacts to that exact synchronous style change rather than running on its own separately-scheduled clock, so unlike the old @keyframes-based crossfade this removed (see comment below), it can't drift out of sync with the final screen's own cut-in. */ transition: background-color 0.45s ease-in-out; display: flex; flex-direction: column; justify-content: center; align-items: center; gap: 30px; pointer-events: none; /* Cream for the entire 01-04 run (a trial variant — was a different bg color per screen) — nothing to crossfade between phases 1-4 since the color never actually changes there, so only 2 bg animations total: cream at 0ms (steps(1) would be equally correct here since there's nothing to fade between, but 0.15s ease costs nothing and stays consistent with the red one below) and red at 1680ms, crossfading into the final/00 logo screen. Screens 01-04 vary by asterisk/caption COLOR instead (see intro-splash__asterisk--N below), red/blue/darker-beige/brown in that order. Slide delay bumped 1930->2180ms (+250) — lingers on 00 a bit longer before clearing. .intro-splash-layer--brown/--grey below (the rapidfire cascade this reveals) are shifted by that SAME +250ms to preserve their existing relative timing, and so are the hero title's own --intro-delay values in index.html (they're timed to start right as this cascade clears). initIntroReveal()'s final anchor timeout in main.js is NOT shifted — it's anchored to the eyebrow lines finishing (unaffected by any of this), not to the splash/title timeline, and stays comfortably later than both either way. intro-splash-slide is NOT in this unconditional list — see .intro-splash.is-ready-to-slide below. The 01-04 asterisk flip- through and landing on 00 are driven by initSplashScreens() in main.js, not CSS — see that function's own comment for why. It's only the SLIDE-AWAY that's held back until initIntroSplashHold() in main.js confirms the page is genuinely ready, so a slow connection lingers on the "00" logo screen instead of clearing to reveal a still-blank page underneath (see that function's own comment). The cream->red background change used to be driven by a separate CSS animation timed against the document timeline (intro-splash-bg- cream/-red, now removed) — a SECOND independent thing racing the same clock initSplashScreens() reads, which could drift from it under load the exact same way screens 1-4 could once drift from each other (see that function's comment): reported live as a "flash of nothing" right before screen 00, i.e. the background already having turned red while the final asterisk/caption hadn't cut in yet, or vice versa. initSplashScreens() now sets splash.style.backgroundColor directly, in the SAME synchronous callback as the final screen's own cut-in — one JS-owned state change instead of two independently-timed ones. Per follow-up feedback that the resulting flip still read as too abrupt, the `transition` above now crossfades it — safe against the same drift bug because a transition fires off that one synchronous assignment itself rather than running on its own separately-scheduled clock. */ } /* Added by initIntroSplashHold() once BOTH the minimum visual time (2480ms — matching the original fixed slide delay this replaces) AND real readiness (fonts loaded, DOM parsed) are satisfied, whichever is later — see that function for the exact race/timeout. */ .intro-splash.is-ready-to-slide { animation: intro-splash-slide 1s cubic-bezier(0.33, 1, 0.68, 1) 0ms forwards; } /* Smaller than the hero asterisk (0.65x) — this one's just a splash decoration, not meant to read at full hero size. Buzzes continuously through ALL FOUR numbered asterisks (1/2/3/4 — this is one shared wrapper, so whichever child asterisk is currently cut in rides the same wiggle), then DECAYS to a smooth, still stop in the brief 70ms gap between asterisk--4 hiding (1910ms) and the final/00 asterisk landing (1980ms — see .intro-splash__asterisk--final's own cut delay), so there's a genuine settled beat before .intro-splash itself slides away (2480ms). Buzz must stay at full amplitude all the way to ~96% (not decay gradually from 70% as an earlier pass did) — with a 270-1980ms window and the four numbered screens' visible windows scattered across the FULL span (asterisk--4's is 1560-1910ms, deep into what used to be the decay tail), a gradual decay starting too early left the later asterisks looking like they'd already gone still. Confining the decay to the invisible 1910-1980ms gap means every numbered asterisk gets the same lively wiggle, and the decay itself is never actually seen (nothing is on-screen during that gap) — only its result, a fully-settled final asterisk. One single, self-contained, non-infinite animation spanning that whole 1980ms window (not "infinite jitter forever, then separately triggered settle") deliberately avoids layering two named animations on the same element/property: a same-class-of-bug investigation elsewhere in this file (see the reset-timing work on the hero asterisk) found that when two animations both end up simultaneously active/forwards-filled on the same property, which one wins is NOT reliably "whichever is listed last" — a real browser quirk, not just a theoretical risk. A single keyframe list sidesteps that ambiguity entirely. Every offset stays small (max ~0.6px — an earlier ~1.5px read as too intense). */ .intro-splash__asterisk-wrap { position: relative; width: calc(var(--hero-asterisk-size) * 0.65); aspect-ratio: 184 / 200; /* 1900ms matches the final/00 screen's real landing time now that 01-04 were sped up (see SPLASH_SCREEN_CUT_DELAYS_MS in main.js, was 1980ms) — keyframe percentages below are unchanged, so the decay tail still lands right as "00" cuts in. */ animation: intro-splash-asterisk-jitter-settle 1900ms linear forwards; } @keyframes intro-splash-asterisk-jitter-settle { 0% { transform: translate(0, 0); } 5% { transform: translate(-0.6px, 0.4px); } 10% { transform: translate(0.4px, -0.6px); } 15% { transform: translate(-0.4px, -0.4px); } 20% { transform: translate(0.6px, 0.3px); } 25% { transform: translate(-0.5px, 0.5px); } 30% { transform: translate(0.3px, -0.5px); } 35% { transform: translate(-0.6px, 0.2px); } 40% { transform: translate(0.5px, -0.3px); } 45% { transform: translate(-0.3px, 0.6px); } 50% { transform: translate(0.4px, -0.4px); } 55% { transform: translate(-0.5px, -0.3px); } 60% { transform: translate(0.6px, 0.4px); } 65% { transform: translate(-0.4px, 0.5px); } 70% { transform: translate(0.3px, -0.6px); } /* Same buzz cycle repeated (not decayed) — keeps asterisk--3's and asterisk--4's own visible windows (1140-1490ms and 1560-1910ms) just as lively as asterisk--1's. */ 75% { transform: translate(-0.6px, 0.4px); } 80% { transform: translate(0.4px, -0.6px); } 85% { transform: translate(-0.4px, -0.4px); } 90% { transform: translate(0.6px, 0.3px); } 95% { transform: translate(-0.5px, 0.5px); } /* Decay tail, compressed into the invisible 1910-1980ms gap after asterisk--4 has already hidden — never actually seen mid-motion, only its settled result once the final asterisk cuts in. */ 97% { transform: translate(0.15px, -0.15px); } 98.5% { transform: translate(-0.05px, 0.05px); } 100% { transform: translate(0, 0); } } /* All 5 stacked in the same spot. Each one's own hide fires 70ms BEFORE the next one's appear (not simultaneously) — that gap is what reads as a beat of plain background between swaps rather than an instant replace. Two comma-separated animations per element (cut, then hide) — later-listed animation wins once both are in their forwards-fill period. object-fit:contain handles the 4 placeholder images' slightly different aspect ratios without distorting them. */ .intro-splash__asterisk { position: absolute; inset: 0; width: 100%; height: 100%; object-fit: contain; opacity: 0; } /* Each asterisk's caption (see .intro-splash__caption-wrap below) cuts in/out at the EXACT same timestamps as its own asterisk — sharing one selector list per phase keeps the two locked together with no risk of drifting apart if the timing ever changes. */ /* All 5 screens (1/2/3/4/final) are driven by ONE unified JS mechanism — initSplashScreens() in main.js — via a plain .is-cut opacity toggle, not animation-delay/steps(1) per screen. That WAS the system here (each screen's own cut/hide scheduled against the document timeline), and it held up fine for the general "connection is slow" case this whole file's comments describe at length. It did NOT hold up under real, sustained CPU throttling: confirmed live (6x CPU throttle via CDP) that a LATER screen's own cut-in could render AFTER an EARLIER screen's hide had already been superseded by the (JS-driven, elapsed- corrected) final screen's own cut — i.e. document.timeline.currentTime already reported "we're well past everything," while the renderer itself hadn't yet caught up repainting an EARLIER screen's own CSS animation to match that same current time. Two independent screens each racing the SAME document timeline can drift from each other under exactly the load conditions ("my computer is slow") this was supposed to survive. initSplashScreens() schedules every screen's cut AND hide via setTimeout, all read against the SAME document.timeline.currentTime snapshot at once, each one flipping its own is-cut in a single synchronous statement — there's no remaining path for two screens to disagree about where "now" is, because there's only one JS-owned answer to that question. Trade-off, deliberately accepted: screen 1 no longer appears before DOMContentLoaded (previously guaranteed by being pure CSS, independent of JS entirely) — on a connection so slow that DOMContentLoaded itself is meaningfully delayed, the cream background now shows a bit longer before the sequence starts, rather than screen 1 alone appearing early. Chosen over the alternative (visibly overlapping/glitching screens under load) per explicit feedback that the latter is the higher-priority failure mode. */ .intro-splash__asterisk--1, .intro-splash__asterisk--2, .intro-splash__asterisk--3, .intro-splash__asterisk--4, .intro-splash__asterisk--final, .intro-splash__caption--1, .intro-splash__caption--2, .intro-splash__caption--3, .intro-splash__caption--4, .intro-splash__caption--final { opacity: 0; } .intro-splash__asterisk--1.is-cut, .intro-splash__asterisk--2.is-cut, .intro-splash__asterisk--3.is-cut, .intro-splash__asterisk--4.is-cut, .intro-splash__asterisk--final.is-cut, .intro-splash__caption--1.is-cut, .intro-splash__caption--2.is-cut, .intro-splash__caption--3.is-cut, .intro-splash__caption--4.is-cut, .intro-splash__caption--final.is-cut { opacity: 1; } /* All 5 numbered/final screens share this now (trying out the bounce on 02/03/04 too, not just 01 and 00/final) — each stays blank a split- second longer, then blinks in with a quick vertical bounce, instead of the plain hard cut. animation (not transition) is what makes the "blank pause" possible in the first place — 120ms delay with fill mode `both` holds the keyframes' 0% state (opacity:0) for that whole window before the animation itself starts, where a transition has no equivalent concept of a pre-start hold. This wins over the shared opacity:1 rule just above for these same selectors regardless of source order/specificity — a running (or delayed-but-pending, via `backwards` fill) CSS animation always overrides a plain property declaration for the properties it animates. Each screen's own visible window (720/420/420/420ms for 1/2/3/4, per SPLASH_SCREEN_CUT_DELAYS_MS in main.js) comfortably outlasts this animation's 360ms total (120ms delay + 240ms run), so the bounce always finishes settling before the next screen cuts in. Composes fine with .intro-splash__asterisk-wrap's own continuous jitter-settle animation (a DIFFERENT element — the wrapper around all 5 numbered asterisks, see that class below) since nested elements' own `transform`s stack independently rather than fighting over the same property. The bounce itself animates the standalone `translate` property, NOT `transform` — .intro-splash__caption itself already carries its own static `transform: translateX(-50%)` for horizontal centering (the classic "center an unsized absolutely-positioned box" trick), and a CSS animation touching `transform` REPLACES that property's value outright rather than merging with it, silently discarding the centering the instant this animation applied (confirmed live: the caption text drifted off-center while the asterisk — which has no transform-based centering of its own to lose — stayed put). `translate` is its own independent property (composes with `transform` rather than overwriting it, applied before it per spec), so animating THAT instead leaves the caption's centering transform completely untouched. */ /* 1-4's own blank pause shortened to 40ms (was 120ms, still shared with 00/final below) per explicit request — that delay is the actual "blank space" between transitions here (the bounce itself doesn't start until it elapses), and 4/5 screens paying the longer 120ms pause added up to feel sluggish even after the per-screen hold times themselves got faster. 00/final keeps the original 120ms (see its own rule below) — same "mic drop shouldn't feel rushed" reasoning as SPLASH_SCREEN_MIN_HOLD_MS's own last entry in main.js. 40ms + this animation's 240ms run = 280ms total, still comfortably inside every screen's own 450ms visible window (per SPLASH_SCREEN_CUT_DELAYS_MS in main.js) with room to spare. */ .intro-splash__asterisk--1.is-cut, .intro-splash__caption--1.is-cut, .intro-splash__asterisk--2.is-cut, .intro-splash__caption--2.is-cut, .intro-splash__asterisk--3.is-cut, .intro-splash__caption--3.is-cut, .intro-splash__asterisk--4.is-cut, .intro-splash__caption--4.is-cut { animation: intro-splash-flicker-in 240ms cubic-bezier(0.34, 1.8, 0.64, 1) 40ms both; } /* Screen 00/final gets the same bounce, per explicit follow-up request — reuses the identical animation/keyframes verbatim, just its own original 120ms delay (not 1-4's shortened one just above) — see that rule's own comment for why. Nothing else on this screen depends on its own cut-in being instantaneous: the cream->red background crossfade is a separate, JS-driven inline style set in the SAME callback that adds is-cut (see initSplashScreens() in main.js), so it still flips right on schedule regardless of how long this element's own blank-pause- then-bounce takes to visually finish. */ .intro-splash__asterisk--final.is-cut, .intro-splash__caption--final.is-cut { animation: intro-splash-flicker-in 240ms cubic-bezier(0.34, 1.8, 0.64, 1) 120ms both; } @keyframes intro-splash-flicker-in { 0% { opacity: 0; translate: 0 0; } /* Snap to visible almost instantly once the animation itself starts — an abrupt opacity jump (not a fade) is what reads as "blink in" rather than a soft fade-in. */ 1% { opacity: 1; translate: 0 -4px; } 40% { translate: 0 1.5px; } 70% { translate: 0 -0.6px; } 100% { opacity: 1; translate: 0 0; } } /* Trial variant: screens 01-04 all sit on cream now (see .intro-splash above), varying by asterisk/caption color instead — red / blue (--color-grey, this project's informal name for it) / darker beige (--color-tan-dark, DBB388) / brown (--color-dark). Asterisk 1 and the final/00 asterisk keep plain tags (their own native PNG color already matches what's needed — red and cream respectively). 2/3/4 are
s instead (see index.html) — mask-image (the same PNG, used purely as an alpha stencil) over an explicit background-color is the only reliable way to recolor a raster asset to an ARBITRARY exact color; a plain 's own pixel colors can't be overridden by CSS. mask-size/position/repeat below stand in for object-fit:contain, which only applies to actual replaced elements (img/video), not divs. */ .intro-splash__asterisk--2, .intro-splash__asterisk--3, .intro-splash__asterisk--4 { -webkit-mask-repeat: no-repeat; mask-repeat: no-repeat; -webkit-mask-position: center; mask-position: center; -webkit-mask-size: contain; mask-size: contain; } .intro-splash__asterisk--2 { -webkit-mask-image: url("../assets/images/Asterisk 2.png"); mask-image: url("../assets/images/Asterisk 2.png"); background-color: var(--color-grey-splash-dark); } .intro-splash__asterisk--3 { -webkit-mask-image: url("../assets/images/Asterisk 3.png"); mask-image: url("../assets/images/Asterisk 3.png"); background-color: var(--color-tan-dark); } .intro-splash__asterisk--4 { -webkit-mask-image: url("../assets/images/Asterisk 4.png"); mask-image: url("../assets/images/Asterisk 4.png"); background-color: var(--color-dark); } @keyframes intro-splash-slide { to { transform: translateY(-100%); } } /* Caption: 2 lines (an italic word/phrase, then its "(0N)" tag) below the asterisk — Monogatari-style title-card text, not a caption in the nav/footer sense. The 30px gap above it comes from .intro-splash's own flex `gap` (it's the 2nd of 2 flex children, asterisk-wrap being the 1st) — just needs position:relative here as the containing block for its own stacked, individually absolutely-positioned captions below (same reason .intro-splash__asterisk-wrap needs it for its stacked asterisk images). No explicit height: with every .intro-splash__caption child absolutely positioned, this collapses to 0 height, which is fine — the flex gap only cares about this box's own (collapsed) edge, not its overflowing content. */ .intro-splash__caption-wrap { position: relative; } .intro-splash__caption { position: absolute; top: 0; left: 50%; transform: translateX(-50%); display: flex; flex-direction: column; align-items: center; gap: 15px; margin: 0; white-space: nowrap; text-align: center; opacity: 0; } .intro-splash__caption-line1 { font-family: var(--font-body); /* 360, not a standard static weight (300 Light/400 Regular) — sits deliberately between them on Newsreader's own variable wght axis, per explicit request for this one spot. */ font-weight: 360; font-style: italic; font-size: var(--text-body); } .intro-splash__caption-line2 { font-family: var(--font-display); font-size: var(--text-body); } /* "1" renders narrower than "0"/"2"/"3"/"4" in Instrument Serif's proportional digit widths — since each caption's line2 is independently centered (see .intro-splash__caption's align-items:center), "(01)"'s narrower digits leave less space between its parens than "(02)"/"(03)"/"(04)" do, which reads as the parens themselves shifting/breathing between screens even though they're centered the same way. Padding added specifically INSIDE "(01)"'s own parens (not a change to the parens or the container) widens just its digit pair to match how far apart "0"+"2"/"0"+"3"/ "0"+"4" naturally push the others' parens — see the wrapping span in index.html. */ .intro-splash__caption--1-digits { padding: 0 1.7px; } .intro-splash__caption--1 { color: var(--color-red); } .intro-splash__caption--2 { color: var(--color-grey-splash-dark); } .intro-splash__caption--3 { color: var(--color-tan-dark); } .intro-splash__caption--4 { color: var(--color-dark); } .intro-splash__caption--final { color: var(--color-cream); } /* Rapidfire cascade behind the red splash — see HTML comment. Each layer starts its own quick slide once the one ABOVE it is ~80% through its own slide (same "don't wait for the sub-pixel tail" convention used throughout the intro). Reuses intro-splash-slide (translateY only, no fade) since these are also just quick slides, not fades. JS-triggered now (.is-triggered, added by initIntroSplashHold() in main.js), not fixed/absolute CSS delays like this used to be — those old delays (2980ms/3180ms) were guesses tied to .intro-splash's own ONCE-fixed slide-away timing; once that became real-readiness-based instead (.intro-splash.is-ready-to-slide, same function), a connection slow enough to actually trigger the hold left this cascade's own fixed delays already elapsed by the time the splash FINALLY cleared — these layers had already finished sliding, invisible, stacked behind the still-present splash, so the whole rapidfire brown/grey flash silently never appeared at all (reported live on the deployed site). Hooking these off the SAME real moment the splash itself starts sliding — not a fixed guess — is what actually fixes that: no CSS-declared animation at rest, so there's nothing TO have already finished before the real trigger fires. */ .intro-splash-layer { position: fixed; inset: 0; pointer-events: none; } .intro-splash-layer--brown { background: var(--color-dark); z-index: 9998; } .intro-splash-layer--grey { background: var(--color-grey); z-index: 9997; } /* Delay is 0 on both — the "starts halfway through the previous layer's own slide" relationship (500ms into .intro-splash's 1s slide; 200ms into brown's own 0.4s slide) is baked into WHEN main.js adds these classes (via its own setTimeout pair, both anchored to is-ready-to- slide) rather than into a CSS animation-delay, so it stays correct however late that real moment ends up landing. */ .intro-splash-layer--brown.is-triggered { animation: intro-splash-slide 0.4s cubic-bezier(0.33, 1, 0.68, 1) 0ms forwards; } .intro-splash-layer--grey.is-triggered { animation: intro-splash-slide 0.4s cubic-bezier(0.33, 1, 0.68, 1) 0ms forwards; } /* Set synchronously in index.html's (the inline script right after __pageLoadStart), not by any JS that runs later — the splash's own screen-01 animation starts from parse time with no JS gating at all, so anything added only on DOMContentLoaded would be too late to stop a brief flash of it. Set when the "Overview" nav link was clicked to get here (see initNavPageFlash() in main.js) rather than a fresh reload or the logo (initLogoSecretEntry()) — per explicit request, only that one link should skip the splash, showing the quick .page-flash (below) in its place instead. Hides all 3 stacked full-screen layers instantly; initIntroReveal() in main.js separately shifts the hero's own entrance to start right away instead of still waiting out the (now invisible) splash. */ html.skip-intro-splash .intro-splash, html.skip-intro-splash .intro-splash__asterisk-wrap, html.skip-intro-splash .intro-splash-layer--brown, html.skip-intro-splash .intro-splash-layer--grey { animation: none; opacity: 0; visibility: hidden; } /* =================================================================== Page flash — a quick, un-choreographed flash shown on arrival at a page reached via the main nav (Overview/Publications/About Us/Get Involved — see initNavPageFlash() in main.js), instead of the elaborate homepage-only intro splash above. Same layout as that splash's own caption (reuses .intro-splash__caption-line1/-line2 directly), but with each screen's colors INVERTED from the intro's own cream-bg/colored-text convention: here each screen is a solid colored bg with light/dark text on top (01 red bg/cream text, 02 blue bg/beige text, 03 beige bg/brown text, 04 brown bg/blue text) — see the 4 "Asterisk N (nav).png" assets, which come pre-colored to match (unlike the intro splash's own asterisks 2-4, no CSS mask/recolor needed here). html.show-page-flash is set synchronously by each page's own inline / script (same early-execution reasoning as html.skip-intro-splash above) reading the one-shot sessionStorage["wfw-page-flash"] flag — see that script on each page for which number it checks for. Two layers, not one: .page-flash itself is a plain, ALWAYS-opaque cream cover — shown instantly (not animated) the moment html.show-page-flash is set, so the real page underneath is never exposed even for a frame. .page-flash__color (its one child) is the actual colored screen (bg + asterisk + caption), which fades in ON TOP of that solid cream backdrop. Animating the OUTER element's own opacity instead (an earlier pass) meant the real page showed faintly through it during the fade — cream never being FULLY opaque until the fade finished. =================================================================== */ .page-flash { position: fixed; inset: 0; z-index: 9999; background: var(--color-cream); pointer-events: none; opacity: 0; visibility: hidden; } /* Opacity/visibility set directly (not via `animation`) — instant, tied to html.show-page-flash ALONE (no .page-flash-ready requirement), so the cream cover is fully opaque from frame 1 regardless. Only the SLIDE is animated (and IS gated on .page-flash-ready — see that class's own comment on initPageFlashReady() in main.js for why); the fade-in lives on .page-flash__color below. Holds in place for the first 900ms (.page-flash__color's own fade + hold), then slides up and off over 900ms (900-1800ms) — same translateY(-100%) technique and easing as the intro splash's own .intro-splash-slide. The header's own drop-in below is timed to this animation's total 1.8s length, so it starts the instant this finishes sliding away. */ html.show-page-flash .page-flash { opacity: 1; visibility: visible; } html.show-page-flash.page-flash-ready .page-flash { animation: page-flash-slide 0.9s cubic-bezier(0.33, 1, 0.68, 1) 900ms forwards; } @keyframes page-flash-slide { to { transform: translateY(-100%); } } .page-flash__color { width: 100%; height: 100%; display: flex; flex-direction: column; align-items: center; justify-content: center; gap: 30px; opacity: 0; } /* 450ms ease-in-out, not the original 200ms/ease — per explicit follow-up feedback that the fade-in read as too abrupt. Softer/longer also means the hold below shrinks to 450ms so the total (fade+hold) still lands at 900ms, matching .page-flash's own slide delay above without needing to touch that number too. */ html.show-page-flash.page-flash-ready .page-flash__color { animation: page-flash-color-fade 0.45s ease-in-out forwards; } @keyframes page-flash-color-fade { to { opacity: 1; } } .page-flash__asterisk { height: calc(var(--hero-asterisk-size) * 0.65); width: auto; opacity: 0; } /* Continuous jitter, not the intro splash's one-shot settle-to-still (there's no "next screen" here to settle in time for) — reuses that same jitter's early values (see intro-splash-asterisk-jitter-settle above), just looped back to (0,0) for a seamless repeat. Comma'd alongside intro-splash-flicker-in (see .intro-splash__asterisk--1.is-cut above) so every page-flash screen pops in with the same blank-pause +bounce the intro splash's own screens 01/00 use, not just a plain fade — the two animations don't fight because they touch different properties (this one's `transform`, that one's `opacity`/`translate`). */ html.show-page-flash.page-flash-ready .page-flash__asterisk { animation: page-flash-asterisk-jitter 0.7s linear infinite, intro-splash-flicker-in 240ms cubic-bezier(0.34, 1.8, 0.64, 1) 120ms both; } @keyframes page-flash-asterisk-jitter { 0% { transform: translate(0, 0); } 12.5% { transform: translate(-0.6px, 0.4px); } 25% { transform: translate(0.4px, -0.6px); } 37.5% { transform: translate(-0.4px, -0.4px); } 50% { transform: translate(0.6px, 0.3px); } 62.5% { transform: translate(-0.5px, 0.5px); } 75% { transform: translate(0.3px, -0.5px); } 87.5% { transform: translate(-0.6px, 0.2px); } 100% { transform: translate(0, 0); } } .page-flash__caption { display: flex; flex-direction: column; align-items: center; gap: 15px; text-align: center; opacity: 0; } /* Same intro-splash-flicker-in bounce as the asterisk above, on the caption too — matches the intro splash, where screen 01/00's asterisk AND caption both bounce in together. */ html.show-page-flash.page-flash-ready .page-flash__caption { animation: intro-splash-flicker-in 240ms cubic-bezier(0.34, 1.8, 0.64, 1) 120ms both; } .page-flash--01 { background: var(--color-red); } .page-flash--02 { background: var(--color-grey); } /* Default --color-tan, NOT --color-tan-dark — that darker one-off is reserved for the intro splash's own screen 03 (see its own comment), not this unrelated inverted scheme. */ .page-flash--03 { background: var(--color-tan); } .page-flash--04 { background: var(--color-dark); } .page-flash__caption--01 { color: var(--color-tan); } .page-flash__caption--02 { color: var(--color-beige-nav); } .page-flash__caption--03 { color: var(--color-dark); } .page-flash__caption--04 { color: var(--color-grey); } /* Nav bar: same fade+drop-in treatment as the homepage's own .intro-reveal--drop (16px translateY, 0.45s ease-out), timed to start the instant .page-flash above finishes sliding away (1.8s) rather than the header just sitting there statically this whole time. Hidden state stays tied to html.show-page-flash alone (so it can't flash visible before .page-flash-ready arrives); only the animation itself (and its 1.8s countdown) waits on that class — see its own comment. */ html.show-page-flash .site-header { opacity: 0; transform: translateY(-16px); } html.show-page-flash.page-flash-ready .site-header { animation: page-flash-header-drop 0.45s ease-out 1.8s forwards; } @keyframes page-flash-header-drop { to { opacity: 1; transform: none; } } /* =================================================================== Header / Nav =================================================================== */ .site-header { position: fixed; top: 0; left: 0; right: 0; z-index: 100; /* Both children are positioned absolutely (see .nav__logo / .nav below) rather than flex-centered, so this needs an explicit height to center them against — with no in-flow content, height:auto here would collapse to 0. Both children share the exact same top:50%, which is what actually keeps them centered in the bar AND level with each other. */ height: var(--nav-height); /* NOT rounding this element's own corners — that was tried and is a dead end. The nav bar occupies y:[0, nav-height] exclusively, a space scrolled content never renders into, so its own rounded corner can only ever reveal the STATIC page background sitting behind it — never the scrolled section. Since that background is the same cream as the bar, the "reveal" is perfectly camouflaged: it isn't a rendering bug, the curve genuinely is there, it's just invisible against a matching color (confirmed by isolating a minimal repro: identical bug appears with a plain solid-color fixed bar over a matching-color body, no other complexity involved). The illusion has to come from .viewport-frame instead, since IT overlaps the actual scrolled content. */ /* NOT overflow:hidden here anymore — see .site-header__clip below for why that moved. */ } /* Holds everything that should be VISUALLY clipped/revealed as the bar grows (logo, nav, dropdown) — split out from .site-header itself so .nav__dropdown-hover-zone (below) can be a plain sibling of this, still a real descendant of .site-header (so :has() below can see it), WITHOUT being clipped by this element's own overflow:hidden. Earlier, with overflow:hidden directly on .site-header, the hover-sustaining hit-area was clipped in lockstep with the CURRENT (still-animating) height, lagging behind a fast-moving cursor reaching for a link and momentarily leaving NEITHER the trigger NOR the (not-yet-revealed) hit-area hovered — verified via Playwright: a continuous mouse path from the trigger toward a link showed the header's own height visibly plateau mid-growth, reported as "jitter." inset:0 keeps this tracking .site-header's own (animating) box exactly, at all times, with zero extra logic. */ .site-header__clip { position: absolute; inset: 0; padding: 0 32px; background: var(--color-cream); overflow: hidden; /* Without this, this plain wrapper div — not just its actual visible content — is a solid, opaque hit-test target across its ENTIRE box, including empty space with nothing visibly in it. Since it comes AFTER .nav__dropdown-hover-zone in the HTML (so ITS real content paints on top of that zone, see the zone's own comment), that stacking order means this wrapper's own empty space was ALSO always winning over the zone underneath, everywhere — verified: even far from any actual link, elementFromPoint resolved to this wrapper, not the zone, so the zone could never register hover at all. .nav already uses this exact pattern for its own children (pointer- events:none here, re-enabled on .nav__logo and .nav__links a). */ pointer-events: none; } /* Sustains the dropdown's open state across the FULL width of the screen and the full remaining height of the expanded bar — without this, only the narrow column actually containing the link text kept it open, so moving the cursor anywhere else in the (visually much larger) expanded header area closed the menu, which doesn't match how big that revealed region actually looks. A real element (not a .nav__dropdown pseudo) specifically so it can be .site-header's own DIRECT CHILD — a sibling of .site-header__clip, not nested inside it — meaning it's a real descendant of .site-header (so the :has() rules above can see it) while never being subject to .site-header __clip's own overflow:hidden, unlike the dropdown's actual visible content. That's what makes this always full-size the instant it becomes relevant, rather than clipped in lockstep with the still- animating height (see .site-header__clip's own comment for the Playwright-verified jitter this used to cause). pointer-events stays off by default — this sits BEFORE .site-header__clip in the HTML, so that element's own real content (including the actual clickable links) naturally paints on top of it, but with no hover of its own to report, this would otherwise just be dead space that's needlessly still watching for pointer input under the hero content whenever the menu isn't even open. Only switches on once the trigger (or this zone itself, to sustain) is already hovered. */ .nav__dropdown-hover-zone { position: absolute; /* top:0/height:100% of the WHOLE expanded bar (not just the sliver below the main nav row) — harmless, since this only ever becomes interactive (pointer-events:auto, below) once the dropdown is already open; hovering elsewhere up there (the logo, "About Us") while it's open just keeps it open, a reasonable trade for staying immune to the trigger
  • 's exact geometry entirely. */ top: 0; left: 0; right: 0; height: var(--nav-height-expanded); pointer-events: none; } /* pointer-events keyed off the SAME .nav__dropdown-is-open class that drives height below — see initPublicationsDropdown() in main.js for why this is a JS-managed class rather than a live :has(...:hover) condition. A live CSS condition here was tried first and is a genuine dead end, not just a stylistic choice: pointer-events would need to already be "auto" for the cursor moving from the trigger toward this zone to ever register on it, but a :has(trigger:hover) condition reverts to false in the exact SAME instant the cursor leaves the trigger — i.e. exactly when this zone would need to already be listening. Verified via Playwright (instrumenting pointer-events and :hover directly) that this produces a real window where NEITHER the trigger NOR this zone can be hovered, which read as the reported "jitter." JS sidesteps this because entering the trigger sets the class (and this zone's pointer-events) BEFORE the cursor ever needs to reach the zone, and a real elapsed-time grace period (not a same-tick CSS recomputation) is what decides when it later reverts. */ .site-header.nav__dropdown-is-open .nav__dropdown-hover-zone { pointer-events: auto; } /* Grows the WHOLE bar's height to reveal .nav__dropdown underneath, rather than the dropdown popping open as its own floating panel on top of the page — explicitly requested. .nav__dropdown-is-open is added/removed by initPublicationsDropdown() in main.js (mouseenter/ mouseleave + a grace-period timer on the trigger and the hover zone together), not a live :has(...:hover) condition — see that zone's own comment for exactly why a pure-CSS condition doesn't work for this. */ .site-header.nav__dropdown-is-open { height: var(--nav-height-expanded); } /* The height transition itself lives here, scoped to body.header-ready (set by initHeaderReady() in main.js once the header's own entrance has genuinely finished — NOT body.intro-finished, which is timed to protect the unrelated eyebrow lines' scroll-exit handoff and can stay unset for several seconds after the header itself is already sitting there fully visible; reusing it here left a real window where hovering "Publications" opened the dropdown with an instant height snap instead of animating), rather than on the base .site-header rule above — .site-header also carries .intro-reveal--drop (its one-time page-load fade+drop-in) OR the html.show-page-flash-scoped animation (arrival via nav click), either of which declares its OWN competing `transition`/`animation` at equal specificity; whichever rule is declared later in the file would silently win and fully discard the other's transition (shorthand properties replace, they don't merge). body.header-ready bumps this rule's specificity from (0,1,0) to (0,2,0), so it reliably wins regardless of file order — and since body.header-ready is only added once the header's entrance has genuinely finished, that entrance is completely unaffected. */ body.header-ready .site-header { transition: height 0.5s cubic-bezier(0.33, 1, 0.68, 1); } /* Retract gets its own, more dramatically-decelerating curve than the 0.33,1,0.68,1 "quick start, slow finish" used for opening — this one ("easeOutExpo," a common, recognizable "soft landing" shape) starts with almost all its motion up front, then spends a long final stretch crawling the last few pixels into place, so closing reads as genuinely easing into a smooth stop rather than just decelerating a little. A touch longer than the 0.5s open (0.65s) gives that long tail enough room to actually be perceived. Only overriding duration/ timing-function (longhands) here, not the whole `transition` shorthand — property (height) stays inherited from the base rule above unchanged. No close-debounce delay needed here anymore (an earlier version added one directly in CSS) — initPublicationsDropdown ()'s own grace-period timer in main.js already absorbs any brief flicker before .nav__dropdown-is-open is ever removed, so by the time this selector starts matching again, it's because the mouse genuinely, sustainedly left — no need for a second layer of debounce here too. */ body.header-ready .site-header:not(.nav__dropdown-is-open) { transition-duration: 0.65s; transition-timing-function: cubic-bezier(0.16, 1, 0.3, 1); } .nav__logo { position: absolute; left: 32px; top: var(--nav-item-center); transform: translateY(-50%); /* .site-header__clip (its own parent, see that rule) sets pointer-events:none across its whole box specifically so its own empty space doesn't sit on top of .nav__dropdown-hover-zone underneath — re-enable it here, same pattern .nav already uses for its own children (.nav__links a). */ pointer-events: auto; } .nav__logo img { height: 52px; width: auto; /* On the IMG, not .nav__logo itself — that already carries its own permanent translateY(-50%) centering nudge, and a hover transform declared there would replace it outright (transform is never additive across the SAME element). easeOutBack-style overshoot (values >1 in the 2nd/4th slots) is what gives a plain transition a genuine bounce/wobble feel with no keyframes needed — it overshoots past the resting tilt, then settles back. */ transition: transform 0.32s cubic-bezier(0.34, 1.56, 0.64, 1); } .nav__logo:hover img { transform: rotate(-14deg); } /* Same top:var(--nav-item-center) as .nav__logo — that shared value is what keeps the logo and nav text level with each other, pinned to a fixed position rather than the bar's shrinking 50% midpoint (see --nav-item-center comment in :root). */ .nav { position: absolute; left: 0; right: 0; top: var(--nav-item-center); transform: translateY(-50%); /* This box spans left:0 to right:0 (the full bar width) so its content can be centered, but that leaves its own hit-testable area stretching all the way to the left — silently sitting on top of .nav__logo and eating clicks meant for it, even though nothing is visibly there. Turned off here and re-enabled only on the actual links, so the empty space around them stops intercepting clicks. */ pointer-events: none; } .nav__links a { pointer-events: auto; } .nav__links { position: relative; display: flex; justify-content: center; gap: 32px; /* Uses --text-small rather than its own one-off scaled value — see the "2-3 sizes" rule on --text-body/--text-small in :root. */ font-size: var(--text-small); /* Book (400), not the site-wide Light (300) default — kept at the original weight rather than following body's drop to Light. (A thicker-weight test briefly lived here — that request was actually about the .section-eyebrow section titles on the publications pages, not this nav, so it's reverted.) */ font-weight: 400; /* Matches .hero__eyebrow's letter-spacing — 0.12em (previous value) was much wider than any other tracked text on the page. */ letter-spacing: 0.04em; text-transform: uppercase; } /* Nothing here scales with viewport at all otherwise — 4 links at 32px gaps plus the logo's own fixed 32px/52px (see .nav__logo/ .nav__logo img) simply don't fit a narrow phone width, confirmed live: "OVERVIEW" overlapping the logo at 600px, clipped off the left edge entirely by 375px. Small enough to still read as the same nav, not a hamburger-menu redesign. */ @media (max-width: 720px) { .nav__links { gap: 6px; font-size: 10.5px; letter-spacing: 0.02em; } .site-header__clip { padding: 0 16px; } .nav__logo { left: 16px; } .nav__logo img { height: 36px; } /* .nav__links is centered within .nav's own FULL left:0/right:0 span (see .nav's own comment on why it can't just be narrowed), so "OVERVIEW" (the first, leftmost link) can still land under the logo even after the sizing fixes above — confirmed live: 38px of overlap remained at 375px. Reserving real space on the left (logo's own 16px position + 36px width + a small gap) shifts the centered group's available area to actually start clear of it. */ .nav { padding-left: 60px; } } /* Solid palette color, no opacity dimming — hover swaps to the brand accent red instead of just fading, so the interaction stays on the 5-color palette rather than inventing a faded shade. */ .nav__links a { color: var(--color-dark); transition: color 0.15s ease; } .nav__links a:hover { color: var(--color-red); } /* Underline for whichever nav link is the current page — positioned via JS (left/width matched to the active link's own offsetLeft/ offsetWidth) rather than a per-link ::after, since it lives in its own
  • . That
  • is taken out of the flex flow (position:absolute) so it doesn't consume a gap slot like a normal flex item would, but it still needs inset:0 to fully cover .nav__links — a bare top/left:0 collapses it to a 0x0 box, which made the indicator's own bottom:0 resolve against that empty box (rendering it at the TOP of the nav instead of under the text). See initNavHighlight() in main.js. */ .nav__indicator-slot { position: absolute; inset: 0; /* Covers the full .nav__links box (needed so the indicator's own bottom:0 has a real box to measure against — see comment above) — but that means it's painted on top of the actual links (later in DOM order). Without this, it silently eats all hover/click events on the whole nav. */ pointer-events: none; } .nav__indicator { position: absolute; bottom: -3px; height: 1px; /* Scaling a 1px box down renders as a true sub-pixel hairline on retina displays instead of a flat 1px bar — thinner than height alone can get you. */ transform: scaleY(0.75); background: var(--color-dark); transition: background-color 0.15s ease; pointer-events: none; } /* Same red-on-hover convention as .nav__links a itself (color 0.15s ease, right above) — the underline only ever sits under the ACTIVE link (see initNavHighlight() in main.js), so :has() on that link's own
  • is what lets this plain sibling
  • (.nav__indicator-slot, later in the same