/* * Design tokens. * * The single source of visual truth, deliberately a plain custom-property file and * NOT Lumo overrides inside a Vaadin theme. Three things load it: * * - the Vaadin app (@StyleSheet on ComeAlongApplication) * - the Thymeleaf marketing pages (templates/marketing/layout.html) * - a future static marketing site, if one ever takes the namespace over * * That is the whole point. Two visual systems drifting apart is the real failure * mode of splitting the marketing site off later - not routing. Keep this file free * of component styles and free of anything Vaadin-specific; it is values only. * * Lumo's own variables are mapped from these at the bottom, so themed Vaadin * components pick the palette up without any component needing to know about it. */ :root { /* ---- The palette ------------------------------------------------------- * docs/UX_DESIGN.md's six values, and no seventh. The analogue is a notice * board - an opslagstavle in a hallway or a forsamlingshus - so the page is the * board and cards are the notes pinned to it. Cards being LIGHTER than the page * is what creates that read, and it is the reason --ta-color-bg is not white. * * The discipline that makes this palette work is that --ta-marigold appears at * most once per screen region, so "the orange thing" is always the action. It is * easy to lose by adding a second affirmative somewhere; there is no token here * that would let you. */ --ta-ink: #1B2A24; /* Text. A warm spruce-black, never neutral #000 */ --ta-board: #E4E0D3; /* The surface cards sit on */ --ta-note: #FFFFFF; /* Card background */ --ta-spruce: #2F5D50; /* Structure: nav, headings, links */ --ta-marigold: #E8A33D; /* The affirmative. Sign-up, confirmed. Sparingly */ --ta-rust: #B4472E; /* Afbud, aflyst, errors. Status only, never an accent */ /* ---- Roles ------------------------------------------------------------- * Every consumer uses these, never the six above, so a component never has to * know that "the affirmative" happens to be orange. * * Contrast ratios below are computed, not estimated. The two worth remembering: * ink on marigold is 7.0:1 while WHITE on marigold is 2.2:1 and fails - so an * affirmative button is dark text on orange, never the reverse. And rust on the * board is 4.2:1, which is under the 4.5 needed for body text, so rust belongs * on a note surface or at large sizes. */ --ta-color-bg: var(--ta-board); /* ink on this: 11.7:1 */ --ta-color-surface: var(--ta-note); /* ink on this: 15.1:1 */ /* Derived from the board rather than grey. 3.7:1 against a note, which clears * the 3:1 that WCAG 1.4.11 asks of a form field's edge; 2.9:1 against the board, * so field borders belong on cards. */ --ta-color-border: #8A8474; --ta-color-text: var(--ta-ink); --ta-color-text-secondary: #4A5A52; /* 5.7:1 on board, 7.3:1 on a note */ --ta-color-primary: var(--ta-spruce); /* 7.5:1 on a note, 5.8:1 on the board */ --ta-color-primary-text: var(--ta-note); --ta-color-primary-hover: #264A40; /* The affirmative, kept apart from --ta-color-primary on purpose: structure and * agreement are different jobs, and merging them is how marigold stops meaning * yes. */ --ta-color-affirm: var(--ta-marigold); --ta-color-affirm-text: var(--ta-ink); /* see the contrast note above */ --ta-color-error: var(--ta-rust); --ta-color-error-text: var(--ta-note); /* 5.4:1 */ /* The seat strip is phase 3's, and it gets no new hues: a full event is a * status, which is what rust is for, and waiting is neither a yes nor an error, * so it reads as muted ink rather than a third signal colour. */ --ta-color-full: var(--ta-rust); --ta-color-waiting: var(--ta-color-text-secondary); /* ---- Typography ------------------------------------------------------- * Three faces, self-hosted - declared in fonts.css, which explains why. Nothing * is loaded from another origin on any page, which is what keeps this app free * of a consent banner (docs/GDPR.md ยง5). * * The split is the part worth getting right, and it is not "headings vs body". * UX_DESIGN.md gives the serif a specific job: MEMBER-WRITTEN text - event * descriptions, posts, profile text - so that writing reads as writing, from a * person. The app's own chrome is the grotesk. So a heading the app wrote and a * paragraph a member wrote are different faces even at the same size, and that * distinction carries meaning: serif on screen here means "a human typed this". * * The mono is earned, not decorative: #n post references are this app's * signature mechanic, and monospace is what makes a reference read as a * reference rather than as prose. Dates and counts for the same reason. * * Every stack keeps a fallback. The faces are swap-loaded, so the fallback is * what a visitor reads for the first few hundred milliseconds. */ --ta-font-family: "Familjen Grotesk", system-ui, -apple-system, "Segoe UI", Roboto, "Helvetica Neue", Arial, sans-serif; --ta-font-family-prose: "Source Serif 4", Georgia, "Times New Roman", serif; --ta-font-family-mono: "IBM Plex Mono", ui-monospace, SFMono-Regular, Menlo, Consolas, monospace; --ta-font-size-s: 0.875rem; --ta-font-size-m: 1rem; --ta-font-size-l: 1.25rem; --ta-font-size-xl: 1.75rem; --ta-font-size-xxl: 2.5rem; --ta-line-height-tight: 1.25; --ta-line-height-body: 1.6; /* ---- Space ------------------------------------------------------------- */ --ta-space-xs: 0.25rem; --ta-space-s: 0.5rem; --ta-space-m: 1rem; --ta-space-l: 2rem; --ta-space-xl: 4rem; /* ---- Shape ------------------------------------------------------------- */ --ta-radius-s: 4px; --ta-radius-m: 8px; --ta-radius-l: 16px; /* ---- Layout ------------------------------------------------------------ */ --ta-content-max-width: 40rem; /* ---- Lumo mapping ------------------------------------------------------ * Vaadin components read Lumo variables. Mapping them here means a component * never refers to a --ta- token directly, and the marketing pages never have to * know Lumo exists. * * THE CONTRAST SCALE IS NOT A PLACE TO PUT NAMED COLOURS. Lumo's * --lumo-contrast-Npct are translucent tints of the text colour, and components * use them for surfaces: a text field takes its BACKGROUND from * --lumo-contrast-10pct. Wiring the border colour into it - which this file did * until 2026-08-17 - turned every input into a dark box with dark text on it, * unreadable and nowhere near the 4.5:1 the same file computes ratios for * elsewhere. They stay as alpha tints of ink so they compose over whatever * surface they land on, which is the property that makes the scale work at all. */ --lumo-font-family: var(--ta-font-family); /* The base is the surface components sit ON. Cards, not the board - a field * rendered straight onto the board is the other half of that same bug. */ --lumo-base-color: var(--ta-color-surface); --lumo-body-text-color: var(--ta-color-text); --lumo-secondary-text-color: var(--ta-color-text-secondary); --lumo-primary-color: var(--ta-color-primary); --lumo-primary-text-color: var(--ta-color-primary); --lumo-primary-contrast-color: var(--ta-color-primary-text); --lumo-contrast-5pct: rgba(27, 42, 36, 0.04); --lumo-contrast-10pct: rgba(27, 42, 36, 0.07); --lumo-contrast-20pct: rgba(27, 42, 36, 0.14); --lumo-contrast-30pct: rgba(27, 42, 36, 0.22); --lumo-contrast-50pct: rgba(27, 42, 36, 0.44); --lumo-contrast-60pct: rgba(27, 42, 36, 0.56); --lumo-contrast-70pct: rgba(27, 42, 36, 0.68); --lumo-contrast-90pct: rgba(27, 42, 36, 0.90); /* Lumo's "success" is what a confirmation toast uses, and a confirmation is the * affirmative - so marigold, with ink on top. Wiring white here would look right * in Lumo's own examples and fail contrast on this palette. */ --lumo-success-color: var(--ta-color-affirm); --lumo-success-text-color: var(--ta-color-text); --lumo-success-contrast-color: var(--ta-color-affirm-text); --lumo-error-color: var(--ta-color-error); --lumo-error-text-color: var(--ta-color-error); --lumo-error-contrast-color: var(--ta-color-error-text); --lumo-border-radius-s: var(--ta-radius-s); --lumo-border-radius-m: var(--ta-radius-m); --lumo-border-radius-l: var(--ta-radius-l); }