/* ============================================================================= lounaat.info — design tokens Synthesised from Mikko's Figma sketch, node 16:657 ("sketching") file tsz0TzljbLcOBZOcyz6NlB Every value is read from the Figma layers, then expressed in rem on a 4px grid (root 16px, so 1rem = 16px = 4 grid units). Nothing invented; gaps are listed in UI-GUIDANCE.md rather than guessed. Why rem and not px: the whole page then scales with the reader's browser font-size setting, which px silently ignores. Layout that must not scale with text — hairlines, the 1px card border — stays in px on purpose. ========================================================================== */ @import url("palette-mint.css"); :root { /* --------------------------------------------------------------------- COLOUR — the swappable palette lives in its own file. ⭐ Every ground, ink and chrome value moved to palette-*.css on 2026-09-01 so a whole palette can be tried and reverted with ONE line: the @import at the top of this file. palette-olive.css is the archive — the palette all 19 public pages were approved in; palette-teal.css is the brand-green trial from Figma 55:3745. What stayed here, and why: the Zevoy house block is explicitly its own world and not the site palette, and the badge and star colours are Mikko-given accents that no palette pass has touched. If a palette ever needs to change one of those, move that token into both palette files rather than forking it. --------------------------------------------------------------------- */ /* COLOUR — Zevoy house block (its own world, deliberately not site palette) */ --c-zevoy-ground: #0a162e; --c-zevoy-border: #2a406e; --c-zevoy-eyebrow: #848a97; --c-zevoy-cta: linear-gradient(178.08deg, #ff6110 4.29%, #7b00ff 87.74%); /* COLOUR — status. Hex given by Mikko 2026-08-26, not sampled. */ --c-badge: #d85200; /* preset-location dot 32:1754 */ /* A star is ALWAYS this orange, wherever it appears — the card rating, the detail hero, the review breakdown. Mikko 2026-08-26: "the stars should always be the same color everywhere." It was hardcoded in four places and the breakdown bars had gone black, so it is a token now and there is one place to change it. */ --c-star: #e58f03; /* --------------------------------------------------------------------- SPACE — 4px grid. Token number = grid units, so --space-6 is 6 × 4px. Only values the sketch actually uses are defined. --------------------------------------------------------------------- */ --space-0-5: 0.125rem; /* 2px */ --space-1: 0.25rem; /* 4px */ --space-1-5: 0.375rem; /* 6px — diet chip padding, 4:158 */ --space-2: 0.5rem; /* 8px */ --space-3: 0.75rem; /* 12px */ --space-4: 1rem; /* 16px */ --space-5: 1.25rem; /* 20px — floating filter bar inset, 6:756 */ --space-6: 1.5rem; /* 24px */ --space-8: 2rem; /* 32px */ --space-9: 2.25rem; /* 36px — card vertical padding, 4:127 */ --space-12: 3rem; /* 48px */ --space-16: 4rem; /* 64px */ --space-32: 8rem; /* 128px — footer bottom pad, 9:182 */ /* --------------------------------------------------------------------- TYPE — two families. See UI-GUIDANCE.md §"Font loading" before shipping. --------------------------------------------------------------------- */ --font-display: "Instrument Serif", Georgia, serif; --font-body: "Inter", "DM Sans", system-ui, sans-serif; /* size / line-height pairs, exactly as drawn */ --t-display: 2rem; --t-display-lh: 1.2; /* 32px — Zevoy headline, day heading */ /* The RESTAURANT NAME is 110% wherever it appears — listing card, search result, detail hero (Figma: Instrument Serif 48 / line height 110%). A token because it is the same voice in four places and was drifting: the three listing rules each hardcoded 1.1 while the detail hero sat on `normal` (~1.4 in Instrument Serif), which is the one Mikko caught by eye on 2026-08-28. A name is the only long serif string on the site that wraps, so it is the only place the value is visible at all. */ --t-name-lh: 1.1; /* 64px page title, drawn only at the 1280 artboard (32:1751). The artboard gives one point, so the mobile end is derived the same way --page-pad is: a straight line 32px @390 → 64px @1280, clamped at both ends. 64px would set "Lounas Tampere, Keskusta" four lines deep on a 390 screen. */ --t-page-title: clamp(2rem, 1.124rem + 3.596vw, 4rem); --t-footer-row: 1.125rem; --t-footer-row-lh: 1.3; /* 18px */ --t-body: 1rem; --t-body-lh: 1.3; /* 16px — dish, nav chip, diet chip */ --t-meta: 0.875rem; --t-meta-lh: 1.3; /* 14px — hours, price, filters */ --w-regular: 400; --w-bold: 700; /* price, diet chip letter */ /* --------------------------------------------------------------------- RADIUS — only two. This is the single biggest fix vs. today's six. --------------------------------------------------------------------- */ --r-container: 1rem; /* 16px — card, nav bar, filter bar */ --r-control: 0.75rem; /* 12px — chip, footer row, button */ --r-chip: 0.5rem; /* 8px — inline diet chip */ /* --------------------------------------------------------------------- BORDERS — px on purpose. A hairline should stay a hairline. --------------------------------------------------------------------- */ --border: 1px solid var(--c-surface-border); --rule-dashed: 1px dashed var(--c-rule); /* --------------------------------------------------------------------- ICONS --------------------------------------------------------------------- */ --icon-lg: 1.5rem; /* 24px — favourite heart, star, footer chevron */ --icon-sm: 1rem; /* 16px — nav chip, filter chip, CTA arrow */ /* --------------------------------------------------------------------- LAYOUT — fluid. No fixed breakpoint grid, no fixed page width. Column count is computed by the browser from --card-min, so the layout responds continuously to the viewport instead of jumping at breakpoints. --------------------------------------------------------------------- */ --card-min: 22.5rem; /* 360px — the drawn card width, 4:127 */ --grid-gap: var(--space-4); /* 16px, as drawn */ /* Side and top margin, measured off the artboards and interpolated between them so the container is always (viewport − 2 × margin): 390px frame → 15px side, 16px top (4:2, content 360 at x=15) 1280px frame → 84px side, 32px top (4:125, container 4:417 = 1112 at x=84) A straight line through those two points, floored at the mobile value and capped so an ultrawide display does not end up mostly margin. At 1280 the container resolves to exactly 1112px and fits exactly three 360px columns with two 16px gaps — 3 × 360 + 2 × 16 = 1112. */ --page-pad: clamp(0.9375rem, calc(7.7528vw - 0.95225rem), 8rem); /* Top margin above the nav is FIXED, not fluid — 32px from 4:125. Side margin scales because the container width has to; vertical rhythm has no such reason to, and a breathing gap above the nav reads as sloppy. */ --page-top: 2rem; /* --------------------------------------------------------------------- MOTION — the first motion tokens in the file. Added 2026-08-31 for the nav (search morph + mobile panel), which is the site's only real transition; everything before it was static or a CSS-only hover. ONE duration and ONE curve, deliberately, so the search field and the mobile panel cannot drift apart — they are the same gesture at two widths. Mikko asked for the panel to reverse the same way it opens, so there is no separate exit timing: normally an exit would be shorter than an entrance, and that is the obvious thing to try if 420ms out feels slow. The curve is a decelerate — fast off the mark, long settle. That is the right shape for something GROWING into place (it arrives rather than stops), and the wrong shape for something leaving, which is the trade accepted by sharing one curve. ⚠️ Not verified in a browser. No timing value in here has been seen moving; they are chosen from the artboard's geometry and standard practice, and they are the first thing to adjust on review. --------------------------------------------------------------------- */ /* 420 -> 300 after Mikko watched it on an iPhone: "could play just a little bit faster". Kept the same both ways, as asked. */ --nav-dur: 300ms; --nav-ease: cubic-bezier(0.22, 1, 0.36, 1); /* The panel's own content lags the surface slightly so the olive arrives first and the controls land into it, rather than everything moving as one slab. Held to a third of the duration — beyond that it reads as lag. */ --nav-stagger: 90ms; /* How far the mobile nav's olive surface is drawn BEYOND the visual viewport. Not decoration — it is what covers the strips iOS never gives a page: the status-bar safe area above, and the region behind Safari's floating bottom toolbar. Both showed as cream bands on the first iteration. ⚠️ 200px -> 50vh on 2026-08-31, and the reason is worth keeping. Mikko's second round showed bands appearing TRANSIENTLY, in frames where Safari is animating its own toolbar and the visual viewport is mid-flight — its floating URL pill is rendered halfway down the panel in two of the four screenshots. During those frames no computed value is correct, because the numbers CSS is positioned against are themselves changing. A generous overscan is the cheap defence: the surface is clipped to the bar's rect when closed and to nothing when open, so over-painting costs literally nothing, and 50vh swallows a displacement far larger than any observed. This is padding against an unmeasurable transient, not a fix — the fix is `interactive-widget=resizes-content`, which stops the pan happening at all. */ --nav-overscan: 50vh; }