/* FACELIFT-198 — signed-out journey refresh.
 *
 * ONE file, linked last in Views/Shared/_LoginLayout.cshtml, reaching all 23 views on that layout:
 * Home (Index, ForgotPassword, ForgotUser, ResetPassword, ChangePassword, Confirm, KeyExpired,
 * ExistingSession, ApproveByEmail, DealOfferByEmail), Onboard (8), PasswordSetup (2),
 * SecurityQuestions (2) and TwoFactorAuthentication/VerifyUser.
 *
 * The layout itself carries no chrome — it is 92 lines of <head> and then @RenderBody(). Every view
 * hand-rolls its markup. What they DO share is the Bootstrap 3 class vocabulary, and `.login-box`
 * plus `.panel` appear in every one, which is why hooking those reaches the whole journey from here.
 *
 * ── WHY THERE IS NO COLOUR IN THIS FILE ───────────────────────────────────────────────────────────
 *
 * This login is themed. `HomeController.SetThemeCss()` resolves one of SEVENTEEN named Kendo themes
 * — RED, BLUE, GREEN, BLACK, BLUEOPAL, BOOTSTRAP, FIORI, FLAT, HIGHCONTRAST, MATERIAL, MATERIALBLACK,
 * METRO, METROBLACK, MOONLIGHT, MOUNTAIN, SILVER, UNIFORM — picked per user, then client, then
 * company (Users.ColorScheme -> ClientSetup.DefaultColorScheme -> Company.DefaultColorScheme).
 * Their accents genuinely differ: default #244061, red #880024, green #005b00.
 *
 * This file loads AFTER those themes, so anything it declares wins. That makes restraint the whole
 * design: it owns what no theme expresses — rhythm, radius, elevation, control geometry, focus,
 * typography, small-screen behaviour — and never repaints a themed surface. Every one of the 17
 * improves and none is overridden.
 *
 * So: no brand hex, no `background-color` on a button, no `color` on a themed control. If an accent
 * is ever wanted here, it has to come from the theme rather than from this file. Adding navy here
 * would silently reskin sixteen customers who did not ask for it.
 *
 * Neutrals ARE fair game — a card is white and a hairline is grey under every one of the 17.
 *
 * ── CORRECTED 2026-10-19 (FACELIFT-430): that rule holds for this FILE, not for every view ───────
 *
 * The paragraph above is right about the journey as a whole and overstates its case for the login
 * page itself. `HomeController.Index` GET never calls `SetThemeCss` and never reads
 * `GlobalVariables.ColorSchema` (HomeController.cs:66-127) — every ColorSchema assignment in the app
 * happens AFTER identity is known (Users.ColorScheme, else ClientSetup, else Company). There is no
 * user at the login page, so there is no per-customer theme there to reskin.
 *
 * Where the 17 themes genuinely do reach this journey is the onboarding and verify screens, because
 * `OnboardController` sets ColorSchema explicitly. Those are the views this file's restraint
 * protects.
 *
 * Direction D's navy therefore lives in a SEPARATE file, `login-v3.css`, loaded after this one and
 * scoped under `.login-v3` — a class only Home/Index carries. This file stays colourless and keeps
 * reaching all 23 views unchanged. Don't merge the two: the separation is what makes D's scope
 * legible and its rollback one deleted `<link>`.
 *
 * ── NO CUSTOM PROPERTIES ─────────────────────────────────────────────────────────────────────────
 *
 * Deliberate. `_LoginLayout` still ships html5shiv and respond.js behind IE conditional comments.
 * That is almost certainly dead weight in 2026, but until someone confirms no customer is on IE,
 * `var()` here would fail silently and unevenly. Plain values cost nothing at this size.
 */

/* ── Rhythm ───────────────────────────────────────────────────────────────────────────────────── */

/* The card sat at `col-md-9` — 75% of a desktop viewport for a two-field form — and the views pushed
   it down with an inline `margin-top: 50px`. Capping the measure is the single biggest change here;
   centring stays the grid's job via `.col-centered`. */
/* `Common.min.css` already gives `.login-box` three things this supersedes:
     box-shadow: 10px 10px 5px rgba(0,0,0,.5)   a hard, offset, 50%-black drop shadow
     background-color: #fff                      a surface, which `.panel` now owns
     min-height: 380px                           a floor that leaves short views with dead space
   All three are neutralised here so the card is drawn once, on `.panel`. Without this the old
   shadow renders UNDERNEATH the new one and the card gets two. (`.col-centered` next to it already
   sets `float: none; margin: 0 auto`, so centring needs nothing from this file.) */
/* NO max-width, deliberately — the card is `col-md-9` centred by `.col-centered`, which is exactly
   what production serves today (~877px of a 1170px container).

   This file used to cap it at 560px, and then at 820px for the two-column views. Both are reverted
   until the new design is approved: the brief is to keep production's MEASUREMENTS — box width,
   column split, button layout, type size and placement — and change only the treatment. So the
   geometry below is Bootstrap's and production's; what this file still owns is radius, elevation,
   focus, validation and typography.

   Don't reintroduce a cap without the approval: the 560px measure also forced the inner `col-md-6`
   to full width, which is what collapsed the two columns into one. */
.login-box {
    margin-top: 48px;
    margin-bottom: 48px;
    background-color: transparent;
    box-shadow: none;
    min-height: 0;
}

/* `.login-box-wide` is kept as a no-op hook rather than deleted.

   Twelve views carry the class, and the two-column geometry it used to provide is now simply what
   Bootstrap does on its own: without a cap on `.login-box`, an inner `col-md-6` is 50% of ~877px,
   which is production's layout. So the class costs nothing, and it is the hook to reach for if the
   approved design wants a different measure for those twelve. */

/* NOTHING here resizes the inner columns, and that is the point.

   This used to force every `col-md-6` / `col-md-4` / `col-md-8` in the panel body to full width,
   because a 560px card made a half-column 265px — a cramped form beside an empty half. With the cap
   gone that reasoning goes with it: Bootstrap's own 50% is right again, and the form sits beside the
   welcome message exactly as production has it.

   Reinstating a width here is how the columns collapsed last time. If a cap comes back with the
   approved design, this rule comes back WITH it, not before. */

.login-box .panel {
    border: 0;
    border-radius: 10px;
    box-shadow: 0 1px 2px rgba(16, 24, 40, .06), 0 8px 24px rgba(16, 24, 40, .08);
    overflow: hidden;
}

.login-box .panel-body {
    padding: 32px 32px 28px;
}

/* ── Typography ───────────────────────────────────────────────────────────────────────────────── */

/* Bootstrap 3 ships "Helvetica Neue", Helvetica, Arial — which on Windows resolves to Arial and is
   the single most dated thing about these screens. A system stack is brand-neutral and costs no
   request. Scoped to the card rather than set on `body`, so nothing else on the host app moves. */
.login-box,
.login-box .form-control,
.login-box .btn {
    font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", Arial, sans-serif;
    -webkit-font-smoothing: antialiased;
}

.login-box h1,
.login-box h2,
.login-box h3,
.login-box h4 {
    font-weight: 600;
    letter-spacing: -.01em;
    margin-top: 0;
}

/* The masthead. NO height cap, deliberately — only the spacing below it is this file's business.

   `Model.LogoURL` is per customer and is NOT always a small mark: production's is a full-width
   banner, roughly 765x103 inside an 877px card. This rule used to cap it at `max-height: 64px` with
   `width: auto`, which shrank that banner to about a third of its area and re-centred it as though
   it were a logo. That is a measurement change, and measurements are what the brief holds steady.

   Bootstrap's own `.img-responsive` (`max-width: 100%; height: auto`) already stops an oversized
   image escaping the card, which is exactly what production relies on. `margin: 0 auto` keeps a
   genuinely small logo centred; the 8px is the gap the views used to carry inline. */
.login-box .panel-body > .text-center > img,
.login-box .panel-body > .col-md-12 > a > img {
    margin: 0 auto 8px;
}

/* ── Form controls ────────────────────────────────────────────────────────────────────────────── */

.login-box .form-control {
    height: 44px; /* also the touch-target minimum this app uses elsewhere */
    padding: 10px 14px;
    font-size: 15px;
    border-radius: 8px;
    border-color: #d5d8dd;
    box-shadow: none;
    transition: border-color .15s ease-in-out, box-shadow .15s ease-in-out;
}

.login-box .form-control::-moz-placeholder { color: #8b9099; opacity: 1; }
.login-box .form-control:-ms-input-placeholder { color: #8b9099; }
.login-box .form-control::-webkit-input-placeholder { color: #8b9099; }

/* Focus is drawn in a NEUTRAL on purpose: a themed ring would need a themed colour, which this file
   has none of. A grey ring plus a darker border reads as focus under every one of the 17 themes,
   where a navy one would be wrong on sixteen of them. */
.login-box .form-control:focus {
    border-color: #9aa0a8;
    box-shadow: 0 0 0 3px rgba(16, 24, 40, .08);
    outline: 0;
}

/* The glyph gutter beside each field. Bootstrap 3 squares these off against the input; matching the
   input's radius on the outer corners is what stops the pair reading as two separate controls. */
.login-box .input-group-addon {
    min-width: 44px;
    background-color: #f5f6f8;
    border-color: #d5d8dd;
    border-radius: 8px 0 0 8px;
    color: #6b7280;
}

.login-box .input-group .form-control:first-child,
.login-box .input-group .form-control:last-child {
    border-radius: 0 8px 8px 0;
}

/* Replaces the inline `margin-bottom: 25px` the views repeat on every field wrapper. */
.login-box .input-group,
.login-box .form-group {
    margin-bottom: 20px;
}

.login-box .form-group:last-child {
    margin-bottom: 0;
}

/* ── Buttons: geometry only ───────────────────────────────────────────────────────────────────── */

/* Home/Index carried its own <style> block redefining `.btn-lg` with six padding declarations, three
   of which overrode the shorthand two lines above them. That block is removed; this is its
   replacement, and it applies to every view rather than one.
   NOTE what is absent: no background, no border-colour, no text colour. `.btn-success` (Login) and
   `.btn-thinkware` (New User Sign On) keep whatever the active theme paints them. */
.login-box .btn {
    border-radius: 8px;
    font-weight: 600;
    letter-spacing: .01em;
    transition: filter .15s ease-in-out, box-shadow .15s ease-in-out;
}

.login-box .btn-lg {
    min-height: 44px;
    padding: 11px 24px;
    font-size: 16px;
    line-height: 20px;
    margin: 0;
}

/* Darkening by filter rather than by colour keeps the hover state theme-agnostic — it works on
   #244061, #880024 and #005b00 alike without this file knowing which one it is. */
.login-box .btn:hover,
.login-box .btn:focus {
    filter: brightness(.94);
}

.login-box .btn:active {
    filter: brightness(.88);
}

.login-box .btn:focus {
    box-shadow: 0 0 0 3px rgba(16, 24, 40, .12);
    outline: 0;
}

/* Nothing here FLOATS or positions the action row, and that is the point. It used to: a `margin-left`
   between the two buttons, and a `@media (max-width: 767px)` block that undid `.pull-right` with
   `float: none !important` and forced the buttons to `width: 100%`.
   Both are gone. The views use the GRID instead - `col-xs-12 col-sm-6` with `btn-block` - which floats
   at >=768px and stacks full-width below, because that is Bootstrap 3's only responsive float. There is
   no `.float-sm-right` in 3.3.5; `.pull-right` is unconditional and `!important`, which is exactly why
   it needed a media query to fight it.
   The bug that prompted this: the desktop `+ .btn` margin rule out-specificity'd the phone rule that
   zeroed it, so the two stacked buttons sat 8px out of line with each other - equal widths, different
   left edges, which is why a measurement of widths alone had read clean. */

/* The action row is right-aligned with buttons at their natural widths, which is what production
   serves and what the brief asks to keep until the new design is approved.

   `.controls` carries `text-right`, so the buttons are inline-block and sit at the right edge of
   the form column in source order - New User Sign On, then Login. No `btn-block`, no equal widths,
   no grid columns: the 203/203 pair those produced is a change to the LAYOUT, and layout is the
   thing being held steady.

   `text-right` rather than `.pull-right`: it needs no media query to undo, which is the whole
   lesson of the block above. Below 768px the buttons wrap and stay right-aligned, the same as
   production. */
.login-box .panel-body .controls .btn + .btn {
    margin-left: 8px;
}

/* Wrapping is where `margin: 0` on .btn-lg bites: two buttons on separate lines would touch. A
   bottom margin costs nothing on one line and saves the wrapped case. */
.login-box .panel-body .controls .btn-lg {
    margin-bottom: 8px;
}

/* `.btn-md` at 14px, which is what production renders — NOT the 16px `Common.min.css` declares for
   the class.

   That is worth stating because it looks like a mistake. `Common.min.css` has
   `.btn-md{padding:6px 12px;font-size:16px}`, and the harness, loading the same file in the same
   order, computes 16px. Production does not: measured off a screenshot of
   `/Onboard/EntryPoint`, its three choice buttons sit at 38px and 30px apart and stand 51px tall,
   and 14px reproduces all three numbers exactly while 16px gives 18/3 and 57. Three independent
   measurements agreeing is not a coincidence — something on a deployed host resolves these to
   Bootstrap's own 14px. WORTH CONFIRMING on a real host; until then this matches what employees
   actually see.

   At 16px the labels ran 235/251/272 against gutters of 30, so the second and third options
   overlapped by 2px. Letter-spacing is dropped with it. Weight is left alone — measured, 600 and
   500 render identically here, so it buys nothing either way and the treatment keeps its weight.

   `.btn-lg` is untouched: the login's action row has the room, and that pair is what an employee
   actually looks at. */
.login-box .panel-body .btn-md {
    font-size: 14px;
    letter-spacing: normal;
}

/* 992-1199px only, and this one does NOT match production — production is broken here.

   In that band Bootstrap's container is 970px, so the card is 727px and each `col-md-4` has a
   212px content box, while `col-md-*` is still floating three across. Production's choice buttons
   measure 217/233/252 and this file's measure 209/223/241: every one of them is wider than 212, so
   two of the three overlap and the third leaves the card. At >=1200px the container jumps to
   1170px, the box to 262px, and they all fit — which is why this is invisible at a normal desktop
   size and shows up on a small laptop.

   So the buttons are allowed to shrink and wrap for that band only. Three lines there beats two
   lines overlapping, and every other width renders exactly as production does. Deliberately a
   media query rather than an unconditional `max-width`: unconditional would cap the widest button
   at >=1200px too and wrap it there, which would lose the match that is the whole point. */
@media (min-width: 992px) and (max-width: 1199px) {
    .login-box .panel-body .btn-md {
        max-width: 100%;
        white-space: normal;
    }
}

/* ── Links and secondary text ─────────────────────────────────────────────────────────────────── */

/* Link colour belongs to the theme; only the weight and underline behaviour are set here. */
.login-box a:not(.btn) {
    font-weight: 500;
}

.login-box a:not(.btn):hover,
.login-box a:not(.btn):focus {
    text-decoration: underline;
}

.login-box .help-block,
.login-box small {
    color: #6b7280;
}

/* ── Validation ───────────────────────────────────────────────────────────────────────────────── */

/* `field-validation-error` and `validation-summary-errors` are emitted by unobtrusive validation on
   most of these views. Red here is a STATUS colour, not a brand one, so it is safe under any theme —
   the same reasoning /v3 uses for keeping success green regardless of primary. */
.login-box .field-validation-error,
.login-box .validation-summary-errors {
    color: #b42318;
    font-size: 13px;
}

.login-box .validation-summary-errors ul {
    margin: 0;
    padding-left: 18px;
}

.login-box .has-error .form-control {
    border-color: #d92d20;
}

.login-box .has-error .form-control:focus {
    box-shadow: 0 0 0 3px rgba(217, 45, 32, .12);
}

/* ── Small screens ────────────────────────────────────────────────────────────────────────────── */

/* These views are `col-md-*` throughout, so below the md breakpoint everything is already full
   width — what they lack is breathing room and a card that does not touch the viewport edge. */
@media (max-width: 767px) {
    .login-box {
        margin-top: 16px;
        margin-bottom: 24px;
        padding-left: 12px;
        padding-right: 12px;
    }

    .login-box .panel-body {
        padding: 24px 20px 20px;
    }
}
