:root {
--theme-text-muted: #5f5f5f;
--theme-border: #e3e3e3;
--theme-banner-background: #f750ca;
--theme-link-hover: #a3027a;
--theme-accent-3: #4fa8d8;
--theme-accent-1: #6fae6e;
--theme-accent-2: #ffd400;
--theme-footer-background: #181818;
--theme-footer-text: #f5f5f5;
--theme-row-hover: #fdf1fa;
--theme-page-background: #f6eef4;
--theme-menu-bar: #f750ca;
--theme-menu-text: #ffffff;
--theme-body-background: #ffffff;
--theme-body-text: #000000;
--theme-body-link: #c2038f;
--theme-button-body: #ffe5f9;
--theme-button-border: #f750ca;
--theme-accent-tint: #ffe5f9;
--theme-mms-accent-1: #6fae6e;
--theme-mms-accent-2: #ffd400;
--theme-mms-accent-3: #4fa8d8;
--theme-mms-button-body: #ffe5f9;
--theme-mms-button-border: #f750ca;
/* Bootstrap variable remap - see docblock above. Sourced from
button_border, not button_body (2026-09-06, found live) -
button_body is now deliberately the LIGHT button fill (see the
unified .btn-primary rule below), but --bs-primary/--bs-primary-rgb
back dozens of OTHER "vivid accent" uses across the admin (focus
rings, subtle hover tints, icon chips, badges) that were all built
assuming button_body was still the vivid one. button_border is now
that vivid token, so this remap follows it instead. */
--bs-primary: var(--theme-button-border);
--bs-primary-rgb: 247, 80, 202;
--bs-link-color: var(--theme-body-link);
--bs-link-hover-color: var(--theme-link-hover);
--bs-body-color: var(--theme-body-text);
--bs-body-bg: var(--theme-body-background);
--bs-border-color: var(--theme-border);
--bs-secondary-color: var(--theme-text-muted);
/* Sitewide type system (2026-08-07, Allie: "lets sort fonts out... i
agree we need a uniform sitewide look") - Space Grotesk for
headings/numbers (reads as operations/production software, fits a
business-management back end rather than a retail storefront),
Inter for body copy (the standard for dense, legible admin UI).
Both loaded via Google Fonts in header.php/sidebar-
header.php, same CDN-heavy convention as Bootstrap/jQuery/
DataTables/TinyMCE elsewhere in this app. Real fallback chain kept
on both in case the CDN is ever slow/blocked - never just the web
font name alone. */
--font-display: 'Space Grotesk', -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Helvetica, Arial, sans-serif;
--font-body: 'Inter', -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Helvetica, Arial, sans-serif;
--bs-body-font-family: var(--font-body);
/* Page-wide gradient (owner reference: legacy/accounting's own
--wl-gradient token) - composed from real tokens already here
rather than its own stored value, so it stays in sync with
accent-tint/body-background automatically instead of needing to be
kept in step by hand. */
--theme-gradient: linear-gradient(180deg, var(--theme-accent-tint) 0%, var(--theme-body-background) 55%);
}
body {
background: var(--theme-gradient);
background-attachment: fixed;
color: var(--theme-body-text);
}
/* Display font on headings/numbers, sitewide (2026-08-07) - Space
Grotesk's real weight range is 300-700 (no 800), so anything that
used to be fw-bold 800 needs to drop to 700 here or the browser
silently synthesizes/falls back instead of actually using the
loaded font at an unsupported weight. .fw-bold itself is Bootstrap's
own utility (font-weight:700 already) so it doesn't need touching -
only the handful of custom 800 rules built across the dashboard/
shell CSS this session do. */
h1, h2, h3, h4, h5, h6,
.app-stat-num, .stat-mini-num, .pipeline-tile .num,
.topbar-title, .page-header-card h1 {
font-family: var(--font-display);
font-weight: 700;
}
/* Tabular figures on every $/count display (2026-08-07) - a real
accounting-software detail now that this system includes a real
accounting module, not just decoration: columns of numbers align
vertically instead of each digit having proportional width. */
.app-stat-num, .stat-mini-num, .pipeline-tile .num,
.mystores-mini-table td {
font-variant-numeric: tabular-nums;
}
.card, .navbar, .dropdown-menu, .modal-content {
background-color: var(--theme-body-background);
color: var(--theme-body-text);
border-color: var(--theme-border);
}
.text-muted, .text-secondary {
color: var(--theme-text-muted) !important;
}
/* Unified 2026-09-06 (Allie: "unification of button site wide.. i want
all buttons to have the outline [look]") - .btn-primary reuses the
EXACT SAME role mapping .btn-store-theme already uses below (fill =
button_body, border/text = button_border, full swap on hover/active),
not a separate "outline mode" formula - .btn-outline-primary gets the
identical rule too, so there is only ever ONE real button style, on
the storefront and in the admin alike. The reason every button now
READS as outline isn't new CSS - it's that Generate Theme (see
mystores/stores/layout.php) generates button_body as a light, muted
tone close to body_background and keeps button_border vivid, so the
same fill/border-swap formula that always existed here naturally
produces an outline look, instead of the old vivid+vivid pairing that
made every button read as a solid block regardless of which Bootstrap
class was used. This also fixes the dark-mode contrast bug found
live (fill and text were sometimes too close in lightness to read) -
fill and text are now deliberately far apart by construction. */
.btn-primary, .btn-outline-primary {
/* border-color = button_border (matches TEXT, not the fill) - a copy
error found live 2026-09-06: it was set to button_body (same as
the fill), making the border invisible and leaving text floating
with no visible outline box at all. .btn-store-theme below already
had this right; this rule just needed to actually match it. */
--bs-btn-bg: var(--theme-button-body);
--bs-btn-border-color: var(--theme-button-border);
--bs-btn-border-width: 2px;
--bs-btn-color: var(--theme-button-border);
--bs-btn-hover-bg: var(--theme-button-border);
--bs-btn-hover-border-color: var(--theme-button-border);
--bs-btn-hover-color: var(--theme-button-body);
--bs-btn-active-bg: var(--theme-button-border);
--bs-btn-active-border-color: var(--theme-button-border);
--bs-btn-active-color: var(--theme-button-body);
font-weight: 600;
}
/* "Armed"/toggled-on state (2026-09-06, Allie: "if you need an armed
button, just reverse the rest and hover settings") - permanently
applies the same swapped colours :hover/:active already use, as a
real persistent state rather than a different Bootstrap variant.
admin/stock/item-zones.php's ruler-mode toggle uses this instead of
switching between btn-primary/btn-outline-secondary. */
.btn-primary.is-armed, .btn-outline-primary.is-armed {
--bs-btn-bg: var(--theme-button-border);
--bs-btn-border-color: var(--theme-button-border);
--bs-btn-color: var(--theme-button-body);
}
.btn { border-radius: 10px; }
/* ---------- storefront button theme (2026-07-31) ---------- */
/* Deliberate resting/hover COLOUR SWAP, not two separate stored
states - body becomes border and vice versa on hover/active. Same
pattern the Layout tab's own live-preview button demonstrates
interactively (mystores/stores/layout.php). Text colour always
matches whichever colour is currently the border (Allie's own
request, 2026-07-31 - "can the text be the button border colour" -
the theme_tokens description for button_border was relabelled
"Button Text/Border" for the same reason), so it swaps alongside
background/border rather than staying fixed and losing contrast
once the background catches up to it. */
.btn-store-theme {
background-color: var(--theme-button-body);
border: 2px solid var(--theme-button-border);
color: var(--theme-button-border);
font-weight: 600;
border-radius: 10px;
padding: 0.5rem 1.25rem;
transition: background-color 0.15s ease, border-color 0.15s ease, color 0.15s ease;
}
.btn-store-theme:hover,
.btn-store-theme:active,
.btn-store-theme:focus {
background-color: var(--theme-button-border);
border-color: var(--theme-button-body);
color: var(--theme-button-body);
}
/* Store nav/body link hover (2026-07-31, Allie's own question - "what
happens to the menu and Body links on hover? do we have a process
for that?"). Both classes shift to --theme-banner-background (Colour
A's own vivid rendering) on hover - the same "shift to the other
brand colour" interactive language the button swap already uses,
rather than inventing a third behaviour. */
.store-menu-link {
color: var(--theme-menu-text, #ffffff);
transition: color 0.15s ease;
}
.store-menu-link:hover,
.store-menu-link:focus {
color: var(--theme-banner-background);
}
.store-body-link {
color: var(--theme-body-link);
transition: color 0.15s ease;
}
.store-body-link:hover,
.store-body-link:focus {
color: var(--theme-banner-background);
}
/* Storefront surfaces - menu_bar/page_background/body_background/
body_text (2026-08-11) - these 4 store tokens are editable on the
Layout tab and resolve into --theme-* vars for the real storefront
markup. */
.store-menu-bar { background-color: var(--theme-menu-bar, #c0c0c0); }
.store-page-bg { background-color: var(--theme-page-background, #000000); }
.store-body-bg {
background-color: var(--theme-body-background, #ffffff);
color: var(--theme-body-text, #000000);
}
.store-body-text { color: var(--theme-body-text, #000000); }
/* ---------- header / navbar ---------- */
.navbar-brand img { height: 60px; }
.navbar-mms {
/* Light gradient (body-background -> a light brand-tint wash), not a
vivid brand fill - text below flips to dark to match, same as the
modal header (superseded 2026-07-28, first tried a bold-magenta
version, wrong direction entirely). */
background: linear-gradient(90deg, var(--theme-body-background) 0%, var(--theme-accent-tint) 100%);
}
/* Gradient modal headers, applied globally so every modal (this one,
confirmDialog in footer.php, and any future one) gets it automatically
instead of each page inline-styling its own - owner reference:
legacy/accounting's Edit Card modal. Light gradient, so header
text/close button need to be DARK here, not white - this is the
opposite of a vivid brand-fill bar, which would need light text
instead. */
.modal-header {
background: linear-gradient(90deg, var(--theme-body-background) 0%, var(--theme-accent-tint) 100%);
color: var(--theme-body-text);
border-bottom: none;
}
.modal-header .modal-title, .modal-header h1, .modal-header h2, .modal-header h3 { color: var(--theme-body-text); }
/* Close button needs to flip with light/dark mode, not be one fixed
colour - dark X on the light-mode gradient, white X on the dark-mode
gradient. Tied to the same data-bs-theme attribute Theme::currentMode()
already sets on , rather than a separate token, since it's a
direct function of which mode is active, not an independent style
choice. */
.modal-header .btn-close { filter: none; }
[data-bs-theme="dark"] .modal-header .btn-close { filter: invert(1) grayscale(100%) brightness(200%); }
/* Every modal scrolls internally instead of overflowing the viewport -
applied unconditionally (not just a mobile media query), since the
owner hit this exact bug on desktop too, 2026-07-28. Went through
several attempts on this same bug the same day - fullscreen class,
then modal-dialog-scrollable, then a hand-rolled flex/max-height
version using `max-height: inherit` on .modal-content - the last one
was still reportedly broken even after the actual missing overflow:
hidden was added, which turned out to most likely be
assets/css/theme.css.php never having a cache-busting query string
(fixed separately in header.php, 2026-07-28) - i.e. the fix was
probably fine and just never reached the browser. Rewritten once
more anyway to remove any dependency on `inherit` resolving
correctly, since that's one more thing that can't silently fail this
way: both .modal-dialog and .modal-content get the SAME literal
calc() twice each (plain vh first, dvh second - later declaration
wins where supported, older browsers just keep the vh version,
avoiding any @supports scoping too). min-height: 0 on modal-body
specifically matters - flex children default to min-height:auto,
which silently blocks internal scrolling from ever kicking in
regardless of overflow-y. */
.modal-dialog {
max-height: calc(100vh - 3.5rem);
max-height: calc(100dvh - 3.5rem);
}
.modal-content {
max-height: calc(100vh - 3.5rem);
max-height: calc(100dvh - 3.5rem);
overflow: hidden;
display: flex;
flex-direction: column;
}
/* THE actual bug, found via dev tools computed-styles inspection,
2026-07-28 (screenshot showed max-height/overflow correctly applied
to .modal-content, so the constraint itself was always working) -
every modal here wraps modal-header/modal-body/modal-footer in a