/* About — a state of the hero stage, not a separate page. Requires base.css and hero.css. Clicking `about` puts `.is-about` on the section. hero.css owns the curtain every section shares — the front chevron sliding left onto the mid chevron, the fourth chevron arriving from the right edge, the logo folding into the corner. What about adds is what rides in on that fourth chevron: the copy column, the scroll rail, the gallery and the lightbox. All geometry is a percentage of the stage, measured off `references site/sections/about/`. */ .hero { /* The fourth chevron's two edges, as lines on the stage. The chevron itself lives in hero.css. These two line equations are the algebraic source of `.about-gallery__peek`'s and `.about-gallery__tile`'s own `clip-path` polygons further down — each vertex there is one of these lines solved against that box's own edges and rebased onto it (subtracting the box's `left`/`top`). The chevron art is sized by height (130%) with `width: auto`, so its slope is fixed in pixels by the art's own aspect — 0.579 px across per px down — and only its offset moves with the viewport. Measured off 1600x811 and 1920x1080 captures; both fits agree to four decimals and predict either capture within 0.6px: lower arm x = --arrow-far + 19.336dvh + 0.579y upper arm x = --arrow-far + 60.996dvh - 0.579y apex (--arrow-far + 40.166dvh, 35.976dvh) This is why the cuts below are written in vw/dvh and not in percentages of the clipped element: a percentage polygon stretches with its own box, so it only lines up at one aspect ratio and drifts off the arrow everywhere else — about 13px at 1920x1080. */ /* Gallery block. The tile is the opaque panel the photo is inset into, by an equal 0.9% on both sides. The reference measures wider on the left, but the tile's left edge is where --peek ends, so the gutters are evened against the photo rather than by moving the tile — moving it would open a seam against the peek. 0.9% and not less: the gutter also has to hold the photo clear of the fourth chevron's lower edge, which crosses the tile's bottom-left corner. At 0.65% the photo's own corner overhung that edge by 3px. */ --tile-left: 69.76%; --tile-top: 29.57%; --tile-width: 27.76%; --tile-height: 38.01%; --photo-left: 82.32%; --photo-top: 31.14%; --photo-width: 14.3%; --photo-height: 34.87%; /* Copy column and its rail. --copy-left/--copy-width narrowed by 10 percentage points on request ("make the width of the column 10% less on the left side") — the left edge moved right from 36.11% to 46.11%, the width dropped from 34.2% to 24.2%, and the right edge (70.31%) held fixed, since only the left side was asked to give up width. That right edge is also what services.css's --bento-right reads (`calc(var(--copy-left) + var(--copy-width))`), so it needed no change, and --rail-x (71%, just clear of the right edge) didn't either. Later widened back 5 points from the left, on request ("make it wider to the left by 5%") — --copy-left: 46.11% -> 41.11%, --copy-width: 24.2% -> 29.2%, right edge still held at 70.31% (41.11 + 29.2 = 70.31), so services' --bento-right and --rail-x again needed no change. --copy-left itself STAYS a bare literal — services.css's --bento-right and events.css's --events-right both read `calc(var(--copy-left) + var(--copy-width))` as a stable anchor for their own right edge, and custom properties resolve by cascade at the element that reads them, not by which file declared them: if --copy-left were tied to --shift-front, those two cross-file reads would resolve --shift-front at *their own* element (inside .is-services/.is-events, where it's always the base 0cqw, not -9cqw) and silently land 9 points too far right. Tried exactly that first, caught it from a visibly widened services grid, reverted to this. */ --copy-left: 41.11%; /* The copy column's own `left`, unlike --copy-left above, DOES follow the front chevron's travel — matching the pattern products.css/events.css already use for their own left edge (--products-left off --shift-back, --events-left off --shift-quad). Without this, retuning --shift-front in the future would silently desync the column from the chevron it sits next to. Base is 50.11%, so --shift-front's always-exactly- -9cqw whenever `about` is showing lands this at 41.11%, the same value --copy-left holds. Only about's own elements (below) read this one; --bento-right/--events-right keep reading the stable --copy-left above, untouched. */ --copy-left-live: calc(52.11% + var(--shift-front)); /* --copy-width itself (below) stays the stable, original 29.2% — it's what services'/events' own --bento-right/--events-right read (`calc(var(--copy-left) + var(--copy-width))`), the same cross-file stability --copy-left already gets its own comment for above. --copy-width-live is the about-local width .about__copy itself actually reads — a plain alias to --copy-width here (so it's identical by default), overridden separately per breakpoint below (see "Laptop tier" further down) rather than ever touching the shared --copy-width directly. This split exists because an earlier pass narrowed --copy-width itself, which silently narrowed services'/ events' own right edge too (neither was asked to change) — caught and fixed by introducing this pair. Desktop tier narrowed 2 points from the left, on request ("make the column 2% narrower from the left, only on desktop") — --copy-left-live above moved 50.11% -> 52.11%, and this dropped the matching 2 points off the width so the right edge (--copy-left-live + --copy-width-live) holds fixed. Laptop tier's own override below is untouched. */ --copy-width-live: calc(var(--copy-width) - 2%); --copy-width: 29.2%; --rail-x: 71%; } /* ---------- Laptop tier ---------- Everything in this block is laptop-only geometry (aspect <= 1.85:1 — see hero.css's own "Sub-page content geometry" comment, once one exists, for the shared threshold; for now this is the first file to introduce it, on request: "make this breakpoint thing and what we have did in this session apply it only on the laptop version"). Outside this range (a plain wide desktop window) the section falls back to the base `.hero` values just above, i.e. today's pre-this-session geometry. Every property overridden here was tuned this session against laptop- sized captures (1600x900 and similar) specifically, one request at a time — see each one's own history below. */ @media (max-aspect-ratio: 1.85/1) { .hero { /* Pulled right of the synced value above, on request ("move the column with the rail 1% right", then "now with 2%", then "make it 5%" — found to visibly crowd both the rail's text-side neighbor and the gallery once screenshotted at 5% — then "make it 3% and narrow the column by 2%", then "position should be 4%", then "make the position to 3.5% and make the column narrower by 0.5%", then finally "make it 1% narrower"). Base 50.11% -> 53.61%, so the column (and --rail-x just below, to stay clear of its new right edge) sits 3.5% right of where --copy-left/--copy-width alone would still put it. This is about's own rendered position only; --copy-left itself is unchanged, so services'/events' own --bento-right/--events-right reads (which key off --copy-left, not this) are unaffected. Moved a further 2 points right on request ("move the title and paragraph by 2% to the right, keep the rail in its position"): 53.61% -> 55.61%. Width (--copy-width-live) is untouched, so this is a pure translate of the title/copy box, not a narrowing — --rail-x (below) was deliberately left alone, since the rail was asked to stay put. The box's own nominal right edge (left + width = 55.61% + 25.7% = 81.31%) sits well past --rail-x's 74.5% — the paragraph's actual wrapped text does reach into the rail's line at this width (confirmed by screenshot at 1600x900: "operational" and "...services be" both run into/through the rail), and was already nearly touching it before this move (79.31% right edge). Flagged to the user with a before/after screenshot; accepted as-is — the overlap is not being treated as a bug to fix. */ --copy-left-live: calc(55.61% + var(--shift-front)); /* Narrowed from the plain --copy-width alias above: dropped 2 points (29.2% -> 27.2%) at the "3% and narrow by 2%" step, then 0.5 (-> 26.7%), then a further 1 (-> 25.7%) at the final "make it 1% narrower" step. */ --copy-width-live: 25.7%; /* Kept clear of the copy column's new right edge above. */ --rail-x: 74.5%; /* The gallery's thumbnail-state size/position (--tile-left/-width/ -height, --photo-*) was shrunk ~15% and moved right here for a while ("make the about gallery before clicking on it smaller and move it to the right a bit"), then nudged left several times over several follow-ups, then reverted in full ("okay also revert the scaling") — back to no laptop-tier override at all for a while. Only the peek clip-path fix below (a real bug, not this experiment) survived that whole run. A second, separate experiment ("now just move this whole galler 2% right" — no resize this time, just `--tile-left`/`--photo-left` plus the peek/nav-arrow `left`s below) went through +2, +1.5, then +1.7 points before being reverted in full too ("okay revert this whole thing back to before moving it to the right"), on the same "clips the nav-next arrow" problem described just below. Revisited and actually landed in an earlier session ("move the images and the arrows 2% to the right"). Base 69.76% -> 71.76% / 82.32% -> 84.32%, a plain +2 points on both — this is the tile/photo pair; the peek's own `left` and the two nav arrows' `left`s are literals on their own rules further down (`.hero .about-gallery__peek`, `.hero .about-gallery__nav--prev/--next`), not read from these two custom properties, so each needed its own matching edit down there. `--next` is the one exception, not a plain +2 — see its own rule for why. `--tile-left` alone was then moved back 2 points on request (2026-09-01, "move the about tile 2% to the left") — 71.76% -> 69.76%, i.e. back to the same value as the desktop base rule. Confirmed with the user this was meant literally (`--tile-left` only, not the whole tile/photo/peek/arrow group above) — since `.about-gallery__tile`'s own fill is the same color as the page background, this has no visible effect on its own. `--photo-left` (84.32%) and the peek/nav-arrow literals below are unchanged, so they're now 2 points to the right of `--tile-left` where they used to share its value — a deliberate, confirmed-good mismatch, not drift to fix. */ --tile-left: 69.76%; --photo-left: 84.32%; } .about__copy { /* 1 point smaller than the base 61% below, on request ("make its height 1% samller"). */ height: 60%; } /* Bug fix, not a design change: the peek photo's clip-path (base rule, below) is deliberately tuned so its taper reaches *exactly* the peek's own right edge at the bottom — bottomcut (`-16.65cqw + 55.715cqh`) equals `--photo-width`... no, equals the peek's own fixed 11.66%-of- stage width almost exactly (186.56px vs 186.55px measured at 1600x813) — confirmed not a coincidence. That equality only holds near the design aspect the constants were fit at. The chevron-tracking terms are `cqh`-heavy, so as `.hero` gets relatively taller at laptop aspect (clamped as low as 1.7:1 by `--stage-min-aspect`), bottomcut grows past the peek's own box — measured 138% of the peek's width at the 1.7 floor, still 115% at the laptop tier's own 1.85 edge. Past 100% the polygon's clip line sits outside the box entirely, so the visible photo collapses to a point partway up instead of tapering to the tile's bottom-left corner, leaving the corner as a bare gap instead of a graceful taper — this is the "gallery overflows onto the arrow" report. Re-deriving bottomcut to land back on 100% would need it to reach ~138% of the *available* gap to the main photo at the 1.7 floor (measured: 244px of clip-path-formula travel vs only 190px of actual room before `--photo-left` begins) — the chevron's real edge has moved further right than the laptop-tier layout has room for, so exactly tracking it isn't possible here regardless of constants. Pinned instead to a fixed taper proportional to the peek's own box (not `cqw`/`cqh`-tracked) — same visual proportions the desktop taper has (37.3% visible width at the top edge, narrowing to the peek's own bottom-right corner, with the same small kink partway down) — so it always closes cleanly regardless of exactly where in the laptop aspect band the window lands. No laptop reference mockup exists to match pixel-for-pixel (like `events`, see CLAUDE.md); "closes cleanly, same proportions as desktop" is the bar here. Selector is `.hero .about-gallery__peek`, not the bare class the base rule below uses: the base `.about-gallery__peek` rule sits *after* this media block in the file, so at equal specificity it would win the cascade regardless of which aspect actually matches — confirmed via computed style (`getComputedStyle` still showed the base `cqw`/`cqh` polygon at 1512x982 with only the bare class here). The extra `.hero` ancestor is harmless (peek is always inside it) and raises specificity enough to win unconditionally once the media query itself matches. */ .hero .about-gallery__peek { /* Revived 2026-08-31: this had been set to `none` (see the history below this comment) on the reasoning that the gallery sits in front of every chevron now, so there was supposedly no edge left to track. That reasoning missed a second job this taper was always doing — the one the file's own top-of-file `--tile-left`/`--rail-x` comment still describes: keeping the peek's *visible* pixels short of wherever the rail sits, even though the box itself is wide enough to reach under it. With this at `none`, the peek rendered as a plain rectangle running the box's full literal width, and at laptop aspect specifically — where `--rail-x` sits at 74.5%, well inside this box's own 69.76%–81.42% span — the rail's hairline and down-arrow ended up drawn directly across the photo. Screenshot-confirmed at 1512x982 (clamped ~1.7) and 1366x768 (~1.78); desktop doesn't have this (`--rail-x: 71%` also sits inside this box there, but desktop was never reported broken and is intentionally left untouched here). Plain `%` polygon, not `cqw`/`cqh` — resolves against this box's own width/height directly, so it can't drift the way the old dvh-tracked version did (see "the gallery overflows onto the arrow" history just below), and its minimum x only has to clear the rail once, not at every aspect. Kept the same shape family the old fix already described (wide at the top, tapering to a point at the box's own bottom-right corner). Minimum x is 28% of the box width today. This paragraph used to claim a much narrower cut (a "was 42%/58%, now 40%/60%" history ending near the rail's own footprint with a comfortable ~52px margin) — that text had drifted out of sync with the live rule for an unknown stretch of time; the code actually read 30% (not 60%) when checked on 2026-09-01, leaving only a ~0.2px gap to the rail (`--rail-x: 74.5%`) instead of the ~53px the old comment described — visually read as the taper running right along the rail. Tried restoring it to 60% to reproduce the documented margin; screenshot rejected on request ("not good"), reverted back to 30%. Immediately after, moved 2 points further left on request ("move that polygon 2% to the left"): 30% -> 28%. So today's 28% is a deliberate, confirmed-good value, not a typo to "fix" back toward 60% — don't re-derive it from the rail-clearance math this comment used to cite; that math no longer describes what's wanted here. */ clip-path: polygon(100% 0%, 28% 0%, 100% 100%); /* Matches --tile-left's own +2 point shift above ("move the images and the arrows 2% to the right") — the peek's box is otherwise a bare literal (its base rule, further down, doesn't read --tile-left even though the two happen to share a value at the base geometry), so it needs its own copy of the same shift rather than picking it up automatically. */ left: 71.76%; /* top/left/width/height all briefly had their own laptop-tier overrides here too, across two separate resize/reshift experiments — both fully reverted (see the long comment on `.hero` above), leaving only this `clip-path` fix. At the base geometry the box this clip-path applies to is `left: 69.76%; top: 33.99%; width: 11.66%; height: 28.84%` (this file's own base `.about-gallery__peek` rule, further down). An attempt to instead widen this rule to exactly track the chevron's true edge ("place the tile photo... exactly into the corner") was also tried and reverted same-session ("revert it its not good") — it required growing well past this box's width, which pushed the peek's visible region into an overlap with the main photo. Kept here only so a future session doesn't re-try the same approach expecting a different result — closing that overlap needs `--photo-left` (or the main photo's own geometry) to move too, not just the peek. */ } /* Laptop-tier only, on request: the gallery sits *behind* `.arrow--far` was the first attempt here — reverted the same session once rendered: `.arrow--far`'s image is sized to cover the entire gallery footprint, and (per hero.html's own note that "arrows are currently flat/uniform color") its body is close enough to `--blue-deep` to read as empty background, so "behind far" didn't nick a corner, it erased the whole gallery invisibly. Landed instead on "between `.arrow--front` and `.arrow--far`": gallery gets the same z-index (3) as both. Front never geometrically reaches the gallery's screen area at this or any aspect, so the only tie that matters in practice is against far — and ties resolve by DOM order, with `.about-gallery` sitting later in hero.html than either arrow, so it wins and paints on top of far, restoring full visibility. No chevron actually cuts into the gallery's corner this way (that would need a real clip-path re-derived against far's true edge, not attempted here) — this only fixes the swallow. Desktop is unaffected either way (gallery in front, via `.about- layer`'s unconditional z-index:20 from hero.css's `.section-layer` rule). `.about-layer`'s z-index is what traps every descendant above the chevrons — a descendant can never out-rank an element outside its own ancestor's stacking context, so the only way to let the gallery's z-index compete directly with an *arrow* (a sibling of `.about-layer`, not a descendant of it) is to stop `.about-layer` itself from establishing one here. `.about__title`/`.about__copy`/`.about-rail` get their own explicit z-index (above the gallery's 3, so the text stays readable over it regardless) to compensate for losing the layer's former z-index:20. **Any new direct child of `.about-layer` needs adding to that same list, or it silently paints underneath the (fully opaque) chevron art at this tier** — caught once already, when the motto banner (`.about__motto`, see its own comment further down) briefly lived here as a direct child: it shipped without a z-index, and computed style showed everything correct (visible, opacity 1, real geometry, even a debug `background: lime` set via devtools) while still not appearing in any screenshot, because a chevron with an explicit z-index was painting over it. Confirmed via `document.elementFromPoint` at the element's own center returning `.about-gallery` (z-index 3) instead of the element itself, and via a `getComputedStyle` diff against `.about__title` that isolated `z-index: auto` vs `4` as the one differing property. The motto banner has since moved to be a child of `.about__copy` instead (see its own comment), which sidesteps this trap entirely — but the trap itself is still real for whatever direct child of `.about-layer` comes next. */ .about-layer { z-index: auto; } .about-gallery { /* z-index is a no-op on a `position: static` element (its base rule, further down, sets none), so it needs its own positioning for the z-index above to take effect at all. `position: relative` alone would leave it sized by normal flow — width matching `.about-layer` (fine), but height auto-collapsing to ~0 since every child inside is itself `position: absolute` and contributes nothing to flow height — and every child's own left/top percentages resolve against *this* box once it's positioned, not `.about-layer` anymore, so a collapsed height would break all of them vertically. `inset: 0` instead makes it full-bleed, matching `.about-layer`'s own box exactly, so nothing downstream needs to change. */ position: absolute; inset: 0; z-index: 3; } .about__title, .about__copy, .about-rail { z-index: 4; } /* Nav arrows, same "move the images and the arrows 2% to the right" request as --tile-left/--photo-left above — both are bare literals on their base rule (further down), not tied to either custom property, so each needs its own laptop-tier override. `.hero` prefix for the same cascade-order reason the peek's own override above needs it: the base `.about-gallery__nav--prev/--next` rules sit later in the file, so a bare-class selector here would lose to them even once this media query matches. */ .hero .about-gallery__nav--prev { /* +5 points on request ("move them 5% to the right") — 82.31% -> 87.31%. `--next` got the same request but couldn't take the full 5 points; see its own rule below. Then pulled back 3 points ("move the left arrow back by 3%", 87.31% -> 84.31%), then back a further 2 ("okay back by 2%", 84.31% -> 82.31%, net back to the pre-shift value), then +1 ("now move it to right by 1%", 82.31% -> 83.31%), then -0.5 ("okay now 0,5% to the left", 83.31% -> 82.81%), then +0.2 on a final follow-up ("okay no move the arrow left 0.2% to the right", 82.81% -> 83.01%). */ left: 83.01%; } /* 20% smaller, on request ("make the nav bar prev and next 20% smaller") — base width is 1.49% (shared with `.lightbox__step` on its own base rule, which this selector deliberately does not touch), 1.49 * 0.8 = 1.19%. The svg inside scales with it (its own rule is `width: 100%; height: auto`), so the icon shrinks proportionally, not just its clickable box. Left unpositioned otherwise — `left` is each arrow's own left edge, so shrinking width only pulls each icon's *right* edge inward, giving `--next` a bit more clearance from the stage edge on top of the margin its own override above already keeps. */ .hero .about-gallery__nav { width: 1.19%; } /* Not a plain +5 like `--prev` just got ("move them 5% to the right"), on purpose — same stage-edge constraint as this arrow's earlier +2 shift (see the long comment on `.hero` above): `.hero` has `overflow: hidden` (hero.css), and at its current 1.19%-wide box (post-shrink, above) there's only 0.6 points of room between its resting right edge (99.4%) and the stage's own 100% edge — nowhere near 5 points of travel available. Pulled in only as far as that room allows: 98.21% -> 98.51%, keeping a 0.3-point clearance to the right edge (99.7%) rather than pushing flush to it. A further +0.5 request ("move the right arrow also 0.5% to the right") hit the same ceiling again — only 0.3 points of room were left, not 0.5. Took as much as a small safety margin allows: +0.2 (98.51% -> 98.71%, right edge 99.9%), leaving 0.1 points clear of the stage's own edge rather than landing exactly flush on it (a flush edge risks sub-pixel clipping from rounding/antialiasing under `overflow: hidden`). Any further rightward request here needs `--next` shrunk smaller first to free up more room — see the shrink's own comment above. */ .hero .about-gallery__nav--next { left: 98.71%; } } /* ---------- State ---------- */ /* The base `.section-layer` rule is in hero.css; this turns about's own layer on. The fourth chevron's band never reaches left of its own apex, so it clears the rail and the copy column entirely. */ .is-about .about-layer { opacity: 1; visibility: visible; pointer-events: auto; transition: opacity var(--ease-fade) var(--delay-settle), visibility 0s linear var(--delay-settle); } /* `about` is the current section once it lands on the mid chevron's point, so it stops being a link there. `services`, which owns that point in the hero, stays visible underneath it and is the way on to the next section. Restates the eased `transition` (`hero.css`'s unconditional rule now delays `opacity` instead, for the leaving direction) so entering still fades this out smoothly as it travels in, unchanged from before. */ .is-about .hero-nav__link--about { opacity: 0; pointer-events: none; transition: transform var(--ease-move), opacity var(--ease-move), color var(--ease-ui); } /* All four chain chevrons + the decorative `.arrow--far` were previously hidden outright for `about` (both here and in hero.css's shared `.arrow--far` arrival group) because the curtain bands were reported showing through under part of the copy paragraph at some window aspect. Restored on a later request instead of left hidden — matches the reference (`about_full.png`), which shows the front-onto-mid travel and the framing fourth chevron with the copy column sitting cleanly in the open band between them at the design aspect. If the overlap resurfaces at a specific window aspect, screenshot that aspect and fix the actual geometry drift (the copy column's `cqw`-based position vs. the chevrons' `cqh`-driven diagonal edges — see hero.css's tip-offset drift fix for the same class of bug) rather than re-hiding the chevrons. */ /* ---------- Copy column ---------- */ .about__title { position: absolute; left: var(--copy-left-live); top: 11%; margin: 0; font-family: var(--font-utility); font-size: var(--size-heading); font-weight: normal; /* Far wider than the nav's tracking — the section title is the one place the copy column borrows the wordmark's spacing. */ letter-spacing: 0.04em; text-transform: uppercase; color: var(--paper); } /* Motto banner — a short mission statement, on request. Lives as the *first child inside* `.about__copy` (hero.html), not a sibling of it — tried as a sibling pinned above the scroll first, reverted on report that it read as a sticky header while the paragraph scrolled underneath it ("i dont want it, if i scroll down the motto should disappear, like it the part of the paragraph"). As a normal in-flow child of the scrolling column it scrolls away with the rest of the text instead, and the column's own width/position needed no separate copy of `--copy-left-live`/`--copy-width-live` — it simply inherits its parent's box. `.about__copy`'s own `top`/`height` are back to their original plain `18%`/`61%` for the same reason: nothing needs carving out of the column's footprint anymore, since the banner now counts toward the column's own scrollable content instead of sitting outside it — see CLAUDE.md's "The about choreography" for the full history of the sibling approach this replaced. Filled with `--panel-elevated` (light blue, on request) — the "floating above the base panel" tone this token already carries elsewhere (the lightbox pdf box, cta-card hover), reused here rather than introducing a new blue. The small icon (the site's own star-only brand crop, already used for the favicon) sits fully inside the box, directly on the panel — no badge disc behind it (tried a `--paper` circle first, removed on request). */ .about__motto { display: flex; align-items: center; gap: 1.4cqw; background: var(--panel-elevated); padding: 1.6cqh 1.8cqw; margin: 0 0 var(--lh-body); } .about__motto-icon { width: 4cqw; height: 4cqw; display: flex; align-items: center; justify-content: center; flex: none; } .about__motto-icon img { width: 100%; height: 100%; object-fit: contain; } .about__motto-text { margin: 0; font-family: var(--font-utility); font-size: 2.1cqh; line-height: 2.7cqh; color: var(--paper); } .about__copy { position: absolute; left: var(--copy-left-live); top: 18%; width: var(--copy-width-live); /* Bottom edge pulled up 5 points on request ("reduce the height on the bottom by 5%") — was 71.9%, top held at 17.6% so only the bottom moved. Nudged to 66%, then pulled up another 5 points to 61% on request. Top then nudged from 17.6% to 18% on request, height left unchanged. A further 1-point reduction ("make its height 1% samller") is laptop- tier only — see the "Laptop tier" media block above. */ height: 61%; overflow-y: auto; scrollbar-width: none; font-family: var(--font-utility); font-size: var(--size-body); line-height: var(--lh-body); color: var(--paper); /* The reference fades the last lines out rather than clipping them, so the column reads as continuing past the frame. The gradient's own stops (88%/100%) never change — animating them directly needs a registered custom property (`@property`), which turned out not to actually interpolate `mask-image` in practice (verified: the computed value sat frozen at 88% long past the transition's duration). `mask-size` is transitioned instead: growing the mask taller than the box, anchored at its top, pushes the gradient's fixed 88%-100% fade band down past the box's own bottom edge — same visual result, standard animatable property, no registration needed. */ -webkit-mask-image: linear-gradient(to bottom, #000 88%, transparent 100%); mask-image: linear-gradient(to bottom, #000 88%, transparent 100%); -webkit-mask-repeat: no-repeat; mask-repeat: no-repeat; -webkit-mask-position: top; mask-position: top; -webkit-mask-size: 100% 100%; mask-size: 100% 100%; transition: -webkit-mask-size var(--ease-ui), mask-size var(--ease-ui); } /* Once scrolled to the actual end of the text, there's no more content below to fade into — the gradient was just eating the last 1-2 lines with nothing to justify it. `about.js`'s syncRail adds this class once the column's scroll position reaches its max. Growing the mask to 120% of the box's height (anchored top, per mask-position above) puts the gradient's 88% stop at 0.88 * 120% = 105.6% of the box's real height — past the visible bottom edge — so the entire visible box lands in the gradient's opaque zone and reads fully solid. */ .about__copy.is-at-end { -webkit-mask-size: 100% 120%; mask-size: 100% 120%; } .about__copy::-webkit-scrollbar { display: none; } .about__copy p { margin: 0 0 var(--lh-body); } .about__copy p:last-child { margin-bottom: 0; } /* ---------- Scroll rail ---------- */ /* Replaces the native scrollbar the column hides. Up and down chevrons step the column; the diamond reports and drags the position. */ /* Laid out absolutely rather than with flex: a percentage margin in a column flex resolves against the container's *width*, and this container is 1.54% wide, so the gaps the reference shows would collapse to nothing. */ .about-rail { position: absolute; left: var(--rail-x); /* Moved up 2 points on request ("move up the about rail by 3%", then corrected to "only by 2") — was 13.14%, height untouched so the whole rail just translates upward. */ top: 11.14%; /* Shrunk by the same 10.9 points the copy column's own height lost from its bottom (71.9% -> 61%, top held fixed both times), so the rail keeps tracking the column's shorter bottom edge. Was 79.5%. */ height: 68.6%; width: 1.54%; transform: translateX(-50%); } .about-rail__step { position: absolute; left: 0; width: 100%; padding: 0; border: 0; background: none; -webkit-appearance: none; appearance: none; color: var(--paper); cursor: pointer; transition: opacity var(--ease-ui), transform var(--ease-ui); } .about-rail__step svg { display: block; width: 100%; height: auto; } .about-rail__step:hover { opacity: 0.7; } .about-rail__step--up { top: 0; } .about-rail__step--down { bottom: 0; } .about-rail__step--up:active { transform: translateY(-2px); } .about-rail__step--down:active { transform: translateY(2px); } .about-rail__track { position: absolute; left: 50%; top: 2.84%; bottom: 3.14%; width: 1px; margin-left: -0.5px; background: var(--paper); cursor: pointer; } /* The line is drawn end to end, but the diamond travels a shorter band inside it, so it never collides with either chevron. Its rest position is where the reference puts it. */ .about-rail__travel { position: absolute; left: 0; right: 0; top: 6.7cqh; bottom: 6.7cqh; } /* An outlined diamond, not a filled one — the track hairline runs visibly straight through it. Sized against the stage, because the track it lives in is one pixel wide. It is a fixed-size position marker rather than a proportional thumb, which is how the reference draws it. */ .about-rail__thumb { position: absolute; left: 50%; top: 0; width: 0.66cqw; height: 1.81cqh; color: var(--paper); transform: translateX(-50%); } .about-rail__thumb svg { display: block; width: 100%; height: 100%; } /* ---------- Gallery ---------- */ /* The lightbox takes the gallery's place rather than covering it: the caption panel lands in the same band the tile occupied, and the tile is opaque, so leaving it behind would show through as a seam. */ .is-lightbox .about-gallery { opacity: 0; visibility: hidden; transition: opacity var(--ease-fade), visibility 0s linear var(--ease-fade); } .about-gallery { transition: opacity var(--ease-fade); } /* The previous slide peeks out to the left of the tile, cut along the fourth chevron's own edges (found missing from this rule entirely on 2026-09-01 — an earlier, undocumented edit had deleted it outright, leaving a plain uncut rectangle; restored from `_backup_pre_flexbox/ about.css`, see "The about choreography" in CLAUDE.md). The gallery staying in front of every chevron (see the laptop-tier media block's `.about-layer` z-index comment above) means this clip isn't needed to hide the box *behind* a chevron — but it's still needed for two other reasons: it tapers the rendered edge to match the chevron's diagonal instead of a hard rectangle corner, and it trims the box's own visible pixels clear of `--rail-x` (71%), which the raw box (69.76%–81.42%) would otherwise paint straight through. Both vertices are the master line equations above, rebased onto this box (subtracting its own 69.76% left / 33.99cqh top). */ .about-gallery__peek { position: absolute; left: 69.76%; top: 33.99%; width: 11.66%; height: 28.84%; object-fit: cover; background: var(--blue-deep); clip-path: polygon( calc(var(--arrow-far-n) * 1cqw - 69.76cqw + 41.316cqh) 0, 100% 0, 100% 100%, calc(var(--arrow-far-n) * 1cqw - 69.76cqw + 55.715cqh) 100%, calc(var(--arrow-far-n) * 1cqw - 69.76cqw + 40.166cqh) 1.986cqh ); /* Sits on the tile now, not bare page ground, so it needs its own depth: darkened and dropped a shadow to read as set apart from the panel behind it. */ filter: brightness(0.55) saturate(0.9) drop-shadow(0.3cqw 0.4cqh 0.8cqw rgba(var(--shadow-ink), 0.5)); /* No transition of its own — its `src` swap (about.js's `slide()`) is a plain instant cut in step with the main photo's own promotion. A crossfade, and later a clone flying between this box and the main photo's, were both tried (2026-09-13) and dropped the same day on request; see CLAUDE.md for what was tried and why. This element's clip-path is plotted in `cqw`/`cqh` relative to `.hero` itself (see the master line equations above), not its own box, so it must stay anchored exactly where it is regardless. */ } /* Opaque background panel behind `.about-gallery__open`, cut the same way as `.about-gallery__peek` just above (same missing-clip-path regression, restored from the same backup on 2026-09-01) — the tile's own fill, `--blue-deep`, is identical to the page ground, so the taper here is purely cosmetic edge-matching against the chevron, not a visibility fix, but the peek's clip above still needs the tile's own left edge to read consistently with it. */ .about-gallery__tile { position: absolute; left: var(--tile-left); top: var(--tile-top); width: var(--tile-width); height: var(--tile-height); background: var(--blue-deep); clip-path: polygon( calc(var(--arrow-far-n) * 1cqw - 69.76cqw + 43.875cqh) 0, 100% 0, 100% 100%, calc(var(--arrow-far-n) * 1cqw - 69.76cqw + 58.465cqh) 100%, calc(var(--arrow-far-n) * 1cqw - 69.76cqw + 40.166cqh) 6.406cqh ); } .about-gallery__open { position: absolute; left: var(--photo-left); top: var(--photo-top); width: var(--photo-width); height: var(--photo-height); padding: 0; border: 0; background: none; -webkit-appearance: none; appearance: none; cursor: pointer; overflow: hidden; } .about-gallery__photo { display: block; width: 100%; height: 100%; object-fit: cover; background: var(--blue-deep); transition: transform var(--ease-ui); } .about-gallery__open:hover .about-gallery__photo { transform: scale(1.03); } .about-gallery__open:active .about-gallery__photo { transform: scale(1.01); } /* Gradient overlay plus a colour layer, so a photograph of any temperature still sits inside the blue. Thumbnail only — at full size the photograph is the subject and carries no treatment of its own. */ .about-gallery__open::after { content: ''; position: absolute; inset: 0; pointer-events: none; background: linear-gradient(to top, rgba(0, 30, 46, 0.45), transparent 55%); } .about-gallery__open::before { content: ''; position: absolute; inset: 0; z-index: 1; pointer-events: none; background: var(--blue-deep); mix-blend-mode: multiply; opacity: 0.12; } /* Desktop has no dot indicator (the tile/peek/chevron-notch treatment already shows the "previous" photo directly) — only the mobile/tablet carousel (about.css's own mobile-flow block, further down) turns this on. Hidden by default rather than left unstyled: unstyled, this empty container's JS-appended `