and are then reset to #fff the * moment you cross into .kismet-scope. Verified in-browser. * - `.kismet-scope` alone would tie on specificity (0,1,0) and LOSE, because * kismet-base-style is enqueued BEFORE kismet-tailwind — later wins a tie. * `:root .kismet-scope` is (0,2,0) and wins regardless of load order. * - No `!important` needed anywhere. The toolbar's background is an INLINE * style (`background:var(--vr-bg, #fff)`) which would normally be unbeatable * from a stylesheet — but var() resolves against the inherited cascade at the * element, so supplying the variable feeds the inline style the right value. * We use the plugin's seam rather than fighting it, and nothing here has to * keep winning an arms race as the bundle changes. * * WHY VARIABLES, NEVER HEXES: the palette lives in the DB (wp_global_styles, * per client) — theme.json still says base:#ffffff while this site serves * base:#f8f4ec. Hardcoding #f8f4ec would desync the instant a client's palette * changed and would make this shared theme client-specific. Reskinning stays a * palette swap; the elements pages follow for free. * * SCOPE: colours only. Deliberately NOT overridden — * - --vr-font-body / --vr-font-heading are already `inherit`, so they pick up * the theme's fonts with no help from us. * - radius / shadows / button sizing are the plugin's design language, not * brand identity. Out of scope for a colour fix. */ :root, :root .kismet-scope { /* Surfaces */ --vr-bg: var(--wp--preset--color--base); --vr-surface: var(--wp--preset--color--surface); --vr-surface-2: var(--wp--preset--color--surface); --vr-surface-alt: var(--wp--preset--color--surface); --vr-surface-hover: var(--wp--preset--color--accent-soft); /* Text */ --vr-text: var(--wp--preset--color--contrast); --vr-text-primary: var(--wp--preset--color--contrast); --vr-text-secondary: var(--wp--preset--color--muted); --vr-text-muted: var(--wp--preset--color--muted); /* Lines. Hover goes to the brand accent — the plugin's default is merely a * darker grey (#d1d5db), which reads as "unstyled" against a sand page. */ --vr-border: var(--wp--preset--color--outline); --vr-border-hover: var(--wp--preset--color--accent); /* Brand. * --vr-brand-accent is the plugin's OWN documented hook: kismet-tailwind.css * declares `--vr-accent: var(--vr-brand-accent, #1a1a1a)`, i.e. it is * explicitly waiting for a host theme to supply it. Set that rather than * overriding --vr-accent directly. * --vr-primary/-secondary default to #1a1a1a/#374151 — ink and grey, not a * brand colour — so they map to contrast/muted, NOT to the gold accent. */ --vr-brand-accent: var(--wp--preset--color--accent); --vr-primary: var(--wp--preset--color--contrast); --vr-primary-soft: var(--wp--preset--color--accent-soft); --vr-secondary: var(--wp--preset--color--muted); } /* ── Results-page view toggle: the floating island's Grid/Map chip ──────────── * * The island at the bottom of the results page is [Grid|Map] [dates] [guests]. * Its ACTIVE chip was the one tan thing on the page: the bundle renders it with * an inline `background: var(--vr-accent)`, and --vr-accent resolves (via * --vr-brand-accent above) to the palette's accent = brass #c89432. Client wants * green here — Maui Inn is a green-forward brand ("less of the light tan, more * of the green"); the brass chip read as off-brand against it. * * WHY THIS SELECTOR, AND WHY IT IS SAFE: * - We feed the plugin's OWN token seam rather than fighting it. The chip's * background is an INLINE style, which no stylesheet could beat without * !important — but var() resolves against the cascade AT the element, so * setting --vr-accent ON the chip feeds that inline style the right value. * Same technique (and same reasoning) as the token block above. * - Scoped to `.kismet-glass-bar` — the island's own class. DO NOT scope this to * `[data-kismet-element="results-page"]`: the island is React-PORTALED out to * document.body, so it has NO kismet-element ancestor once it mounts. A * mount-scoped selector matches before the portal and stops matching after, * which renders as the chip "reverting" to gold at random — same CSS, moved * DOM. That exact bug shipped once; this comment is why it will not again. * `.kismet-glass-bar` travels WITH the island wherever React puts it. * - `button[style*="var(--vr-accent)"]` picks the ACTIVE chip only (the bundle * writes that inline background on whichever of Grid/Map is selected), so the * rule follows the selection instead of hardcoding "Grid". * - Deliberately NOT set on .kismet-scope or globally: --vr-accent is written * inline by 7 bundles (blog-detail, collection-page, group-page, map-view, * property-detail, property-sheet, results-page) and has 4 more consumers in * the bundle CSS (focus ring + two text colours). Brass is a real brand colour * — the homepage buttons are deliberately brass — so this must not go global. * Only the island chip changes. * * WHY A LITERAL AND NOT A PALETTE VAR (the file's rule above says never hex): * that rule exists so we don't desync from the DB palette — but this green is * not IN the palette. Maui Inn's greens (#16281f emerald / #111c15) are chrome * literals in brand.json, parts/footer.html and parts/header.html; there is no * preset to point at. Matches the "Browse All" header CTA exactly. */ :root .kismet-glass-bar button[style*="var(--vr-accent)"] { --vr-accent: #16281f; }