/* FACELIFT-430 — Direction D for the signed-out journey.
 *
 * Linked AFTER login-refresh.css in Views/Shared/_LoginLayout.cshtml, and scoped entirely under
 * `.login-v3`. Only Views/Home/Index.cshtml carries that class today; the other 22 views on this
 * layout are untouched and keep login-refresh.css's treatment exactly as it is.
 *
 * ── WHY THIS FILE CARRIES COLOUR WHEN login-refresh.css DOES NOT ─────────────────────────────────
 *
 * That file's header says adding navy "would silently reskin sixteen customers who did not ask for
 * it." That is true of the journey as a whole and NOT true of this page.
 *
 * `HomeController.Index` GET never calls `SetThemeCss` and never reads `GlobalVariables.ColorSchema`
 * (HomeController.cs:66-127). Every ColorSchema assignment in the app is post-identification —
 * Users.ColorScheme once a user exists, else client, else company. There is no user at the login
 * page, so there is no per-customer theme to override here. The themed screens in this journey are
 * the onboarding/verify ones, where OnboardController sets ColorSchema explicitly, and none of them
 * is in this file's scope.
 *
 * One caveat that shapes the selectors below: `GlobalVariables.Css1` is a STATIC. In a warm app pool
 * it can still hold whatever the last authenticated request set, so this page may load any of the 17
 * theme sheets rather than thinkware-default. Nothing here may ASSUME the default theme — every rule
 * that matters is scoped under `.login-v3` so it outweighs the theme regardless of which one loaded.
 *
 * Kept from login-refresh.css, deliberately: NO CSS CUSTOM PROPERTIES. `_LoginLayout` still ships
 * html5shiv and respond.js, and until someone confirms no customer is on IE, `var()` would fail
 * silently and unevenly. Plain values cost nothing at this size.
 *
 * ── THE SHAPE ────────────────────────────────────────────────────────────────────────────────────
 *
 * D and C are ONE page, not two. Above 992px (Bootstrap's only breakpoint in this journey) the
 * primary aside and the white form sit side by side — D. Below it they stack and the welcome copy
 * demotes beneath the form — C. Building them as separate layouts would guarantee they drift.
 */

/* ── The split ───────────────────────────────────────────────────────────────────────────────── */

/* The card is gone. D is a full-height split, so the page's own background sits behind the aside
   rather than around a floating panel. `.home-background`'s inline background image still paints on
   the wrapper; it is only visible now where the split does not reach, which at >=992px is nowhere. */
.login-v3 {
    min-height: 100vh;
}

/* `.login-box` keeps its class so login-refresh.css still reaches the form controls, buttons, focus
   rings and validation inside it — none of which D changes. What D overrides is only the geometry:
   that file's 48px margins and the col-md-9 measure both go, because there is no longer a card to
   centre. */
.login-v3 .login-box {
    margin: 0;
    padding: 0;
    width: 100%;
    float: none;
}

.login-v3-split {
    display: flex;
    flex-wrap: wrap;
    min-height: 100vh;
    align-items: stretch;
}

/* 42/58 rather than 50/50: the form is the task and the aside is context, so the aside takes the
   smaller half. `flex-basis` in percent with `flex-wrap` means the two drop to full width together
   the moment they cannot both fit — the same single step Bootstrap's grid already takes at 992. */
.login-v3-aside {
    flex: 0 1 42%;
    min-width: 0;
    box-sizing: border-box;
    background-color: #29599A;
    color: #ffffff;
    padding: 56px 48px;
    display: flex;
    flex-direction: column;
    justify-content: center;
}

/* `align-items: center` is what centres the 420px form block in the white half. Without it the
   block sits hard against the left padding with ~370px of dead white beside it — which measured
   clean (the split was correct, the widths were correct) and looked wrong. The harness README's
   warning about exactly this is why the screenshots get opened. */
.login-v3-form {
    flex: 1 1 58%;
    min-width: 0;
    box-sizing: border-box;
    background-color: #ffffff;
    padding: 56px 48px;
    display: flex;
    flex-direction: column;
    justify-content: center;
    align-items: center;
}

/* ── The banner ──────────────────────────────────────────────────────────────────────────────── */

/* `Model.LogoURL` is a per-customer asset with its own colours and an arbitrary aspect — production's
   is roughly 765x103. It is not navy-safe, so it gets a white plate rather than sitting directly on
   the aside. FACELIFT-198 learned the other half of this the hard way: do NOT cap its height. A
   max-height of 64px shrank that banner to about a third of its area. */
.login-v3-banner {
    background-color: #ffffff;
    border-radius: 10px;
    padding: 14px;
    margin-bottom: 36px;
    align-self: flex-start;
    max-width: 420px;
    width: 100%;
    box-sizing: border-box;
}

.login-v3-banner img {
    display: block;
    width: 100%;
    height: auto;
    margin: 0;
}

/* ── The welcome copy ────────────────────────────────────────────────────────────────────────── */

/* `@Html.Raw(Model.Message)` is CUSTOMER-AUTHORED HTML, stored raw and edited from Company Tools. It
   was written to sit on a white card, so it may carry its own inline colours that vanish on navy.
   These rules force the colours this file can reach; an inline `style="color:#333"` in the stored
   copy will still win, and that is a content fix, not a CSS one. Worth checking per customer before
   this reaches more than the pilot. */
.login-v3-welcome {
    font-size: 16px;
    line-height: 1.6;
    color: #ffffff;
    max-width: 46ch;
}

.login-v3-welcome p,
.login-v3-welcome li,
.login-v3-welcome span,
.login-v3-welcome div {
    color: #ffffff;
}

.login-v3-welcome strong,
.login-v3-welcome b {
    color: #ffffff;
    font-weight: 700;
}

/* The title arrives as `<p><strong>…</strong></p>` with no class of its own — there is no element to
   hook, so the first paragraph is styled positionally. */
.login-v3-welcome > p:first-child strong {
    display: block;
    font-size: 26px;
    line-height: 1.25;
    font-weight: 700;
    letter-spacing: -0.02em;
    margin-bottom: 10px;
}

.login-v3-welcome a {
    color: #ffffff;
    text-decoration: underline;
}

.login-v3-welcome a:hover,
.login-v3-welcome a:focus {
    color: #e6edf6;
}

/* ── Buttons: /v3's palette, not the theme's ─────────────────────────────────────────────────── */

/* Until now these two took their colour from whichever Kendo theme was loaded, which is why the
   page could render a white-on-white "New User Sign On" (FACELIFT-438). On a page that has no
   customer theme to respect, that is all cost and no benefit — so inside `.login-v3` they are
   pinned to the employee branding instead, the same tokens bootstrap-custom.scss feeds /v3:
   primary #29599A, success #69a442.

   A side effect worth knowing: this makes FACELIFT-438 unreachable on this view. It does NOT fix
   it - the other 652 views still take the theme's fill, and that bug stands.

   FOREGROUNDS ARE MEASURED, NOT ASSUMED - the FACELIFT-197 rule. White on #69a442 is 3.00:1, which
   fails AA, and forcing white there is exactly the bug 197 found and removed across seven palettes.
   /v3 resolves this with Bootstrap's own color-contrast(), which picks DARK text on the green and
   white on the navy. The same two picks are hardcoded here because this file cannot run SASS. */

.login-v3 .btn-thinkware,
.login-v3 .btn-thinkware:focus {
    background-color: #29599A;
    border-color: #29599A;
    color: #ffffff;          /* 4.58:1 */
}

.login-v3 .btn-success,
.login-v3 .btn-success:focus {
    background-color: #69a442;
    border-color: #69a442;
    color: #141617;          /* 6.07:1 - white would be 3.00:1 and fail */
}

/* login-refresh.css already darkens every `.btn` on hover with `filter: brightness(.94)`, which is
   theme-agnostic and works on both of these. Nothing further is needed here. */

/* ── The form side ───────────────────────────────────────────────────────────────────────────── */

/* login-refresh.css pads `.login-box .panel-body` at 32px; the split owns its own padding now. */
.login-v3 .panel-body {
    padding: 0;
    max-width: 420px;
    width: 100%;
}

/* ── The leftover inner grid ─────────────────────────────────────────────────────────────────── */

/* Ten views still carry a `.row > .col-md-6` pair INSIDE the form side. It made sense when the card
   was the whole page: form left, helper copy right. Now that the page itself is the split, it is a
   second division inside the first — the form gets half of the white column and its password rules
   are crushed into a 200px gutter beside it.

   Flattened rather than removed from 10 views of Razor: every one of those columns is full width
   here, so the form owns the white side and its helper copy falls beneath it.

   `col-md-4` is deliberately NOT included — EntryPoint and NoCodeSelectClient use it for a row of
   choices, and that row is meant to stay a row. */
.login-v3-form .row {
    margin-left: 0;
    margin-right: 0;
}

.login-v3-form .col-md-6,
.login-v3-form .col-md-12,
.login-v3-form .col-sm-12,
.login-v3-form .col-sm-10,
.login-v3-form .col-sm-9 {
    width: 100%;
    float: none;
    padding-left: 0;
    padding-right: 0;
}

/* An aside holding nothing but the banner does not need 42% of the viewport. Ten views are in that
   state until their helper copy is moved into it; until then, give the width back to the form.
   `:has()` is unsupported on older engines, where this simply does not apply and the aside keeps
   its full share — the same progressive-enhancement bargain as `display: contents` below. */
.login-v3-aside:has(> .login-v3-banner:only-child) {
    flex: 0 1 30%;
    justify-content: flex-start;
    padding-top: 56px;
}

.login-v3-heading {
    font-size: 24px;
    font-weight: 700;
    letter-spacing: -0.02em;
    margin: 0 0 4px;
    color: #141617;
}

.login-v3-subheading {
    font-size: 14.5px;
    color: #5c6166;
    margin: 0 0 24px;
}

/* ── C: below 992, one column, welcome after the form ────────────────────────────────────────── */

@media (max-width: 991px) {
    .login-v3,
    .login-v3-split {
        min-height: 0;
    }

    .login-v3-split {
        flex-direction: column;
    }

    .login-v3-aside,
    .login-v3-form {
        flex: 1 1 auto;
        padding: 28px 20px;
        justify-content: flex-start;
    }

    .login-v3-aside {
        padding-bottom: 28px;
    }

    .login-v3-banner {
        margin-bottom: 0;
        max-width: 100%;
    }

    .login-v3 .panel-body {
        max-width: 100%;
    }

    /* The welcome copy demotes BENEATH the form — C's own argument is that most of it is boilerplate
       about the mobile app, and if it is not worth a column it is not worth the top of a phone
       screen. `display: contents` lifts the banner and the welcome out of the aside so all three
       become siblings of one flex column and can be ordered independently, with no duplicated
       markup. Guarded because where it is unsupported the fallback — welcome above the form, as on
       desktop — is merely not ideal rather than broken. */
    @supports (display: contents) {
        .login-v3-aside {
            display: contents;
        }

        .login-v3-banner {
            order: 1;
            background-color: #29599A;
            border-radius: 0;
            padding: 20px;
            margin: 0;
            align-self: auto;
        }

        .login-v3-banner img {
            max-width: 420px;
            margin: 0 auto;
        }

        .login-v3-form {
            order: 2;
        }

        .login-v3-welcome {
            order: 3;
            background-color: #29599A;
            padding: 28px 20px;
            max-width: 100%;
            font-size: 15px;
        }

        .login-v3-welcome > p:first-child strong {
            font-size: 20px;
        }
    }
}