/** * Fixit design system — spacing scale, breakpoint alignment and the measured * consistency fixes from the 2026-08-22 full-site audit (54 URLs x 3 viewports). * * WHY a separate file instead of appending to fixit.css: fixit.css is served from * Cloudflare with max-age=31536000, so a rule appended there can sit behind a stale * edge copy. A new path is a new cache entry and takes effect on the first request. * * WHY tokens: fixit.css carries 73 distinct padding/margin values across 55 distinct * breakpoints. Every new component invented its own. These custom properties give the * next component a value to reach for instead of a fresh one to invent. * * Each rule below cites the measurement that justifies it. Nothing here is speculative. * * ⛔EVERY var() BELOW CARRIES A LITERAL FALLBACK, AND MUST KEEP IT. This is not * defensive style, it is a measured requirement. LiteSpeed serves production through * UCSS (tree-shaken CSS): after the first deploy of this file, www.fixit.gr rendered * every one of these fixes as if it had never shipped. The selectors had survived the * shake — `minmax(0,1fr)` and `header-search-btn` were both present in the UCSS bundle * — but the `:root` block had not: the generated file contained ZERO `--fx-*` * declarations, because nothing in the shaken output "uses" a custom property the way * the shaker recognises. Every `var(--fx-…)` therefore resolved to nothing, each * declaration was invalid, and each rule was silently dropped at parse time. * * The failure mode is the dangerous kind: the file is deployed and 200s, the rule is * visibly in the bundle, and a purge changes the `?ver=` hash so it looks refreshed. * Only measuring the live computed style shows the fix is inert. With the fallback the * rules hold whether or not the token block survives. */ :root { /* Spacing scale — 4px base. The audit's real usage clusters on these. */ --fx-space-1: 4px; --fx-space-2: 8px; --fx-space-3: 12px; --fx-space-4: 16px; --fx-space-5: 24px; --fx-space-6: 32px; --fx-space-7: 40px; --fx-space-8: 48px; --fx-space-9: 64px; --fx-space-10: 80px; --fx-space-11: 100px; /* Section rhythm — fluid, so one value covers mobile through desktop and no component needs its own breakpoint to shrink its padding. */ --fx-section-y: clamp(40px, 7vw, 100px); --fx-section-y-lg: clamp(56px, 9vw, 140px); --fx-hero-y: clamp(100px, 14vw, 200px); /* Horizontal gutter — audit found the only measured container at 1206px wide with the page bleeding past the viewport on 3 pages at 1440px. */ --fx-gutter: clamp(16px, 3vw, 40px); --fx-container: 1206px; --fx-container-wide: 1800px; /* Control geometry — audit found 7 distinct button heights (45,46,47,49,50,51,58) and 7 distinct radii (0, 3.6px, 4.2px, 4.8px, 10px, 999px, 50%). */ --fx-control-h: 48px; --fx-tap-min: 44px; --fx-radius: 10px; --fx-radius-pill: 999px; /* Type scale — audit found 7 distinct desktop H1 sizes (92,74,72,64,60,42,40) and 6 on mobile, with one page not scaling down at all. */ --fx-h1: clamp(30px, 5vw, 64px); --fx-h2: clamp(24px, 3.4vw, 42px); --fx-h3: clamp(20px, 2.4vw, 30px); } /* --------------------------------------------------------------------------- * 1. Horizontal overflow at 1440px — home (/, /home) and /it-agency * Measured: scrollWidth 1473 against a 1440 viewport, +33px. * Cause: `grid-template-columns: 1fr 876px` on .section-services. A `1fr` track * has min-width:auto, so the left column's min-content (its .clever-solutions * child carries padding-left:220px) pushes the track past the 564px left over * from 876px, and the row overflows. There is a 1230px media query and an 1800px * max-width, so the gap between them — every laptop at 1280-1799 — is unhandled. * ------------------------------------------------------------------------- */ body.page-id-152 .wp-block-group.section-services > .wp-block-group__inner-container { grid-template-columns: minmax(0, 1fr) minmax(0, 876px); padding-inline: var(--fx-gutter, clamp(16px, 3vw, 40px)); } /* --------------------------------------------------------------------------- * 2. H1 that never scales down * Measured: /oroi-kai-proypotheseis renders its H1 at 64px on a 375px viewport — * identical to desktop. It is a bare

with no class and no inline font-size, * so no rule in fixit.css matches it; the 768px media queries all target * component-scoped selectors. 64px on 375px is ~17 characters per line. * Scoped to bare headings so every styled or inline-sized H1 is left alone. * ------------------------------------------------------------------------- */ .l-section h1:not([class]):not([style*="font-size"]) { font-size: var(--fx-h1, clamp(30px, 5vw, 64px)); line-height: 1.15; } /* --------------------------------------------------------------------------- * 3. Talos landing pages do not scale their section spacing at all * Measured: /talos-magento, /talos-woocommerce, /talos-wordpress, /talos-mythos, * /talos-shopify all render the first section at padding-top:110px / * padding-bottom:80px on BOTH 1440px and 375px — the mobile value is the desktop * value. Meanwhile their two siblings, /talos-ai-chatbot and /talos-eu-ai, use * 200px/160px. Same page family, two spacing systems, neither responsive. * * ROOT CAUSE, and why this one needs !important: the spacing is in no stylesheet. * It is hardcoded in each page's own post_content as an inline