/** * CleanPro public-facing fluid type scale — host-theme-independent by design. * * WHY THIS FILE EXISTS: this plugin ships into arbitrary client WordPress * sites, each with its own theme, and themes set wildly different * font-size values (some 16px default, some 10px via a 62.5% reset for * easy rem math, etc). CleanPro's public CSS used to size text with `rem`, * which always resolves against the HOST page's font-size — so the * exact same `1.15rem` rule rendered at very different real pixel sizes on * different client sites, with no way for this plugin to predict or * control it. Confirmed live 2026-07-28: a 10px host root silently shrank * every rem-based size in this plugin to 62.5% of its intended value. * * FIX: every token below is built from `px` and `vw` only — NEVER `rem` or * `%` — so it is mathematically immune to the host theme's root font-size. * Each token also fluidly interpolates between a minimum (at a 360px * viewport) and a maximum (at 1440px), rather than jumping at fixed * breakpoints, so every width in between (not just named devices) gets a * correctly-scaled size automatically. * * DO NOT convert these back to `rem` — that reintroduces the exact bug * this file exists to fix. DO NOT reference `rem` in any CleanPro * public-facing CSS file (techreme-cleanpro-booking.css, * tcp-theme-modern.css, or any future public template) — use these tokens * instead. See CLAUDE.md STANDING RULES for the full writeup. * * Shared across every CleanPro public template (booking form, confirmation * page, payment-unsuccessful page, result pages) so the type scale stays * visually consistent — but each template's own CSS file still owns all of * its actual layout/component rules independently. Only these numeric * values are common. */ :root { /* Shared vertical rhythm between field-group-level sections (the gap after "How often?", after a subtype option grid, after a counter-card grid, etc). Added 2026-07-28 to replace 6+ slightly-different hardcoded margin-bottom values (16/18/20/24px, plus one genuine outlier bug — .tcp-subtype-grid was 4px) with one consistent value, so any new Service Configuration field type an admin adds through the Form Builder automatically inherits correct spacing without a bespoke fix. This represents the FULL intended visual gap (32px). Elements that are direct children of .tcp-fields-grid already get +12px for free from that grid's own `gap` property, so THEIR margin-bottom must use calc(var(--tcp-space-section) - 12px) instead of the bare token, or they'd end up with 44px instead of 32px. Elements nested one level deeper (inside a .tcp-field-group wrapper, e.g. the calendar or the recurring panel) get no such boost and use the bare token directly. Verified live via DOM parent-chain inspection which classes are direct grid children before wiring this up — don't guess, check getComputedStyle(el.parentElement).display / classList first if this ever needs revisiting. */ --tcp-space-section: 32px; /* Gap between a field/section label (.tcp-label, including the "How often?"/"Property Type"/"Cleaning Package" subtype-group labels, which carry .tcp-label too) and the control/content directly below it. Was a hardcoded 6px — cramped enough to misread as a rendering bug once --tcp-space-section grew to 32px for comparison. Flagged by the developer 2026-07-28. Tokenized for the same reason as --tcp-space-section: any current or future label in this plugin's public CSS should reference this instead of a new hardcoded value. */ --tcp-space-label: 10px; --tcp-fs-2xs: clamp(10px, 9.67px + 0.09vw, 11px); --tcp-fs-xs: clamp(11.5px, 11.17px + 0.09vw, 12.5px); --tcp-fs-sm: clamp(12.5px, 12.17px + 0.09vw, 13.5px); --tcp-fs-base: clamp(14px, 13.67px + 0.09vw, 15px); --tcp-fs-md: clamp(15px, 14.5px + 0.14vw, 16.5px); --tcp-fs-lg: clamp(17.5px, 16.67px + 0.23vw, 20px); --tcp-fs-xl: clamp(20px, 18.67px + 0.37vw, 24px); --tcp-fs-2xl: clamp(26px, 24px + 0.56vw, 32px); --tcp-fs-3xl: clamp(32px, 29.33px + 0.74vw, 40px); }