/* Platform.Ui's shared styles (issue #1104, moved out of VisaOps.BlazorApp's app.tailwind.css unchanged): the
   firm-branded "tinted header band" system — .widget-header-band, every MudDataGrid column-header row, every
   MudDialog title bar — and the branded MudTooltip that ActionButton relies on. Plain CSS, no Tailwind, so any
   product can link it: _content/Platform.Ui/css/platform-ui.css (PlatformUiAssets.StylesheetPath), after
   MudBlazor's stylesheet and before the product's own.

   Every colour reads the firm's palette (blazor-styling.md §2): --visaops-band-rgb is the firm's real Primary,
   emitted by AppThemeProvider, falling back to MudBlazor's own --mud-palette-primary-rgb. No literal colours. */

/* Shared padding for every "tinted header band" this app uses (.widget-header-band, the MudDataGrid
   column-header rule, and the MudDialog title-bar rule below) — one value, so a future adjustment (e.g.
   "these read a bit cramped") changes all of them at once instead of needing the same literal repeated
   in three places and inevitably drifting. 8px 16px, not the original 4px 16px this shipped as — the
   tighter value was tuned specifically for the Dashboard widget cards' own compact one-line band, and
   reads noticeably tight once reused for a MudDataGrid header row or a MudDialog title bar, contexts
   that read better with a bit more breathing room. */
:root {
    --header-band-padding: 8px 16px;
}

/* MudBlazor's default tooltip is a flat, opaque mud-palette-gray-darker box — reads as an unstyled system
   tooltip rather than part of the app. Same tinted-translucent treatment as .widget-header-band (the
   firm's own Primary colour via --mud-palette-primary-rgb, so it's on-brand rather than a hardcoded
   colour) instead of a hardcoded grey.

   MudBlazor's own rule is the combined .mud-tooltip.mud-tooltip-default (two classes) — a single-class
   .mud-tooltip-default selector here has lower specificity and silently loses regardless of load order
   (the same mistake the earlier .mud-link rule made before its :where() fix, just the opposite direction:
   there we needed to always lose, here we need to actually win). Matching the same two-class selector. */
.mud-tooltip.mud-tooltip-default {
    background-color: rgba(var(--visaops-band-rgb, var(--mud-palette-primary-rgb)), 0.9);
    color: var(--mud-palette-appbar-text);
}

/* Dashboard widget header band — a ~25% tint of the firm's own accent colour (Primary doubles as the app
   bar background, see ThemeRegistry.Build) rather than a hardcoded colour, using MudBlazor's own *-rgb
   custom property so it follows whatever a firm has actually branded. Also used on the Dashboard's
   Attention digest panel (a plain div, not a MudCard) so it reads as the same kind of "card" as the
   widgets below it, even though it isn't actually an IDashboardWidget (dashboard.md §3 — Attention is a
   cross-cutting digest, not a section home).

   Padding/size are deliberately tighter than .section-panel/.section-heading's page-level defaults —
   this band's only job is to hold a one-line title plus a small icon button, not introduce a subsection,
   so the generous page-heading spacing reads as wasted space here.

   Border radius set explicitly rather than relying on inherit — MudCardHeader's own CSS class inherits
   it from the parent MudCard automatically, but a plain div (the Attention case) has nothing to inherit
   from, so it rendered with square corners while the widget cards' rounded ones came for free. Matching
   the theme's own DefaultBorderRadius (ThemeRegistry.Build) via MudBlazor's CSS variable keeps it in
   sync if that value ever changes, rather than a second hardcoded "6px".

   Every band-shaped tint (this, grid headers, dialog titles, tooltips, the calendar and journey-map headers)
   reads --visaops-band-rgb, the firm's real Primary (AppThemeProvider), not --mud-palette-primary-rgb: in dark
   mode the palette's Primary is lifted to read as text on the dark surface, which would make a band pale under
   its white text (issue #1053). Light tints that carry Primary-coloured text keep the palette's own Primary. */
.widget-header-band {
    background-color: rgba(var(--visaops-band-rgb, var(--mud-palette-primary-rgb)), 0.80);
    padding: var(--header-band-padding) !important;
    border-radius: var(--mud-default-borderradius) var(--mud-default-borderradius) 0 0;
}

.widget-header-band .section-heading {
    margin-bottom: 0;
    font-size: 1rem;
    font-weight: normal;
    color: var(--mud-palette-appbar-text);
}

/* Standard top spacing for content sitting directly below a widget-header-band, for containers that (unlike
   MudCardContent, which already defaults to 16px on every side) provide no top padding of their own — e.g.
   MudExpansionPanel's own content area (.mud-expand-panel-content), confirmed against the installed
   MudBlazor.min.css to carry only padding-bottom, no padding-top at all. Matches MudCardContent's own
   16px default rather than inventing a new value, so a banded section's first row of content sits the
   same distance from its header everywhere in the app, whichever container renders it. */
.widget-header-band-content {
    padding-top: 1rem;
}

/* The Hide-widget MudIconButton sitting in the band alongside the title — same colour so it doesn't
   stand out as unstyled against the tinted background. */
.widget-header-band .mud-icon-button {
    color: var(--mud-palette-appbar-text);
}

/* A count MudChip sitting in the band (e.g. the Tasks board's per-lane count) — MudChip's own default
   variant is actually Filled (.mud-chip-filled — confirmed against MudChip.razor.cs's own CssBuilder
   chain, not inferred from which CSS rule looked like a plausible default; an earlier attempt here
   targeted .mud-chip-text, a class the chip never carries, and silently matched nothing).
   .mud-chip-filled's own rule is --mud-palette-text-primary on --mud-palette-action-disabled-background,
   both picked for a light page background, not a darkened band; left alone the number reads as
   low-contrast dark-on-dark. The number itself matches the band's own text colour (appbar-text, same as
   the lane title next to it), on a light translucent fill so it still reads as a chip.

   .mud-chip-color-default only — a deliberately-coloured chip (e.g. QuestionnaireSummary's
   Color="Color.Success" "Submitted" chip) must keep its own colour rather than being flattened to this
   neutral treatment. MudChip emits mud-chip-color-{color} for every colour, Default included (its own
   CssBuilder in MudChip.razor.cs, v9.5.0) — the stylesheet just has no rule for the default one, which is
   why an earlier :not([class*="mud-chip-color-"]) guard here, reasoned from the stylesheet alone, excluded
   every chip and left the band counts dark-on-dark. */
.widget-header-band .mud-chip-filled.mud-chip-color-default {
    color: var(--mud-palette-appbar-text);
    background-color: rgba(255, 255, 255, 0.2);
}

/* MudChip's own base rule carries margin: 4px on every side — harmless floating free-standing, but inside
   a 4px-padded flex row it adds a further 8px (top+bottom) on top of the band's own padding, so a band
   holding a chip ends up visibly taller than one that doesn't (e.g. the Tasks grid's own column-header
   band, which holds no chip) despite both using the same 4px 16px padding. Confirmed via a side-by-side
   height measurement: 40px with the chip's own margin left in, 32px once zeroed — matching the grid
   header exactly. */
.widget-header-band .mud-chip {
    margin: 0;
}

/* An outlined ActionButton sitting in the band (e.g. QuestionnaireSummary's per-section "Request again") —
   .mud-button-outlined's own rule is text-primary on both text and border (Color.Default adds no
   override), which reads as near-illegible dark-on-tinted, the same contrast bug .mud-icon-button/
   .mud-chip-filled above already fix for their own elements. */
.widget-header-band .mud-button-outlined {
    color: var(--mud-palette-appbar-text);
    border-color: var(--mud-palette-appbar-text);
}

/* MudExpansionPanel's own built-in expand/collapse chevron (rendered automatically unless HideIcon is
   set — both QuestionnaireSummary's and TeamsList's panels use it) is a bare MudIcon, not a
   MudIconButton, so the .mud-icon-button fix above doesn't reach it. Its own base rule
   (.mud-icon-root { color: var(--mud-palette-action-default) }) is a mid-grey, illegible against the
   tint — same contrast bug, different element. */
.widget-header-band .mud-expand-panel-icon {
    color: var(--mud-palette-appbar-text);
}

/* Every MudDataGrid's column-header row, app-wide — the same .widget-header-band treatment every
   widget/section header elsewhere already gets, rather than MudBlazor's own plain default. Values copied
   from .widget-header-band/.widget-header-band .section-heading above (1rem/normal weight, appbar-text
   colour, --header-band-padding — MudBlazor's own default header-cell padding is 16px all round, taller
   than this) rather than sharing those rules directly — their own
   selectors don't reach into a MudDataGrid's framework-rendered header cells.

   MudBlazor's own background rule is the two-class .mud-table-head .mud-table-cell, but its own COLOUR
   rule is actually the three-class .mud-table-root .mud-table-head .mud-table-cell — easy to miss since
   both selectors render identically today, and the exact bug this session already hit once for
   .mud-link/.mud-tooltip: a two-class override here silently lost the colour tie-break (while the
   background half, a genuine two-class tie, happened to still win on load order) because it was
   competing against a higher-specificity rule, not an equal one. Matching the three-class selector for
   every property here, not just colour, so nothing here is left one specificity level short of
   MudBlazor's own actual rule. */
.mud-table-root .mud-table-head .mud-table-cell {
    background-color: rgba(var(--visaops-band-rgb, var(--mud-palette-primary-rgb)), 0.80);
    color: var(--mud-palette-appbar-text);
    font-size: 1rem;
    font-weight: normal;
    padding: var(--header-band-padding);
}

/* A real MudTable/MudDataGrid nested inside a MudCard whose own header already carries
   .widget-header-band (e.g. ApplicantDetail's inline Cases table, or TaskGrid's grid inside its
   "Task List" card) would otherwise render two identically-tinted 0.80 bands stacked on top of each
   other — the card's own header and the grid's column-header row — with nothing visually separating
   them. A lighter 0.6 shade for a nested grid's header keeps it legible as a distinct, subordinate
   level rather than reading as a second copy of the card header. Scoped to :has(.widget-header-band) so
   it only ever applies to a grid that's actually sitting under a banded header — every top-level list
   page (Cases, Intake, Tasks, Users, ...) renders its MudDataGrid directly on the page with no
   surrounding MudCard/band at all, so this rule never matches there and those grids keep the standard
   0.80 tint. Higher specificity than the base rule above (an extra ancestor class), so only
   background-color needs restating here — colour/padding/font-size still cascade from it.

   Also matches .mud-expand-panel (TeamsList's per-team member table sits directly inside a banded
   MudExpansionPanel, with no ancestor .mud-card at all — the whole page is a bare MudExpansionPanels
   list, unlike QuestionnaireSummary's own panels, which happen to sit inside CaseDetail's outer
   MudCard) — the same "table nested under a band" case, just a different ancestor element carrying
   the band. */
.mud-card:has(.widget-header-band) .mud-table-root .mud-table-head .mud-table-cell,
.mud-expand-panel:has(.widget-header-band) .mud-table-root .mud-table-head .mud-table-cell {
    background-color: rgba(var(--visaops-band-rgb, var(--mud-palette-primary-rgb)), 0.6);
}

/* MudSimpleTable (e.g. ApplicantDetail's Payment ledger, Engagement pack document-status table) renders
   a plain, un-classed <table>/<thead>/<th> — confirmed against MudSimpleTable.razor's own source, which
   emits nothing beyond a bare <table>@ChildContent</table>. It carries none of .mud-table-root/
   .mud-table-head/.mud-table-cell, so neither rule above ever reaches it; a MudSimpleTable inside a
   banded card rendered with zero header styling at all rather than merely the wrong shade. Given its
   own self-contained rule here (not just a background-color override, since there is no base rule for
   it to inherit color/padding/font-size from) at the same 0.6 nested shade the .mud-table-root override
   above uses, so every table inside a banded card — real MudTable or plain MudSimpleTable — reads at
   the same subordinate level. Scoped to :has(.widget-header-band) for the same reason as above: a
   MudSimpleTable used standalone elsewhere (outside any banded card) is untouched. */
.mud-card:has(.widget-header-band) .mud-simple-table thead th {
    background-color: rgba(var(--visaops-band-rgb, var(--mud-palette-primary-rgb)), 0.6);
    color: var(--mud-palette-appbar-text);
    font-size: 1rem;
    font-weight: normal;
    padding: var(--header-band-padding);
}

/* MudBlazor's own .mud-table (the outermost wrapper div a MudDataGrid renders into) already carries
   border-radius: var(--mud-default-borderradius) by default — the same variable .widget-header-band uses
   — but with no overflow clipping, so a colored header band just overhangs past that already-rounded
   edge with square corners of its own instead of being cropped to it. MudBlazor's own first-child/
   last-child border-radius rules for the header cell exist only behind Bordered/RTL/sticky-header
   variants (confirmed against the installed MudBlazor.min.css) — none of which this app's plain grids
   use — so there is no default per-cell rounding to lean on either. Clipping the outer wrapper to its
   own existing radius is the actual fix, not re-deriving the same radius on individual header cells.

   Confirmed via a standalone repro (real MudBlazor.min.css + this file, real DOM shape) that the clip
   itself genuinely works — the radius alone was still invisible because none of this app's grids set
   Outlined="true" the way every widget MudCard does, so there was no border line anywhere to trace the
   curve against the page's own similarly-toned background. Adding the exact border Outlined="true" itself
   adds (.mud-table-outlined's own rule) rather than requiring every grid to opt in individually. */
.mud-table {
    overflow: hidden;
    border: 1px solid var(--mud-palette-lines-default);
}

/* MudDataGrid's own sort/filter/column-menu icons default to --mud-palette-action-default (a mid-grey)
   via their own single-class selectors — invisible against the darkened band above. Same fix
   .widget-header-band .mud-icon-button already applies for widget-card header icon buttons.
   .mud-icon-button-label is the one that actually carries the filter icon's own colour (confirmed
   against the installed MudBlazor.min.css) — .mud-icon-button alone doesn't. */
.mud-table-head .mud-table-cell .sort-direction-icon,
.mud-table-head .mud-table-cell .mud-table-sort-label-icon,
.mud-table-head .mud-table-cell .column-options-icon,
.mud-table-head .mud-table-cell .drag-icon-options,
.mud-table-head .mud-table-cell .mud-icon-button,
.mud-table-head .mud-table-cell .mud-icon-button-label {
    color: var(--mud-palette-appbar-text);
}

/* Every MudDialog's title bar, app-wide — the same .widget-header-band treatment every widget/section
   header and grid column-header above already gets. Dialog titles across this app are passed as a plain
   string to DialogService.ShowAsync<T>("Title", options) rather than a <TitleContent> template per
   dialog, so MudBlazor always renders them through its own .mud-dialog .mud-dialog-title element — one
   global rule here covers all ~35 dialogs the same way the grid-header rule covers every MudDataGrid,
   with no per-dialog markup change needed. MudBlazor's own rule already gives this element top-corner
   border-radius matching --mud-default-borderradius (confirmed against the installed MudBlazor.min.css)
   — same variable .widget-header-band uses — so only background/colour/padding need overriding here. */
.mud-dialog .mud-dialog-title {
    background-color: rgba(var(--visaops-band-rgb, var(--mud-palette-primary-rgb)), 0.80);
    color: var(--mud-palette-appbar-text);
    padding: var(--header-band-padding);
}

/* A dialog's own close ("X") button, when DialogOptions.CloseButton is enabled — not currently used by
   any dialog in this app, but styled here defensively so it doesn't silently render invisible-grey against
   the darkened band the moment one is. Same .mud-icon-button-label fix as the grid header's own icons. */
.mud-dialog .mud-dialog-title .mud-icon-button,
.mud-dialog .mud-dialog-title .mud-icon-button-label {
    color: var(--mud-palette-appbar-text);
}