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;
}

/* AN UNPRESSED TOGGLE NEVER TAKES A FILL, FROM ANY INTERACTION (#937).

   Hover and focus may change the border, the text, or add a ring; they may not
   add the background that means "pressed".

   THE DEFECT. Bootstrap defines --bs-btn-hover-bg and --bs-btn-active-bg to the
   SAME value across the whole outline family (.btn-outline-primary sets both to
   #0d6efd), and .btn:focus-visible takes the hover background too. So an
   unpressed toggle under the pointer, or under keyboard focus, is
   pixel-identical to a pressed one — the control shows you the state you are
   trying to read, and a keyboard user tabbing a group sees every item they pass
   appear selected. Measured in Chromium against this repo's own
   bootstrap.min.css: an unpressed .btn-outline-secondary paints
   rgb(108,117,125) on hover and on :focus-visible, which is exactly
   .btn-secondary's resting fill.

   WHY IT IS HERE RATHER THAN IN A SCOPED STYLESHEET. It has been point-fixed
   three times — #350 in SegmentedChoice.razor.css, #877 in MoodLog.razor.css,
   and #937 — because each fix was scoped to the control it was found on, so the
   fourth control gets the bug for free. One rule, applying wherever a toggle is
   drawn, is the thing that stops the rediscovery.

   WHY [aria-pressed="false"] AND NOT A CLASS. That attribute is what MAKES a
   button a toggle: the ARIA button pattern requires it on one, so keying on it
   covers every toggle we have and every toggle we write, including any drawn
   with some pair of fills other than outline/solid. A toggle missing the
   attribute is out of reach here, and is also already an accessibility defect —
   UnpressedToggleFillGuardTests scans for that separately.

   THIS DOES NOT COVER the other way to draw a toggle, an input.btn-check with
   an adjacent label.btn — the day pickers on ConfigureMedications and
   ConfigureSymptoms. It does not need to. Bootstrap 5.3 guards that form itself
   (.btn-check+.btn:hover restores the resting --bs-btn-bg, and
   .btn-check:focus-visible+.btn sets no background at all), and focus lands on
   the hidden input rather than the label, so .btn:focus-visible never applies.
   Measured: those labels stay rgba(0,0,0,0) through both. The guard tests pin
   that vendored guarantee, since it is the reason we add nothing there.

   var(--bs-btn-bg) rather than `transparent`, so this restores whatever the
   button's own resting fill is — the same answer Bootstrap's btn-check rule
   gives — instead of assuming the unpressed half is an outline. */
.btn[aria-pressed="false"]:hover,
.btn[aria-pressed="false"]:focus-visible,
.btn[aria-pressed="false"]:active {
    color: var(--bs-btn-color);
    background-color: var(--bs-btn-bg);
    border-color: var(--bs-btn-border-color);
}

.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."
    }

.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;
}

/* #546: Critical severity.

   Bootstrap stops at danger, so the top of the severity ramp had been bg-dark
   — black. Green -> amber -> red is an intensity ramp the eye reads without a
   legend; black is not its next step, and a reader said so: "critical is
   black, which I guess is worse than high which is red?"

   #8b0000 is a darker red than danger (#dc3545), so Critical reads as "more of
   the same thing" rather than as a different kind of thing. It also separates
   in greyscale — relative luminance 0.05 against danger's 0.18 — which is what
   keeps the ramp legible to a colour-blind reader and in a printed report.
   Contrast against white is ~10:1 both ways, so it carries white badge text
   and works as a text colour on the page background.

   !important matches Bootstrap's own utility semantics: these sit alongside
   .bg-danger etc. and have to win the same way those do. RiskScale.ColorName
   is the only thing that emits these names; RiskScaleColourRampTests asserts
   all three selectors exist, because a missing rule renders no fill at all. */
:root {
    --moli-critical: #8b0000;
}

.bg-critical {
    background-color: var(--moli-critical) !important;
    color: #fff !important;
}

.border-critical {
    border-color: var(--moli-critical) !important;
}

.text-critical {
    color: var(--moli-critical) !important;
}

/* #966: the logging run's count line, which now carries the day the run began
   ("292 days in a row, since Nov 15, 2025").

   At 360px and up that is one line. Below it the line wraps, and the default
   greedy algorithm strands the year alone on the second — a single orphaned
   "2025" under a full line of text. `pretty` is the property CSS added for
   exactly that, and it reflows to keep the last line from being one word.

   Progressive enhancement on purpose: engines without it (Firefox, as of
   writing) lay the line out as they do today, which is the rendering this
   replaces rather than a broken one. Nothing depends on it being applied. */
.logging-run-count {
    text-wrap: pretty;
}