/* ==========================================================================
 * The location palette — legacy's `theme` column, on every surface.
 *
 * Legacy applies it the crude way: `<link href="/css/{{ app.session.get('theme') }}">`
 * (`base/base.html.twig:17`), swapping a whole 300–670 line stylesheet per location. The
 * two files it swaps between, `portal.css` and `redportal.css`, are overwhelmingly the same
 * plumbing — sidebar padding, select2 borders, summernote heights, the checkout wizard —
 * and the *palette* difference between them is small. This sheet is that difference, keyed
 * on `[data-location-theme]`, which `templates/partials/html.html.twig` puts on `<html>`.
 *
 * # What blue is
 *
 * Nothing. `portal.css` carries no `.btn-primary` rule at all and no `.nav > li.active`
 * border, so a blue location's staff screens are the admin theme's own colours — INSPINIA's
 * here, as they were legacy's `style.css` there. `[data-location-theme="blue"]` is a hook
 * that deliberately styles nothing, and the default when a location has no theme
 * (`App\Enum\LocationThemeEnum::of()`).
 *
 * # What red is, and why it is one rule
 *
 * Of `redportal.css`'s 313 lines, two reach a ported staff screen:
 *
 *   - `.btn-primary { background-color: #ed5565; border-color: #ed5565; color: #FFFFFF }` (:291)
 *   - `.nav > li.active { border-left: 4px solid #ed5565 }` (:41)
 *
 * Only the first is carried. The sidebar accent is dropped by instruction: this project's
 * side nav already marks the item you are on its own way, and legacy's 4px left edge fights
 * that rather than adding to it, so a red location's menu is the admin theme's.
 *
 * The rest is the checkout funnel (`.checkout-form`, `.sk-spinner-wave`, the payment
 * iframe), the tenant portal, and select2/summernote/`.mini-navbar` plumbing for INSPINIA 2
 * markup that this project does not build. Those surfaces get their palette when they are
 * ported, from this file; importing the rules now would be importing them for markup that
 * is not on any page.
 *
 * # The authentication screens are NOT painted from here
 *
 * `assets/styles/auth.css` has its own `.auth-theme-red` block and keeps it. Not
 * duplication: that sheet hard-paints the login button `#004FDE` / `#1ab394` to reproduce
 * legacy's own login CSS, so a variable override cannot reach it — a `background-color`
 * declaration wins over the custom property that would otherwise feed it. The auth screens
 * are the one surface whose primary button is not INSPINIA's, so they are the one surface
 * that needs a rule of its own.
 * ========================================================================== */

/*
 * INSPINIA builds `.btn-primary` out of `--ins-btn-*` custom properties, so the palette is
 * set by redefining them rather than by out-shouting `background-color` in eight states.
 *
 * Every state gets the same red, including hover and active. That is legacy's behaviour
 * rather than an oversight: its rule is flat and `!important`, so the button does not
 * darken on press, and letting INSPINIA's `--ins-btn-hover-bg` show through would turn a
 * red button green mid-click.
 */
[data-location-theme="red"] .btn-primary {
    --ins-btn-color: #ffffff;
    --ins-btn-bg: #ed5565;
    --ins-btn-border-color: #ed5565;
    --ins-btn-hover-color: #ffffff;
    --ins-btn-hover-bg: #ed5565;
    --ins-btn-hover-border-color: #ed5565;
    --ins-btn-active-color: #ffffff;
    --ins-btn-active-bg: #ed5565;
    --ins-btn-active-border-color: #ed5565;
    --ins-btn-disabled-color: #ffffff;
    --ins-btn-disabled-bg: #ed5565;
    --ins-btn-disabled-border-color: #ed5565;
    --ins-btn-focus-shadow-rgb: 237, 85, 101;
}

/*
 * Every green on a red location, not only the primary button — the operator's ruling of
 * 2026-09-29 ("replace all green with red"), which goes past `redportal.css`. Legacy's red
 * sheet repainted `.btn-primary` and left INSPINIA's green everywhere else; here the
 * `primary` family (#1ab394) and every green BUTTON go red.
 *
 * What stays green, by the same ruling: the `success` family — status badges, `text-success`,
 * success flashes — because there green means "done" and red would read as an error; the
 * side menu; and the solid primary badge. So `--ins-success` is never touched here.
 *
 * The primary token carries most of it — checkboxes, pagination, `bg-primary-subtle`, the
 * soft primary button — and links have their own. `:root[…]` so it outranks INSPINIA's own
 * `:root` / `[data-bs-theme=light]` declarations.
 *
 * The solid and outline success/primary buttons do NOT read the tokens — INSPINIA compiles
 * their hex into `--ins-btn-*` — so they are redefined below, flat like `.btn-primary` above.
 */
:root[data-location-theme="red"] {
    --ins-primary: #ed5565;
    --ins-primary-rgb: 237, 85, 101;
    --ins-primary-text-emphasis: #be4451;
    --ins-primary-bg-subtle: rgba(237, 85, 101, 0.15);
    --ins-primary-border-subtle: rgba(237, 85, 101, 0.3);
    --ins-link-color: #ed5565;
    --ins-link-color-rgb: 237, 85, 101;
    --ins-link-hover-color: #be4451;
    --ins-link-hover-color-rgb: 190, 68, 81;
}

/* Except the side menu — its items and the user's name keep the admin theme's colours
   (operator, 2026-09-29: the content side goes red, not the menu). The tokens are put back
   to INSPINIA's own values inside it, so whatever the menu draws from them stays green. */
[data-location-theme="red"] .sidenav-menu {
    --ins-primary: #1ab394;
    --ins-primary-rgb: 26, 179, 148;
    --ins-primary-text-emphasis: #14866f;
    --ins-primary-bg-subtle: rgba(26, 179, 148, 0.15);
    --ins-primary-border-subtle: rgba(26, 179, 148, 0.3);
    --ins-link-color: #1ab394;
    --ins-link-color-rgb: 26, 179, 148;
    --ins-link-hover-color: #16987e;
    --ins-link-hover-color-rgb: 22, 152, 126;
}

[data-location-theme="red"] .btn-success {
    --ins-btn-color: #ffffff;
    --ins-btn-bg: #ed5565;
    --ins-btn-border-color: #ed5565;
    --ins-btn-hover-color: #ffffff;
    --ins-btn-hover-bg: #ed5565;
    --ins-btn-hover-border-color: #ed5565;
    --ins-btn-active-color: #ffffff;
    --ins-btn-active-bg: #ed5565;
    --ins-btn-active-border-color: #ed5565;
    --ins-btn-disabled-color: #ffffff;
    --ins-btn-disabled-bg: #ed5565;
    --ins-btn-disabled-border-color: #ed5565;
    --ins-btn-focus-shadow-rgb: 237, 85, 101;
}

[data-location-theme="red"] .btn-outline-primary,
[data-location-theme="red"] .btn-outline-success {
    --ins-btn-color: #ed5565;
    --ins-btn-border-color: #ed5565;
    --ins-btn-hover-color: #ffffff;
    --ins-btn-hover-bg: #ed5565;
    --ins-btn-hover-border-color: #ed5565;
    --ins-btn-active-color: #ffffff;
    --ins-btn-active-bg: #ed5565;
    --ins-btn-active-border-color: #ed5565;
    --ins-btn-disabled-color: #ed5565;
    --ins-btn-disabled-border-color: #ed5565;
    --ins-btn-focus-shadow-rgb: 237, 85, 101;
}

/* And the solid primary badge — operator, 2026-09-29: "badge bg-primary keep it green". Its
   background is `rgba(var(--ins-primary-rgb), …)`, so putting the token back on the badge
   itself is enough. `text-bg-primary` is the same solid badge spelled the other way. */
[data-location-theme="red"] .badge.bg-primary,
[data-location-theme="red"] .badge.text-bg-primary {
    --ins-primary-rgb: 26, 179, 148;
}

/* The two greens INSPINIA writes as literals rather than tokens: the bordered tab's active
   underline and the calendar's today cell. */
[data-location-theme="red"] .nav-tabs.nav-bordered-primary .nav-item .nav-link.active,
[data-location-theme="red"] .nav-tabs.nav-bordered-success .nav-item .nav-link.active {
    border-bottom-color: #ed5565;
    color: #ed5565;
}

[data-location-theme="red"] .fc .fc-daygrid-day.fc-day-today,
[data-location-theme="red"] .fc .fc-timegrid-col.fc-day-today {
    background-color: rgba(237, 85, 101, 0.1);
}