/* ===== Badge Component ===== */

.ui-badge-wrapper {
    display: inline-flex;
    align-items: center;
    justify-content: center;
    padding: 4px 10px;
    font-size: var(--text-xs);
    font-weight: var(--weight-semibold);
    background: var(--badge-background, var(--meb-surface-input-filled));
    color: var(--badge-text, var(--meb-text-default));
    border: 1px solid var(--badge-border, transparent);
    border-radius: 6px;
    user-select: none;
    white-space: nowrap;
}

/* --- Pill shape --- */

.ui-badge-wrapper.pill {
    border-radius: 999px;
}

/* --- Variant: Filled --- */

/* #10567 triad round 5 (hostile lens, Major 2): the exact same collision round 4 fixed for
   --badge-border applies here -- Badge.razor.cs inlines the token resolver's output as a `style`
   attribute, and the resolver ALWAYS emits a --badge-background custom property (ComponentTokenResolver.cs's
   BuildVariables sets --{component}-background right beside --{component}-border), so a `.type-*`
   rule that sets --badge-background is permanently dead code -- every filled coloured badge
   (success/warning/error/info) silently rendered the resolver's generic surface.badge value instead
   of its type colour. Reading --badge-type-background FIRST -- a name the resolver never emits --
   lets the per-type rules below actually take effect; --badge-background stays only as the fallback
   for the untyped/legacy case, same shape as .variant-outlined above.
   #10567 triad round 6 (ultra-r5 survivor badge-blast-2): the base rule's `border: 1px solid
   var(--badge-border, transparent)` resolves --badge-border against the resolver's unconditionally
   inlined `#000000` (border.badge) for every badge -- filled included, since no `.variant-filled`
   rule ever overrode it. Before this fix that inline black ring sat on the resolver's own white
   fallback fill and read as an outlined-neutral badge; now that filled badges paint their real type
   colour, the SAME black ring would wrap every one of them regardless of type. Overriding the
   border-color LONGHAND directly (not another --badge-*-border custom property, which the inline
   style would just as unconditionally beat) removes it for every filled type -- the same "borderless
   fill" shape `.variant-subtle` already declares via `border: none` below, for the identical
   underlying reason. */
.ui-badge-wrapper.variant-filled {
    background: var(--badge-type-background, var(--badge-background, var(--meb-surface-card)));
    border-color: transparent;
}

/* #10567 triad round 7 (parallel ultra-review finding badge-and-theme-3): the transparent border
   above is correct for the accent-filled types (success/warning/error/info) -- their own vivid
   background supplies the visible boundary -- but filled Neutral's background is
   --meb-surface-input-filled (#f5f5f5), a near-white fill on the near-white surface.card (#ffffff)
   card behind it (~1.09:1), so the transparent border left it a pale, boundary-less blob. Restoring a
   real border-color here (an existing token, not a new one) keeps filled Neutral legible as a badge
   without reintroducing the resolver-inlined black ring the round-6 fix removed. */
.ui-badge-wrapper.variant-filled.type-neutral {
    border-color: var(--meb-border-subtle);
}

/* --- Variant: Subtle --- */

.ui-badge-wrapper.variant-subtle {
    background: var(--badge-background-subtle, var(--meb-surface-input-filled));
    border: none;
}

/* --- Variant: Outlined --- */

/* #10567 triad round 4 (ultra-r3 survivor shared-primitive-blast-1): Badge.razor.cs inlines the
   token resolver's output as a `style` attribute on this element, and that resolver ALWAYS emits a
   `--badge-border` custom property (falling back to the generic border.badge token when no
   type-specific one exists, which it never does for badge). An inline declaration of a custom
   property beats a class-selector declaration of the SAME property regardless of selector
   specificity, so a `.variant-outlined.type-*` rule that sets `--badge-border` is permanently dead
   code -- it never reaches the DOM. Reading `--badge-type-border` FIRST -- a name the resolver never
   emits -- lets the per-type rules below actually take effect; `--badge-border` stays only as the
   fallback for the untyped/legacy case. */
.ui-badge-wrapper.variant-outlined {
    background: transparent;
    border: 1px solid var(--badge-type-border, var(--badge-border, var(--meb-border-subtle)));
}

/* --- Type: Neutral --- */

.ui-badge-wrapper.type-neutral {
    --badge-type-background: var(--meb-surface-input-filled);
    --badge-text: var(--meb-text-default);
}

/* --- Type: Success --- */

/* #10567 triad round 6 (known finding, verified against theme-default.css's real token values):
   round 5 made .type-success's --badge-type-background actually reach the DOM for the first time
   (see the .variant-filled comment above) -- before that fix this rule was as dead as .type-warning's
   was pre-round-3, so --meb-text-inverse (white) on --meb-accent-success (#1be777) was never actually
   painted. It is now, at ~1.65:1, failing WCAG 1.4.3's 4.5:1. --meb-text-default clears it at ~9.3:1
   (BadgeFilledAndOutlinedContrastTests), the same fix shape as .type-warning above -- the accent
   stays the background/border signal, not the text. */
.ui-badge-wrapper.type-success {
    --badge-type-background: var(--meb-accent-success);
    --badge-text: var(--meb-text-default);
}

/* --- Type: Warning --- */

/* #10567 triad round 3 (ultra-r2 a11y-4): --meb-accent-warning (#f5b62e) is a mid-lightness amber --
   --meb-text-inverse (white) on it measures ~1.81:1, failing WCAG 1.4.3 (4.5:1). --meb-text-default
   clears it (the outlined/subtle rules below have the identical issue against a WHITE/transparent
   background, same fix). Amber stays the background/border/tint signal; it is no longer asked to
   double as legible text.
   #10567 triad round 5 (hostile lens, Major 2): --badge-background here was dead code (see the
   .variant-filled rule above) -- renamed to --badge-type-background, the resolver-safe name, so a
   filled Warning badge actually renders amber for the first time. */
.ui-badge-wrapper.type-warning {
    --badge-type-background: var(--meb-accent-warning);
    --badge-text: var(--meb-text-default);
}

/* --- Type: Error --- */

/* #10567 triad round 6 (known finding): same round-5 exposure as .type-success above --
   --meb-text-inverse (white) on --meb-accent-danger (#ff3d3d) is ~3.51:1, failing 4.5:1. Unlike
   Success/Warning, --meb-text-default does NOT clear it here either (#2b2418 on #ff3d3d measures
   ~4.38:1, computed from the real theme-default.css token values -- just short of AA). No existing
   text token pairs at >= 4.5:1 against this background except a near-black one already governed
   elsewhere in the theme: --meb-button-info-foreground (#000000, the foreground already paired with
   the info BUTTON's own fill) clears every accent in this file (danger ~5.99:1, info ~4.93:1,
   success/warning comfortably higher), so it is reused here rather than inventing a new token --
   picking the closest existing compliant pairing per the token-system rule (no raw hex, no
   page-local bridge token) instead of a `--meb-text-inverse` that fails. */
.ui-badge-wrapper.type-error {
    --badge-type-background: var(--meb-accent-danger);
    --badge-text: var(--meb-button-info-foreground);
}

/* --- Type: Info --- */

/* #10567 triad round 6 (known finding): --meb-text-inverse on --meb-accent-info (#2e74f5) is ~4.26:1
   and --meb-text-default is ~3.61:1 -- both fail 4.5:1 against this specific background (computed
   from the real theme-default.css token values). Same reused-token fix as .type-error above:
   --meb-button-info-foreground (#000000) is the only existing text token that clears AA here
   (~4.93:1). */
.ui-badge-wrapper.type-info {
    --badge-type-background: var(--meb-accent-info);
    --badge-text: var(--meb-button-info-foreground);
}

/* --- Outlined types: inherit type color for border, keep transparent bg --- */

/* #10567 triad round 6 (known finding, extended contrast test): --meb-accent-success as TEXT on the
   white/transparent card background is the identical pre-round-3 defect .type-warning's outlined
   rule already had (~1.65:1) -- never caught for Success because ReportedMarker (the only production
   Badge consumer) is Warning-typed. --meb-text-default clears it (~15.3:1 against white); the border
   stays the accent colour as the visible state signal, same split as outlined Warning above. */
.ui-badge-wrapper.variant-outlined.type-success {
    --badge-type-border: var(--meb-accent-success);
    --badge-text: var(--meb-text-default);
    background: transparent;
}

.ui-badge-wrapper.variant-outlined.type-warning {
    /* #10567 triad round 3 (ultra-r2 a11y-4): --meb-accent-warning text on the white/transparent
       card background measures ~1.81:1, failing WCAG 1.4.3 -- see the .type-warning rule above for
       the full note; text uses --meb-text-default.
       #10567 triad round 4 (ultra-r3 shared-primitive-blast-1): the outline is decorative
       reinforcement only, not a state carrier on its own -- amber #f5b62e on the white/transparent
       card background is ~1.81:1, below WCAG 1.4.11's 3:1 minimum for non-text UI components, so an
       amber outline could never be an AA-safe way to signal "warning" by itself. ReportedMarker's
       visible label text ("Reported"/"Reviewed") is what actually carries the state; --badge-type-
       border (not the resolver-clobbered --badge-border, see the .variant-outlined rule above) just
       lets the outline colour differ at all for a sighted user who isn't relying on it. */
    --badge-type-border: var(--meb-accent-warning);
    --badge-text: var(--meb-text-default);
    background: transparent;
}

/* #10567 triad round 6 (known finding, extended contrast test): same pre-existing defect as outlined
   Success above -- --meb-accent-danger as text on the white/transparent card is ~3.51:1.
   --meb-text-default clears it easily against the near-white card (unlike the FILLED danger
   background above, where the card colour is not in play). */
.ui-badge-wrapper.variant-outlined.type-error {
    --badge-type-border: var(--meb-accent-danger);
    --badge-text: var(--meb-text-default);
    background: transparent;
}

/* #10567 triad round 6 (known finding, extended contrast test): same defect -- --meb-accent-info as
   text on the white/transparent card is ~4.26:1, failing 4.5:1. --meb-text-default clears it. */
.ui-badge-wrapper.variant-outlined.type-info {
    --badge-type-border: var(--meb-accent-info);
    --badge-text: var(--meb-text-default);
    background: transparent;
}

.ui-badge-wrapper.variant-outlined.type-neutral {
    --badge-type-border: var(--meb-border-subtle);
    --badge-text: var(--meb-text-default);
    background: transparent;
}

/* --- Subtle types: lighter tinted backgrounds --- */

.ui-badge-wrapper.variant-subtle.type-success {
    --badge-background-subtle: color-mix(in srgb, var(--meb-accent-success) 15%, transparent);
    --badge-text: var(--meb-accent-success);
}

.ui-badge-wrapper.variant-subtle.type-warning {
    /* #10567 triad round 3 (ultra-r2 a11y-4): same fix as the outlined/filled warning rules -- the
       15%-tinted background is still close enough to white that --meb-accent-warning text fails AA. */
    --badge-background-subtle: color-mix(in srgb, var(--meb-accent-warning) 15%, transparent);
    --badge-text: var(--meb-text-default);
}

.ui-badge-wrapper.variant-subtle.type-error {
    --badge-background-subtle: color-mix(in srgb, var(--meb-accent-danger) 15%, transparent);
    --badge-text: var(--meb-accent-danger);
}

.ui-badge-wrapper.variant-subtle.type-info {
    --badge-background-subtle: color-mix(in srgb, var(--meb-accent-info) 15%, transparent);
    --badge-text: var(--meb-accent-info);
}

.ui-badge-wrapper.variant-subtle.type-neutral {
    --badge-background-subtle: color-mix(in srgb, var(--meb-text-default) 6%, transparent);
    --badge-text: var(--meb-text-default);
}