/* Global Administration wears the theme's WARNING colour, everywhere it appears: the page
   itself, its hub cards, and its nav entry. Nothing here hardcodes a colour - every rule is a
   tint of the same palette variable, so it follows whichever theme (and light/dark mode) the
   user picked, and a new theme needs no change here.

   Why a plain stylesheet and not scoped CSS: three unrelated components consume these classes -
   AdminShell (page wash), AdminHub (cards) and NavMenu (drawer entry, which lives in the static
   layout) - and scoped CSS would need the same rules copied into all three. */

/* The theme's REAL surface colour, captured before .global-admin-page below re-defines it. A
   custom property may not reference itself, so the capture has to happen on an element that does
   not do the overriding - :root, where MudThemeProvider writes the palette. */
:root {
    --sf-plain-surface: var(--mud-palette-surface);
}

.global-admin-page {
    background-color: rgba(var(--mud-palette-warning-rgb), 0.14);
    border-left: 4px solid var(--mud-palette-warning);

    /* FULL BLEED. The negative margins cancel MudMainContent's own padding (MainLayout gives it
       "pt-16 pa-4" = 64px top, 16px elsewhere) and the padding puts it straight back, so the
       colour reaches the edges of the content area instead of sitting in a card inside it. The
       top 64px is what clears the fixed appbar; the wash runs up behind it, which is invisible
       because the appbar is opaque and paints on top.

       If MainLayout's MudMainContent classes ever change, these four numbers change with them -
       that coupling is the price of filling a region this element does not own. */
    margin: -64px -16px -16px -16px;
    padding: 64px 16px 16px 16px;
    min-height: 100vh;

    /* The page wash alone is nearly invisible: MudBlazor paints every paper, tab strip, card and
       table with --mud-palette-surface, which is opaque and covers most of the page. Re-defining
       that ONE variable inside the wrapper tints all of them at once, and keeps working for
       components nobody thought to enumerate here.

       Mixed against --mud-palette-background, not --mud-palette-surface: a custom property may not
       reference itself (that is a cycle, and the whole declaration would be thrown away). Opaque
       on purpose - a translucent surface would make the role matrix's STICKY feature column show
       the columns scrolling underneath it.

       color-mix needs a 2023+ browser; where it is missing the declaration is simply invalid and
       surfaces stay their normal colour, which is the pre-#331 look rather than a broken page. */
    --mud-palette-surface: color-mix(in srgb, var(--mud-palette-warning) 6%, var(--mud-palette-background));
}

/* The hub cards and the group block that holds them. !important because MudCard/MudPaper paint
   their own surface colour inline-equivalent through .mud-paper. */
.global-admin-card {
    background-color: rgba(var(--mud-palette-warning-rgb), 0.12) !important;
    border-color: var(--mud-palette-warning) !important;
}

/* Beats AdminHub's own .admin-card:hover, which would otherwise flip the border to primary. */
.global-admin-card:hover {
    border-color: var(--mud-palette-warning) !important;
}

.global-admin-group {
    background-color: rgba(var(--mud-palette-warning-rgb), 0.05) !important;
    border-color: var(--mud-palette-warning) !important;
}

/* Grids opt OUT of the tint (owner, 2026-08-24): a data grid is where the eye actually reads, and
   tinting the rows made the data feel like chrome. Only the VARIABLE is put back - never a
   background-color - so the role matrix keeps its own group-row and band colours, which are
   painted from different palette entries. */
.global-admin-page .mud-table,
.global-admin-page .role-matrix {
    --mud-palette-surface: var(--sf-plain-surface);
    background-color: var(--sf-plain-surface);
}