html, body {
    font-family: 'Helvetica Neue', Helvetica, Arial, sans-serif;
}

a, .btn-link {
    color: #006bb7;
}

.btn-primary {
    color: #fff;
    background-color: #1b6ec2;
    border-color: #1861ac;
}

.btn:focus, .btn:active:focus, .btn-link.nav-link:focus, .form-control:focus, .form-check-input:focus {
  box-shadow: 0 0 0 0.1rem white, 0 0 0 0.25rem #258cfb;
}

.content {
    padding-top: 1.1rem;
}

h1:focus {
    outline: none;
}

.valid.modified:not([type=checkbox]) {
    outline: 1px solid #26b050;
}

.invalid {
    outline: 1px solid #e50000;
}

.validation-message {
    color: #e50000;
}

.blazor-error-boundary {
    background: url(data:image/svg+xml;base64,PHN2ZyB3aWR0aD0iNTYiIGhlaWdodD0iNDkiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyIgeG1sbnM6eGxpbms9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGxpbmsiIG92ZXJmbG93PSJoaWRkZW4iPjxkZWZzPjxjbGlwUGF0aCBpZD0iY2xpcDAiPjxyZWN0IHg9IjIzNSIgeT0iNTEiIHdpZHRoPSI1NiIgaGVpZ2h0PSI0OSIvPjwvY2xpcFBhdGg+PC9kZWZzPjxnIGNsaXAtcGF0aD0idXJsKCNjbGlwMCkiIHRyYW5zZm9ybT0idHJhbnNsYXRlKC0yMzUgLTUxKSI+PHBhdGggZD0iTTI2My41MDYgNTFDMjY0LjcxNyA1MSAyNjUuODEzIDUxLjQ4MzcgMjY2LjYwNiA1Mi4yNjU4TDI2Ny4wNTIgNTIuNzk4NyAyNjcuNTM5IDUzLjYyODMgMjkwLjE4NSA5Mi4xODMxIDI5MC41NDUgOTIuNzk1IDI5MC42NTYgOTIuOTk2QzI5MC44NzcgOTMuNTEzIDI5MSA5NC4wODE1IDI5MSA5NC42NzgyIDI5MSA5Ny4wNjUxIDI4OS4wMzggOTkgMjg2LjYxNyA5OUwyNDAuMzgzIDk5QzIzNy45NjMgOTkgMjM2IDk3LjA2NTEgMjM2IDk0LjY3ODIgMjM2IDk0LjM3OTkgMjM2LjAzMSA5NC4wODg2IDIzNi4wODkgOTMuODA3MkwyMzYuMzM4IDkzLjAxNjIgMjM2Ljg1OCA5Mi4xMzE0IDI1OS40NzMgNTMuNjI5NCAyNTkuOTYxIDUyLjc5ODUgMjYwLjQwNyA1Mi4yNjU4QzI2MS4yIDUxLjQ4MzcgMjYyLjI5NiA1MSAyNjMuNTA2IDUxWk0yNjMuNTg2IDY2LjAxODNDMjYwLjczNyA2Ni4wMTgzIDI1OS4zMTMgNjcuMTI0NSAyNTkuMzEzIDY5LjMzNyAyNTkuMzEzIDY5LjYxMDIgMjU5LjMzMiA2OS44NjA4IDI1OS4zNzEgNzAuMDg4N0wyNjEuNzk1IDg0LjAxNjEgMjY1LjM4IDg0LjAxNjEgMjY3LjgyMSA2OS43NDc1QzI2Ny44NiA2OS43MzA5IDI2Ny44NzkgNjkuNTg3NyAyNjcuODc5IDY5LjMxNzkgMjY3Ljg3OSA2Ny4xMTgyIDI2Ni40NDggNjYuMDE4MyAyNjMuNTg2IDY2LjAxODNaTTI2My41NzYgODYuMDU0N0MyNjEuMDQ5IDg2LjA1NDcgMjU5Ljc4NiA4Ny4zMDA1IDI1OS43ODYgODkuNzkyMSAyNTkuNzg2IDkyLjI4MzcgMjYxLjA0OSA5My41Mjk1IDI2My41NzYgOTMuNTI5NSAyNjYuMTE2IDkzLjUyOTUgMjY3LjM4NyA5Mi4yODM3IDI2Ny4zODcgODkuNzkyMSAyNjcuMzg3IDg3LjMwMDUgMjY2LjExNiA4Ni4wNTQ3IDI2My41NzYgODYuMDU0N1oiIGZpbGw9IiNGRkU1MDAiIGZpbGwtcnVsZT0iZXZlbm9kZCIvPjwvZz48L3N2Zz4=) no-repeat 1rem/1.8rem, #b32121;
    padding: 1rem 1rem 1rem 3.7rem;
    color: white;
}

    .blazor-error-boundary::after {
        content: "An error has occurred."
    }

/* Blazor's unhandled-error bar. This MUST live in a global stylesheet, not a component-scoped
   *.razor.css: the element is a framework-owned singleton that blazor.web.js finds by id, and it is
   rendered separately by BOTH MainLayout and CheckoutLayout. Scoped CSS is rewritten to
   `#blazor-error-ui[b-<hash>]`, so a rule in one layout's stylesheet cannot match the other layout's
   copy — which left `display: none` unapplied on checkout pages and the bar permanently visible. */
#blazor-error-ui {
    color-scheme: light only;
    background: lightyellow;
    bottom: 0;
    box-shadow: 0 -1px 2px rgba(0, 0, 0, 0.2);
    box-sizing: border-box;
    display: none;
    left: 0;
    padding: 0.6rem 1.25rem 0.7rem 1.25rem;
    position: fixed;
    width: 100%;
    z-index: 1000;
}

    #blazor-error-ui .dismiss {
        cursor: pointer;
        position: absolute;
        right: 0.75rem;
        top: 0.5rem;
    }

.darker-border-checkbox.form-check-input {
    border-color: #929292;
}

.form-floating > .form-control-plaintext::placeholder, .form-floating > .form-control::placeholder {
    color: var(--bs-secondary-color);
    text-align: end;
}

.form-floating > .form-control-plaintext:focus::placeholder, .form-floating > .form-control:focus::placeholder {
    text-align: start;
}

/* ==========================================================================================
   Colour mode
   ==========================================================================================
   The switch itself lives in swan-theme.js (which sheet applies) — these are the few places the
   Blazor project template hardcoded a light-only colour, plus the toggle button's own styling.
   Global on purpose: ThemeToggle is its own component, so a sheet scoped to whatever hosts it could
   reach neither the button nor the icons FeatherIcon renders inside it.

   The button now renders as a row in the sidebar's footer, and NavMenu.razor.css's .sidebar-footer-row
   rules out-specify the padding and colour below. What still comes from here is the button reset
   (background/border/cursor), the focus ring, and — the part that matters — the two-state switching. */

.theme-toggle {
    background: none;
    border: 0;
    padding: 0.5rem 0.65rem;
    color: var(--bs-secondary-color);
    line-height: 1;
    cursor: pointer;
}

.theme-toggle:hover {
    color: var(--bs-body-color);
}

.theme-toggle:focus-visible {
    outline: 2px solid var(--bs-primary);
    outline-offset: 2px;
}

.theme-toggle-icon {
    width: 18px;
    height: 18px;
    vertical-align: middle;
}

/* Show only the icon AND label for the mode you can switch TO, so the row reads as an action rather than as
   a statement of the current mode. Both states ship in the markup and this hides one — which is why nothing
   in ThemeToggle.razor may set `display` on the .theme-toggle-moon/.theme-toggle-sun elements: at (0,2,1)
   this rule loses to almost any class-based `display`, and both states would show at once. */
html[data-bs-theme="dark"] .theme-toggle-moon,
html:not([data-bs-theme="dark"]) .theme-toggle-sun {
    display: none;
}

/* Semantic ink/tint palette.
   ---------------------------------------------------------------------------------------------
   Bootstrap's own `*-text-emphasis` / `*-bg-subtle` families CANNOT be used for this: AppStack's
   dark build never dark-ified them, so under dark.css they are still light-ground values
   (--bs-warning-text-emphasis is #523816, a near-black brown, against a #202634 page). Anything
   styled with them is unreadable in dark mode. These tokens are the replacement — every value is
   contrast-checked against the ground it appears on, and they are the ONLY semantic text/tint
   colours app CSS should reach for.

   Base `--bs-warning` / `--bs-success` are fine in both modes and stay in use for solid marks
   (gauge ticks, severity stripes): AppStack ships them vivid (#e5a54b / #4bbf73).

   `--swan-surface` is the "raised above the page ground" colour — what a .card gets. AppStack only
   defines --bs-card-bg inside the .card rule itself, so chrome that has to match a card without
   being one (the checkout header bar) cannot read it and needs this token instead. The page ground
   underneath is plain `--bs-body-bg`, which both builds define correctly. */
:root {
    --swan-surface: #fff;        /* = AppStack light's --bs-card-bg */
    --swan-surface-line: #e6e9f0;
    --swan-ok-ink: #16603c;      /* ~7:1 on white */
    --swan-ok-tint: #dcefe5;
    --swan-ok-line: #9fd3b4;
    --swan-warn-ink: #8a4a12;    /* ~7.5:1 on white */
    --swan-warn-tint: #f6e7d8;
    --swan-warn-line: #e3b782;
    --swan-info-ink: #0c405a;
    --swan-info-tint: #d3e8f6;
    --swan-info-line: #a4d1ea;
    --swan-accent-ink: #1f5fd0;  /* #2f6fed measured 4.31:1 — under AA on the page ground */
    --swan-code-ink: #9c3f6a;
}

html[data-bs-theme="dark"] {
    --swan-surface: #293042;     /* = AppStack dark's --bs-card-bg */
    --swan-surface-line: #3e4555;
    --swan-ok-ink: #7ddba4;      /* ~9:1 on the #202634 page */
    --swan-ok-tint: #14321f;
    --swan-ok-line: #245c37;
    --swan-warn-ink: #e6b566;    /* ~7:1 */
    --swan-warn-tint: #37290f;
    --swan-warn-line: #6b4f1c;
    --swan-info-ink: #7fc8ec;
    --swan-info-tint: #12303f;
    --swan-info-line: #245b74;
    --swan-accent-ink: #6ea8fe;
    --swan-code-ink: #e685ad;    /* --bs-code-color's #e83e8c glares on the dark ground */
}

/* Content links only. The sidebar keeps its own dark ground in BOTH modes, so its links and brand
   must not follow the page link colour — a blanket `a` rule here painted them blue. */
html[data-bs-theme="dark"] :is(main, .main, .content, .card, .modal) a:not(.btn):not(.sidebar-link),
html[data-bs-theme="dark"] .btn-link {
    color: var(--swan-accent-ink);
}

html[data-bs-theme="dark"] code {
    color: var(--swan-code-ink);
}

html[data-bs-theme="dark"] .btn:focus,
html[data-bs-theme="dark"] .btn:active:focus,
html[data-bs-theme="dark"] .btn-link.nav-link:focus,
html[data-bs-theme="dark"] .form-control:focus,
html[data-bs-theme="dark"] .form-check-input:focus {
    box-shadow: 0 0 0 0.1rem var(--bs-body-bg), 0 0 0 0.25rem #258cfb;
}

html[data-bs-theme="dark"] .validation-message,
html[data-bs-theme="dark"] .invalid {
    /* #e50000 fails contrast on a dark ground. */
    color: #ff8a84;
}

html[data-bs-theme="dark"] .invalid {
    outline-color: #ff8a84;
}

/* ==========================================================================================
   Centred sign-in shell — /account/login
   ==========================================================================================
   The page used to carry `min-height: 100vh; background: #f5f7fb` inline (so did the since-removed
   /auth/trusted-login hand-off, which shared this class). The literal ground stayed pale under
   dark.css while the card went dark, so the card floated on a light void. No background of its own on purpose —
   the page ground belongs to the layout (.content), so this follows the colour mode for free.

   The 100vh went with it: this sits INSIDE .content, which already starts below the ~63px top bar
   and adds 1.5rem of padding top and bottom, so a full viewport height overflowed by just over
   7rem and put a scrollbar on a page that has nothing to scroll — enough that focusing the email
   field scrolled the top bar out of sight. 7rem is that chrome, so the shell fills what is left. */

.auth-shell {
    display: flex;
    align-items: center;
    justify-content: center;
    min-height: calc(100vh - 7rem);
}

.auth-card {
    width: 100%;
    max-width: 420px;
}
/* ==========================================================================================
   Write-only secret inputs — admin config, NOT sign-in
   ==========================================================================================
   Processor passwords, API keys and webhook secrets are `type="text"` masked by CSS rather than
   `type="password"`. That looks backwards, so: a password field is exactly what makes a browser's
   password manager classify the surrounding form as a login form. Having done so it fills the
   nearest preceding text input with the saved username and the password field with the saved
   password — which put the operator's own `lgadmin@…` address into "Payment Processor Username"
   and their admin password into "Payment Processor API Key". `autocomplete="off"` and
   `autocomplete="new-password"` were both ignored; they are advisory, and Chrome overrides them
   when its own heuristics disagree. Removing the password field removes the signal itself, which
   is the only part of this that a browser cannot override.

   The cost is narrow because these fields are write-only: every one of them renders BLANK (a
   stored secret is never shown back), so masking only ever covers what is being typed right now,
   never anything at rest.

   -webkit-text-security covers Chromium and WebKit. Firefox has never shipped it or an equivalent,
   so a secret being typed there shows in clear — the trade is deliberate: a value visible while
   an operator types it is a smaller problem than an admin credential silently saved as a
   merchant's processor password. Revisit if the standard `input-security` property ships.

   The password field on the real sign-in form is untouched and stays `type="password"` with
   `autocomplete="current-password"` — that form IS a login, and the password manager should work
   there. Marking it correctly is also what stops the heuristics reaching for other forms. */

.secret-input {
    -webkit-text-security: disc;
}