/** * Mechanc — light theme correction layer. * * design-system.css already carries the light palette from the complete mockup * (237 `body.light` rules). This file exists for the places where that palette * could not reach on its own, all of which come from the same root cause: * Elementor stores colours as literal hex, outside the token system, so they * cannot see `body.light` at all. * * Hand-written. Unlike design-system.css and elementor-bridge.css this file is * not generated, so it is safe to edit directly. Loaded after both of them. */ /* ── 1. Elementor Global Colours ─────────────────────────────────────────── The Global Kit bakes its swatches into .elementor-kit-8 as literal dark hex, and rules across the generated widget CSS resolve against them. Re-pointing them at the design tokens fixes every kit-coloured widget at once, and keeps doing so, because body.light already swaps the tokens underneath. body.light (0,1,1) outranks .elementor-kit-8 (0,1,0), so the load order between the kit CSS and this file does not matter. --e-global-color-mclight is deliberately left alone: it is the "Light BG" swatch, picked where a section wants a light panel in either theme. */ body.light { --e-global-color-primary: var(--cyan); --e-global-color-secondary: var(--blue); --e-global-color-text: var(--t1); --e-global-color-accent: var(--green); --e-global-color-mcvoid: var(--void); --e-global-color-mcdeep: var(--deep); --e-global-color-mccard: var(--card); --e-global-color-mccardh: var(--card2); --e-global-color-mctext2: var(--t2); --e-global-color-mctext3: var(--t3); } /* ── 2. The kit paints directly ───────────────────────────────────── It does not only define colours, it also applies them: the page background and base text colour are set straight onto as literal hex, which beats body{background:var(--void)} in design-system.css (0,1,0 against 0,0,1). In dark mode the two agree so it never surfaced; in light mode it was what kept every section on the dark void with white cards floating on top of it. */ body.light { background-color: var(--void); color: var(--t1); } /* ── 3. The alias tokens ─────────────────────────────────────────────────── The design system carries two names for every colour: the mockup shorthand (--card, --t1, --br) and a long form (--bg-card, --text-primary, --border) defined in :root as aliases of it, e.g. --bg-card:var(--card). Aliasing survives a theme swap only if both names live on the same element, and they do not. The aliases are declared on :root, which is , while body.light redefines the shorthand one level down on . A custom property resolves its own var() references where it is declared, so --bg-card resolved against the dark --card on and inherited down already fixed to the dark value. That is why light mode looked half-applied: rules written against the shorthand flipped, rules written against the aliases did not. Re-declaring the aliases here puts them on , beside the shorthand they point at. Only colour aliases are restated — the geometry and type aliases (--radius, --transition, --font-head, --nav-h) are the same in both themes. */ body.light { --accent-cyan: var(--cyan); --accent-blue: var(--blue); --accent-pulse: var(--pulse); --border: var(--br); --border-accent: var(--bra); --text-primary: var(--t1); --text-secondary: var(--t2); --text-muted: var(--t3); --bg-void: var(--void); --bg-deep: var(--deep); --bg-card: var(--card); --bg-card-hover: var(--card2); --bg-glass: var(--glass); --shadow-glow: 0 0 60px var(--glow); } /* ── 4. Topbar contact icons ─────────────────────────────────────────────── The phone and envelope sit inside Elementor Button widgets, which fill their icon white — correct for a button with a coloured background, wrong for these, which are plain links. The label already resolves to --t2; the icon should match it, which is what the mockup does (its markup fills these two with currentColor). */ body.light .topbar-contacts .elementor-button-icon svg { fill: currentColor; } /* ── 5. Theme toggle ─────────────────────────────────────────────────────── Both labels ship in the markup and CSS picks the visible one, so the label settles in the same paint as the palette rather than one frame later. */ .theme-toggle [data-theme-label="light"] { display: none; } body.light .theme-toggle [data-theme-label="dark"] { display: none; } body.light .theme-toggle [data-theme-label="light"] { display: inline; } /* Elementor wraps a shortcode widget in two divs, neither of which is a flex item by default, so the toggle would not sit on the topbar baseline. */ .topbar-right .elementor-widget-shortcode, .topbar-right .elementor-widget-shortcode .elementor-shortcode { display: flex; align-items: center; } /* ── 6. Active product tab ─────────────────────────────────────── design-system.css carries `body.light .pd-tab.active`, but product-tabs.php and mechanc.js both emit `is-active` — so that rule, and every other `.pd-tab.active` rule in the generated sheet, has never matched anything. The tab strip kept the dark theme's cyan in light mode as a result. Corrected here rather than in the generated sheet, and against the class the markup actually uses. */ body.light .pd-tab.is-active { color: var(--blue); border-bottom-color: var(--blue); } /* ── 7. Headings and links the Global Kit paints in literal hex ─────────── The kit's typography panel stores its colours as hex rather than as Global Colours, so `.elementor-kit-8 h1 … h6 { color:#DDE6F9 }` and `.elementor-kit-8 a { color:#00CFFF }` sit outside the token system completely — body.light cannot reach them the way it reaches --t1. In dark that is the right palette, so it never surfaced. In light it painted every heading the dark theme's near-white onto a near-white page, which is the 18.08 feedback's "all titles and sub titles in Black (right Part)", and left body copy links at a cyan with no contrast on white. These selectors match the kit's specificity exactly (0,1,1) and win on load order — light-theme.css is enqueued last. Matching rather than beating it is deliberate: anything Elementor styles per widget lands at (0,2,0) or higher and still overrides these, so a heading the client colours by hand in the editor keeps that colour. Only the kit-wide default is corrected. */ body.light h1, body.light h2, body.light h3, body.light h4, body.light h5, body.light h6 { color: var(--t1); } body.light a { color: var(--cyan); } body.light a:hover { color: var(--blue); } /* The kit's "White" swatch (--e-global-color-c09def5, #FFFFFF) is bound as the title colour on six headings: the homepage section title and its three translations, the About hero, and `.pd-title` on the connectors product template. All six sit on the page background rather than on a dark panel, so in light mode they were white on white. Unlike --e-global-color-mclight — the "Light BG" swatch, deliberately light in either theme — this one is only ever used as text, so it can follow the theme. Remapped here rather than overriding each of the six widgets, so any heading the client binds to White later is themed too. */ body.light { --e-global-color-c09def5: var(--t1); } /* ── 8. The one heading with a literal white ──────────────────────────── §7 covers the kit default and the White swatch, which between them account for every unreadable heading but one: the homepage's "Our Product Range" was given `#FFFFFF` directly in the editor rather than bound to a Global Colour, so no token can reach it. Grepping uploads/elementor/css confirmed it is the only such heading on the site — the four matches are this same widget on the homepage and its three translations, which share the widget id. `.elementor-widget` is added to reach (0,4,0) and tie Elementor's own `.elementor-1350 .elementor-element.elementor-element-27699c0 .elementor-heading-title`; light-theme.css is enqueued last, so the tie goes to this rule. If the client ever re-picks that heading's colour from the Global Colours panel instead, delete this block — §7 will already handle it. */ body.light .elementor-widget.elementor-element-27699c0 .elementor-heading-title { color: var(--t1); }