> +
, so this needs no HTML change: two children, two columns. */
.band .opener {
display: grid;
grid-template-columns: minmax(0, 12rem) minmax(0, 1fr);
gap: clamp(14px, 2.4vw, 56px);
align-items: start;
}
.band .opener > .opener-num {
display: flex;
flex-direction: column;
align-items: flex-start; /* the flex default would centre the column */
gap: .5em;
padding-top: .5em; /* optical: aligns the label to the heading cap */
margin: 0;
text-align: left;
white-space: normal;
}
/* styles.css trails a hairline after the number to tie it to the heading
sitting beside it. Stacked in a left rail there is nothing to tie it to,
and it renders as a stray underline under the label. */
.band .opener > .opener-num::after { content: none; }
.opener-step {
font-family: var(--mono);
font-size: var(--t-xs);
letter-spacing: .14em;
color: var(--accent);
}
.opener-label {
font-family: var(--mono);
font-size: var(--t-xs);
letter-spacing: .14em;
text-transform: uppercase;
color: var(--text-2);
}
.opener-lede {
max-width: var(--measure);
line-height: 1.62;
color: var(--text-2);
}
@media (max-width: 820px) {
.band .opener { grid-template-columns: 1fr; gap: 12px; }
.band .opener > .opener-num {
flex-direction: row;
gap: .9em;
padding-top: 0;
}
}
/* The alternating fill is what makes the stack obvious. Replace most of it
with a single hairline: the section change is still legible, and the page
reads as one continuous document rather than eleven boxes. */
/* The alternating fill stays. Stripping it to bare hairlines made the page
one long undifferentiated sheet — the bands are what give it a pulse as
you scroll, and the complaint was never that the page had too much
colour. A hairline is added ON TOP of the fill so the boundary is crisp
where two filled sections would otherwise blur together. */
.band-alt {
border-top: 1px solid var(--line-soft);
}
/* ───────────────────────────────────────────────────────────────────────────
6. THE ACCENT, SPENT ONCE
It appeared on every rule, label, icon and border, which means it said
nothing. Reserved now for the primary action and live state.
─────────────────────────────────────────────────────────────────────── */
.accent-line,
.rule,
hr,
.divider { background: var(--line) !important; }
/* Buttons keep their pill shape and their lift. The only thing taken away
is the gradient fill — a flat ink block reads as more confident than a
subtly graded one, and the gradient was pure decoration. */
.btn,
.btn-primary,
.btn-ghost,
.btn-solid {
background-image: none;
letter-spacing: -.005em;
}
/* ───────────────────────────────────────────────────────────────────────────
7. NAV
The bar was showing a left-to-right gradient — warm cream at the logo,
cold blue-green by the buttons. That is the hero's glow refracting
through a translucent bar that also ran saturate(190%), which pushes
whatever is behind it toward neon. Against the warm ground it read as a
rendering fault rather than as glass.
Fixed by making the bar its own surface: a near-opaque warm fill, blur
without saturation, so what passes underneath softens instead of
tinting the bar.
─────────────────────────────────────────────────────────────────────── */
.nav,
.nav-inner,
header.site-head {
border-bottom: 1px solid var(--line-soft);
backdrop-filter: blur(20px);
-webkit-backdrop-filter: blur(20px);
}
.nav {
/* color-mix keeps this in step with the ground token rather than
hard-coding a second near-white that drifts when --bg changes. */
background: color-mix(in srgb, var(--bg) 88%, transparent);
}
.nav.scrolled {
background: color-mix(in srgb, var(--bg) 96%, transparent);
backdrop-filter: blur(24px);
-webkit-backdrop-filter: blur(24px);
/* The inset white line read as a seam on a warm bar. A single hairline
and a soft drop is enough to say "this floats". */
box-shadow: 0 6px 24px -18px rgba(22,19,14,.4);
border-bottom-color: var(--line);
}
:root[data-theme="dark"] .nav.scrolled {
box-shadow: 0 8px 28px -18px rgba(0,0,0,.75);
}
.nav-links a {
font-size: var(--t-sm);
}
/* The underline sat at -5px, close enough to the bar's own bottom border
that the two read as one thick smudge on hover. -9px separates them. */
.nav-links a::after {
bottom: -9px;
height: 1px;
}
/* ───────────────────────────────────────────────────────────────────────────
8. SCREENSHOT FRAMES
One shadow survives on the page, and this is it: the dashboard shot is the
only element that should read as lifted off the ground, because it is the
product and everything else is description.
─────────────────────────────────────────────────────────────────────── */
.shot,
.showcase .ui-panel,
.shot-stack .ui-panel {
border-radius: var(--r-md);
border: 1px solid var(--line);
box-shadow: var(--shadow-lg);
}
/* Respect the OS setting; none of the above depends on motion. */
@media (prefers-reduced-motion: reduce) {
* { animation-duration: .001ms !important; transition-duration: .001ms !important; }
}
/* ───────────────────────────────────────────────────────────────────────────
9. THE PHONE TRIO, LEVELLED
The three crew-app shots each carried a different transform —
rotateY(5deg) rotateZ(-1.2deg) on the first, a bare translateY(-14px) on
the second, the mirrored rotation on the third. Measured, that put the
screens at three different heights and three different angles while
their captions sat on one line, so the group read as misaligned rather
than as a deliberate fan.
They are the same product on three screens, so they line up like three
screens: one baseline, no rotation. The middle one keeps a small lift,
which is enough to stop the row being flat without breaking the line.
─────────────────────────────────────────────────────────────────────── */
.phone-1 .phone-shot,
.phone-3 .phone-shot {
transform: none;
}
.phone-2 .phone-shot {
transform: translateY(-18px);
}
/* With the rotation gone the shots can share one width and one radius, so
the row reads as a set. */
.phone-shot {
max-width: 258px;
border-radius: 22px;
}
/* ───────────────────────────────────────────────────────────────────────────
10. THE POINTER EFFECTS AT THE TOP OF THE PAGE, REMOVED
Three separate things fired as the cursor crossed the top of the page,
and together they read as the page twitching rather than responding:
1. .hero-spot — a 620px radial glow tracking the pointer across the
whole hero, driven by --mx/--my written on every pointermove. A
light that chases the mouse is the loudest "effect for its own
sake" on the page; nothing about the product is being communicated
by it, and it draws the eye away from the headline it sits behind.
2. .btn-solid / .btn-ghost lift translateY(-1.5px) on hover, so both
nav buttons jump as the cursor passes over them. Measured: top
11.1 -> 9.6.
3. .theme-toggle SCALES to 1.06 — 38px to 40.3px. A control that
changes size under the cursor is the most jarring of the three,
because its neighbours appear to shift to make room.
Crossing the nav therefore set off three movements in sequence. All
three are replaced with colour and border changes, which answer the
pointer without moving anything. Hover should confirm "this is
clickable", not animate.
─────────────────────────────────────────────────────────────────────── */
.hero-spot,
.pointer-fine .hero-spot {
display: none !important;
}
.btn:hover,
.btn-solid:hover,
.btn-ghost:hover,
.btn-quiet:hover,
.theme-toggle:hover {
transform: none !important;
}
/* The nav buttons answer with tone instead of travel. */
.btn-solid:hover {
background-color: color-mix(in srgb, var(--btn-fill) 86%, var(--bg));
box-shadow: none;
}
.btn-ghost:hover,
.theme-toggle:hover {
border-color: var(--line-firm);
color: var(--heading);
background-color: color-mix(in srgb, var(--bg-3) 60%, transparent);
}
/* The sheen that sweeps across the solid button on hover travels too, so it
goes with the rest. */
.btn-solid:hover::after { display: none; }
/* ───────────────────────────────────────────────────────────────────────────
11. THE PHONE RAIL ON MOBILE
At 393px the three crew-app shots were cut off at both edges: measured,
app-job-detail lost 393px of its 253px-wide box (72% of it off-screen)
and app-checklist lost 126px.
The cause is a handover between two layouts. On mobile .phones stops
being a 3-column grid and becomes a scroll-snap rail, and the rail gives
each child flex: 0 0 82% — about 322px at this width. But the centring
came from the GRID's justify-items, which no longer applies once the
parent is a flex rail, so each 258px image sat hard against the left of
its 322px slot and the group drifted progressively out of frame.
Centring inside the slot puts every phone fully in view, and the rail
still shows a slice of the next one, which is what tells a thumb to
swipe.
─────────────────────────────────────────────────────────────────────── */
@media (max-width: 760px) { /* the breakpoint where styles.css turns
.phones into the scroll rail — matching
it exactly is what makes these win */
/* The rail is full-bleed: margin-inline pulls it out past the page gutter
so a half-visible next card is the swipe affordance. For the dashboard
cards that works, because they are wide and short. For the PHONES it
does not — a phone shot is 2.2x taller than it is wide, so at 393px a
full-width card runs well past the fold, and with the bleed there is no
left gutter either: the first phone sits hard against the screen edge
and reads as cut off rather than as the start of a row.
So the phones keep the swipe but get their page gutter back, and each
card is sized to fit the screen it is on rather than to fill it. */
.showcase-phones .phones {
margin-inline: 0;
padding-inline: var(--gutter, 16px);
gap: 14px;
}
.showcase-phones .phones > .phone {
display: flex;
flex-direction: column;
align-items: center;
justify-content: flex-start;
/* 62% of the viewport, so a whole phone and a clear slice of the next
are both in frame at 393px. */
flex: 0 0 62%;
}
/* Cap the height to the viewport so a card is never taller than the
screen that has to show it. The shot keeps its own ratio. */
.showcase-phones .phones .phone-shot {
width: 100%;
max-width: 100%;
max-height: 64vh;
height: auto;
object-fit: contain;
margin-inline: auto;
}
/* The lift on the middle phone is a desktop grace note. In a swipe rail
each card is looked at on its own, so an offset one just looks wrong. */
.phone-2 .phone-shot { transform: none; }
}
/* ───────────────────────────────────────────────────────────────────────────
12. THE "ONE SHIFT" PAIR
Two faults in one figure, both of them things a reader notices before
they read anything:
The phone carried rotateZ(-2deg) while the dashboard beside it sat
straight. Two screens of the same moment, one tilted and one not, do
not read as a composition — they read as one image having slipped.
The dashboard used the rail's zoomed crop at ~1090px wide, where the
missing Actions column and user menu are plainly cut rather than
cropped. It now uses the uncropped variant, like the explorer.
─────────────────────────────────────────────────────────────────────── */
/* MUST stay scoped to the overlay layout. Written unscoped at first, and
that is what put a phone screenshot on top of the shift timeline: below
560px the phone is position: static and stacks normally, but an
unconditional translateY(-50%) still lifted it half its own height —
measured -225px at 393px wide — straight out of the flow and over "The
cleaner arrives and taps in." A transform that only makes sense for an
absolutely positioned element has to carry the same media query the
positioning does. */
@media (min-width: 561px) {
.loop-phone {
transform: translateY(-50%);
}
}
/* ───────────────────────────────────────────────────────────────────────────
13. ONE RULE COLOUR PER ROW
styles.css tinted the FIRST rule of the pillars row and of the loop
timeline with --accent-mark, to mark where a sequence starts. The
reasoning was sound and the result was not: in a row of three otherwise
identical columns, one rule in a different colour reads as a rendering
fault, not as a marker. The owner saw it and asked why there was only
one teal line, which is the whole answer — a marker nobody reads as
deliberate is just an inconsistency.
The pillars are three AUDIENCES (owner, supervisor, cleaner), not a
ranked sequence, so there is nothing to mark in the first place. The
loop steps are genuinely sequential, but they are already numbered with
times — 09:00, 09:14, SAME MORNING — which says "sequence" far better
than a tinted hairline.
─────────────────────────────────────────────────────────────────────── */
.pillar:first-child,
.loop-step:first-child {
border-top-color: var(--line);
}
/* ───────────────────────────────────────────────────────────────────────────
14. HORIZONTAL RAILS MUST NOT EAT A VERTICAL SWIPE
Measured on a real touch context at 393x852: dragging UP with the thumb
starting on a rail moved the page
.loop-chain 0px — completely stuck
.pillars 8px — effectively stuck
.phones 434px — fine
.tabs 279px — fine
So two of the four swipe rails swallowed the page scroll outright. A
reader scrolling the page hits "One shift, end to end", swipes up, and
nothing happens — which is the whole "scrolling isn't smooth" complaint.
Cause: the rails set overflow-x:auto with overflow-y:hidden and no
touch-action. With both axes claimed by the element, the browser has no
rule for which direction belongs to the page, and a near-vertical drag
that starts inside the box is resolved as a (clamped) horizontal one.
touch-action: pan-x says explicitly: this element handles LEFT/RIGHT, the
page keeps UP/DOWN. overscroll-behavior-x: contain stops a horizontal
fling from chaining into browser back-navigation once a rail hits its end.
─────────────────────────────────────────────────────────────────────── */
@media (max-width: 760px) {
.rail-track,
.loop-chain,
.showcase-phones .phones,
.pillars,
.tabs {
/* NOT touch-action: pan-x. Measured with real touch events: pan-x on
the container means the element claims horizontal and NOTHING
handles vertical inside its box, so a vertical swipe that starts on
the rail dies at 0px. Both #capabilities and #app were fully stuck
that way. Leaving touch-action at its default lets the browser do
what it already does well — decide from the angle of the first few
pixels of movement whether the gesture is the rail's or the page's.
overscroll-behavior-x: contain is the part worth keeping: it stops a
horizontal fling, once the rail hits its end, from chaining into the
browser's back-navigation. */
overscroll-behavior-x: contain;
}
/* touch-action goes on the SCROLL CONTAINER ONLY.
Putting pan-x on the cards too (tried, measured) is worse than the
original bug: pan-x on a card means that card handles left/right and
nothing handles up/down, so a vertical swipe landing on a card died
completely — 0px, where before the fix it managed 9px. The container
alone is what needs the hint; its children inherit the behaviour by
being inside it, not by being told separately. */
}
/* ───────────────────────────────────────────────────────────────────────────
15. NO PINNED SECTION ON A PHONE
Measured by dispatching real touch events down the live page: the page
scrolled 285px per swipe at 17 of 19 positions, and 9px and 47px at the
two that land inside the capability rail. That section was the only
place scrolling broke, and it broke badly — the thumb moves and the view
does not.
The cause is the mobile rail's own scroll-driven treatment: .rail-band
is 180vh with .rail-pin sticky at height:100vh inside it, so 682px of
thumb travel (0.8 of a screen) is spent sliding cards sideways while the
page appears frozen. On a desktop, with a mouse wheel and a wide
viewport, that reads as a considered transition. On a phone it reads as
the page having stopped responding, and it is the single biggest
obstacle to following the page top to bottom.
So the phone gets the plain version instead: a normal-height section and
an ordinary swipe rail. The cards are still all reachable, the page
never stops moving under the thumb, and the horizontal motion is now
something the reader chooses rather than something done to them.
Desktop keeps the pinned treatment: the min-width:1024px block above is
untouched.
─────────────────────────────────────────────────────────────────────── */
@media (max-width: 1023px) {
.rail-band {
height: auto !important;
view-timeline-name: none !important;
}
.rail-pin {
position: static !important;
height: auto !important;
overflow: visible !important;
display: block !important;
}
.rail-track-wrap { overflow: visible; }
.rail-track {
/* Back to a finger-driven rail: no transform, no animation timeline. */
animation: none !important;
transform: none !important;
display: flex;
flex-wrap: nowrap;
width: auto;
max-width: 100%;
overflow-x: auto;
overflow-y: hidden;
scroll-snap-type: x mandatory;
overscroll-behavior-x: contain;
gap: 14px;
margin-inline: calc(var(--gutter, 16px) * -1);
padding-inline: var(--gutter, 16px);
padding-block-end: 8px;
scrollbar-width: none;
}
.rail-track::-webkit-scrollbar { display: none; }
.rail-track > * {
scroll-snap-align: start;
flex: 0 0 82%;
min-width: 0;
}
}
/* ───────────────────────────────────────────────────────────────────────────
16. TAP TARGETS ON TOUCH
Thirteen controls measured under 44px tall at 393px wide — the
pillar links at 23px, "Sign in" at 24px, the brand at 30px, the
explorer tabs at 37px, the theme toggle at 38px. Apple's and Google's
guidance is 44px, and below about 40px a thumb starts missing.
Fixed with padding and min-height rather than by growing the type, so
the layout and the visual weight are unchanged — only the area that
responds to a thumb gets bigger. Negative margin keeps the extra
padding from pushing neighbours apart.
─────────────────────────────────────────────────────────────────────── */
@media (hover: none) and (pointer: coarse) {
.pillar-link,
.row-link,
.ui-link {
min-height: 44px;
display: inline-flex;
align-items: center;
/* The link sits at the end of a card, so the extra height goes
downward into space that was padding anyway. */
margin-block: -10px 0;
}
.nav-cta a,
.nav-links a {
min-height: 44px;
display: inline-flex;
align-items: center;
}
.brand {
min-height: 44px;
display: inline-flex;
align-items: center;
}
.theme-toggle {
width: 44px;
height: 44px;
}
.tab {
min-height: 44px;
padding-block: 10px;
}
/* Footer links are the last thing a thumb reaches and were the smallest
on the page at 24px. They stack, so extra height costs nothing. */
.footer-links a,
footer a {
min-height: 44px;
display: inline-flex;
align-items: center;
}
/* Stops the double-tap-to-zoom delay on anything tappable, which reads
as the page being slow to respond. */
a, button, [role="button"], .tab, summary {
touch-action: manipulation;
}
}
/* ───────────────────────────────────────────────────────────────────────────
17. READING PROGRESS
The page is 18.5 screens on a phone, and measurement showed that is
content, not padding — section padding is only 11% of the height. So
rather than cut the owner's copy, give the reader the one thing a long
page is missing: a sense of where they are and how much is left.
A 2px bar along the bottom edge of the fixed nav, driven by
scroll(root). No JavaScript, no scroll listener, no layout read per
frame — it runs on the compositor.
scroll(root) and not scroll(): body has overflow-x: hidden, which makes
BODY a scroll container, so a bare scroll() binds to body, which barely
scrolls, and the bar would never advance. This is the same trap the hero
drift hit; see the note at .hero-glow.
─────────────────────────────────────────────────────────────────────── */
.nav::after {
content: "";
position: absolute;
left: 0;
bottom: -1px; /* sits on the nav's own border, not above it */
height: 2px;
width: 100%;
transform-origin: 0 50%;
transform: scaleX(0);
background: var(--accent);
opacity: .85;
pointer-events: none;
}
@supports (animation-timeline: scroll(root)) {
@media (prefers-reduced-motion: no-preference) {
.nav::after {
animation: nav-progress linear both;
animation-timeline: scroll(root);
}
}
}
@keyframes nav-progress {
from { transform: scaleX(0); }
to { transform: scaleX(1); }
}
/* Without scroll-timeline support, or with reduced motion on, the bar
simply never appears rather than sitting at a misleading 0%. */
@supports not (animation-timeline: scroll(root)) {
.nav::after { display: none; }
}
@media (prefers-reduced-motion: reduce) {
.nav::after { display: none; }
}