/* ==========================================================================
   Little Moo Hosting - contrast and icon legibility
   ==========================================================================
   Loaded last, so it settles the cascade rather than competing inside it.

   WHY THIS SHEET EXISTS
   --------------------------------------------------------------------------
   Three faults were measured across the client area, and all three are the
   same underlying mistake: a colour stated once, as a literal, for one theme.

     1. Form control borders were `rgba(155, 130, 255, .42)` in BOTH themes -
        one fixed translucent purple. Composited it is 1.37:1 on the light
        ground and 1.77:1 on the dark one. WCAG 1.4.11 wants 3:1 for the
        boundary of a control you are meant to find and click.

     2. `.lmh-cart-btn` carried `color:#FFF !important` on its glyph and got
        its background from a gradient. Section 27 of lmh-contract.css strips
        `background-image` on signed-out routes, which left a white icon on a
        white page - measured 1.09:1, effectively invisible.

     3. Purple was doing the work of a foreground rather than an accent on the
        light ground: eyebrows and outline buttons at 3.44:1 and 2.50:1.

   THE RULE THIS SHEET FOLLOWS
   --------------------------------------------------------------------------
   Light theme: functional glyphs and control boundaries are DARK. Purple is
   kept for state and emphasis - active, selected, focus, badges, accent
   borders - where it is a signal rather than the default ink.
   Dark theme: the inverse, light enough to identify at a glance.

   Values are tokens, defined once per theme, so a later change is one edit and
   not a hunt. Nothing here changes a layout, a route, an icon set or a
   behaviour.
   ========================================================================== */

/* --------------------------------------------------------------------------
   Tokens. Default block is the dark theme, matching the rest of the system;
   [data-theme="light"] overrides. Both were chosen by measuring against the
   ground they actually sit on, not by eye.
   -------------------------------------------------------------------------- */

:root {
    /* control boundary, >= 3:1 on the dark field */
    --lmh-control-border:      #837BA0;
    --lmh-control-border-hover:#A79FC4;
    /* functional glyph colour - the default ink for icons */
    --lmh-icon-ink:            #E9E6F2;
    --lmh-icon-ink-muted:      #C2BCD4;
    /* text that has to clear 4.5:1 on the ground */
    --lmh-accent-text:         #C9B6FF;
}

:root[data-theme="light"] {
    --lmh-control-border:      #6B6483;
    --lmh-control-border-hover:#443E58;
    --lmh-icon-ink:            #241F3A;
    --lmh-icon-ink-muted:      #4A4560;
    --lmh-accent-text:         #5A3FC0;
}

/* --------------------------------------------------------------------------
   1. Control boundaries
   -------------------------------------------------------------------------- */

.form-control,
input[type="text"], input[type="email"], input[type="password"],
input[type="search"], input[type="tel"], input[type="number"],
input[type="url"], select, textarea,
.lmh-auth-field .form-control,
.lmh-auth-password .form-control,
#inputCaptcha {
    border-color: var(--lmh-control-border) !important;
}

.form-control:hover,
input:hover, select:hover, textarea:hover {
    border-color: var(--lmh-control-border-hover) !important;
}

/* Focus stays purple - that is a state, and state is what purple is for. */
.form-control:focus,
input:focus, select:focus, textarea:focus,
#inputCaptcha:focus {
    border-color: var(--lmh-purple, #6D4CDB) !important;
}

/* Placeholders were rendering at full text colour, which reads as a filled
   field. Muted, but still above 4.5:1 on both grounds. */
.form-control::placeholder,
input::placeholder, textarea::placeholder {
    color: var(--lmh-icon-ink-muted) !important;
    opacity: 1;
}

/* --------------------------------------------------------------------------
   2. Functional glyphs
   --------------------------------------------------------------------------
   The house icon component draws with `stroke="currentColor"`, so setting the
   colour on the control is enough - no icon markup is touched.
   -------------------------------------------------------------------------- */

.lmh-icon { color: currentColor; }

/* The support button on signed-out routes. It needs a real background of its
   own because section 27 removes the gradient it used to rely on. Solid brand
   fill with a white glyph is >= 3:1 and keeps purple as emphasis. */
body.lmh-public-page .lmh-cart-btn,
.lmh-cart-btn {
    background-color: var(--lmh-purple, #6D4CDB) !important;
    border-color: var(--lmh-purple, #6D4CDB) !important;
}

body.lmh-public-page .lmh-cart-btn i,
body.lmh-public-page .lmh-cart-btn .lmh-icon,
.lmh-cart-btn i,
.lmh-cart-btn .lmh-icon,
.lmh-cart-btn span:not(.badge) {
    color: #FFFFFF !important;
}

/* Icons sitting inside form field affixes were drawn in a near-invisible tint
   of the field background in both themes. */
.input-group-text,
.input-group-text i,
.input-group-text .lmh-icon,
.lmh-field-icon,
.lmh-input-icon {
    color: var(--lmh-icon-ink-muted) !important;
}

/* --------------------------------------------------------------------------
   3. Purple as accent, not as default ink (light theme)
   -------------------------------------------------------------------------- */

:root[data-theme="light"] .lm-section-eyebrow,
:root[data-theme="light"] .lm-card-kicker,
:root[data-theme="light"] .lmh-kicker,
:root[data-theme="light"] .lmh-portal-subtitle {
    color: var(--lmh-accent-text) !important;
}

:root[data-theme="light"] .lm-btn-outline {
    color: var(--lmh-accent-text) !important;
    border-color: var(--lmh-control-border) !important;
}

/* --------------------------------------------------------------------------
   4. Focus indicator, everywhere
   --------------------------------------------------------------------------
   One visible ring on anything focusable, at >= 3:1 against both grounds.
   -------------------------------------------------------------------------- */

a:focus-visible,
button:focus-visible,
input:focus-visible,
select:focus-visible,
textarea:focus-visible,
[tabindex]:focus-visible {
    outline: 2px solid var(--lmh-purple, #6D4CDB) !important;
    outline-offset: 2px !important;
}

/* ==========================================================================
   Round 2 - the three that survived the first pass
   ==========================================================================
   Each was measured again after the first fix and each had a specific reason
   for surviving, recorded here so the next person does not re-derive it.
   ========================================================================== */

/* --------------------------------------------------------------------------
   5. Control borders, stated at the specificity that actually wins
   --------------------------------------------------------------------------
   The first attempt used `.form-control !important` and still lost: the
   contact page carries `.lmh-contact-page .form-control` with `!important`,
   which is one class more specific. Matching that shape rather than reaching
   for a bigger hammer.
   -------------------------------------------------------------------------- */

.lmh-contact-page .form-control,
.lmh-contact-page input,
.lmh-contact-page textarea,
.lmh-contact-page select,
body .lmh-form-field .form-control,
body .lmh-auth-field .form-control,
body .lmh-auth-password .form-control,
body .form-control,
body input[type="text"], body input[type="email"], body input[type="password"],
body input[type="search"], body input[type="tel"], body textarea, body select {
    border-color: var(--lmh-control-border) !important;
}

.lmh-contact-page .form-control:focus,
body .form-control:focus,
body input:focus, body textarea:focus, body select:focus {
    border-color: var(--lmh-purple, #6D4CDB) !important;
}

/* --------------------------------------------------------------------------
   6. Contact form field icons
   --------------------------------------------------------------------------
   These are `<i>` inside a bare `<span>` in `.lmh-icon-field`, not an
   `.input-group-text`, which is why the first rule never matched them. Their
   colour was computing to `rgba(109, 76, 219, .1)` - a ten-per-cent purple,
   measured at 1.13:1 dark and 1.15:1 light. A field icon is a functional
   glyph, so it takes the icon ink.
   -------------------------------------------------------------------------- */

.lmh-contact-page .lmh-icon-field > span,
.lmh-contact-page .lmh-icon-field > span > i,
.lmh-icon-field > span,
.lmh-icon-field > span > i {
    color: var(--lmh-icon-ink-muted) !important;
    opacity: 1 !important;
}

/* --------------------------------------------------------------------------
   7. Product cards on the signed-out portal home
   --------------------------------------------------------------------------
   `.lm-product-card` is `rgba(255,255,255,.045)` over the page - effectively
   transparent - and its `h3` is a hard `#FFFFFF`. On the dark ground that is
   correct. There was no light-theme counterpart, so on the light ground it
   was white on near-white: measured 1.09:1, the card titles were invisible.
   -------------------------------------------------------------------------- */

:root[data-theme="light"] .lm-product-card,
:root[data-theme="light"] .lm-action-card {
    background: var(--lmh-surface, #FFFFFF) !important;
    border-color: var(--lmh-border-strong, #CFC7BC) !important;
}

:root[data-theme="light"] .lm-product-card h3,
:root[data-theme="light"] .lm-action-card h3,
:root[data-theme="light"] .lm-product-card h2,
:root[data-theme="light"] .lm-action-card h2 {
    color: var(--lmh-text, #16132B) !important;
}

:root[data-theme="light"] .lm-product-card p,
:root[data-theme="light"] .lm-action-card p,
:root[data-theme="light"] .lm-product-card li,
:root[data-theme="light"] .lm-action-card li {
    color: var(--lmh-icon-ink-muted, #4A4560) !important;
}

/* --------------------------------------------------------------------------
   8. The support button, in both themes
   --------------------------------------------------------------------------
   Round 1 pointed it at `--lmh-purple`, which is a light lilac in the dark
   theme (#A78BFA); white on that is 2.72:1, under the 3:1 a glyph needs.
   `--lmh-brand-fill` is the same #6D4CDB in both themes, and white on it
   measures about 5.6:1.
   -------------------------------------------------------------------------- */

body .lmh-cart-btn,
body.lmh-public-page .lmh-cart-btn {
    background-color: var(--lmh-brand-fill, #6D4CDB) !important;
    border-color: var(--lmh-brand-fill, #6D4CDB) !important;
}

/* --------------------------------------------------------------------------
   9. Control borders, at ID specificity
   --------------------------------------------------------------------------
   Round 2 still lost. The winning declaration is
   `#inputEmail { border: ... !important }` in littlemoo-custom.css - an ID,
   so (1,0,0), which no class-based selector can outrank however many classes
   it chains and however late it loads.

   So these are stated as IDs too. Same specificity, later sheet, therefore
   these win. Listed explicitly rather than reached for with a wildcard,
   because an ID override is a blunt instrument and should be auditable.
   -------------------------------------------------------------------------- */

#inputEmail, #inputPassword, #inputName, #inputSubject, #inputMessage,
#inputDomain, #inputCaptcha, #inputNewPassword1, #inputNewPassword2,
#inputCurrentPassword, #inputConfirmPassword {
    border-color: var(--lmh-control-border) !important;
}

#inputEmail:focus, #inputPassword:focus, #inputName:focus, #inputSubject:focus,
#inputMessage:focus, #inputDomain:focus, #inputCaptcha:focus,
#inputNewPassword1:focus, #inputNewPassword2:focus,
#inputCurrentPassword:focus, #inputConfirmPassword:focus {
    border-color: var(--lmh-purple, #6D4CDB) !important;
}

/* --------------------------------------------------------------------------
   10. The last two control boundaries
   --------------------------------------------------------------------------
   Found by listing every bordered control rather than by assuming the ID list
   was complete: the password reveal toggle and the knowledgebase search field
   were still carrying the translucent purple.
   -------------------------------------------------------------------------- */

#inputKnowledgebaseSearch,
.lmh-auth-password-toggle,
.lmh-auth-password .lmh-auth-password-toggle {
    border-color: var(--lmh-control-border) !important;
}

#inputKnowledgebaseSearch:focus,
.lmh-auth-password-toggle:focus-visible {
    border-color: var(--lmh-purple, #6D4CDB) !important;
}

/* --------------------------------------------------------------------------
   11. The mobile navigation toggle
   --------------------------------------------------------------------------
   Only rendered below the xl breakpoint, which is why it survived every pass
   measured at desktop widths and then appeared on all six narrow ones. Same
   translucent purple boundary as the form controls had.
   -------------------------------------------------------------------------- */

.navbar-toggler.lmh-mobile-toggle,
.lmh-mobile-toggle {
    border-color: var(--lmh-control-border) !important;
    color: var(--lmh-icon-ink) !important;
}

.navbar-toggler.lmh-mobile-toggle .fa-bars,
.lmh-mobile-toggle .fa-bars,
.lmh-mobile-toggle .lmh-icon {
    color: var(--lmh-icon-ink) !important;
}

.navbar-toggler.lmh-mobile-toggle:focus-visible,
.lmh-mobile-toggle:focus-visible {
    outline: 2px solid var(--lmh-purple, #6D4CDB) !important;
    outline-offset: 2px !important;
}

/* ==========================================================================
   12. The authenticated shell
   ==========================================================================
   Measured across 13 signed-in screens in both themes. Text came back clean;
   what failed was one family of controls, repeated on every screen because
   they live in the shell.

   All of them were drawing their boundary from `--lmh-client-border` or
   `--lmh-border-strong`. Those are panel-edge tokens - a decorative divider,
   correct at that weight. A control boundary is not decoration: WCAG 1.4.11
   asks for 3:1 on something a person has to find and click. So these point at
   `--lmh-control-border` instead. Panel and card edges are deliberately left
   alone.

   Worst case found: an inactive `.lmh-domain-segment-btn` whose border was
   the same colour as its own background - a ratio of exactly 1.00, i.e. no
   visible boundary at all, in both themes.

   Measured before:
     theme toggle              1.39 dark / 1.35 light
     verification close        1.92 / 1.37
     resend verification       2.27 / 1.34
     .lmh-dt-btn (x6)          2.07 / 1.67
     domain segment (active)   2.08 / 1.53
     domain segment (inactive) 1.00 / 1.00
     domain tools input        2.07 / 1.67
   ========================================================================== */

body.lmh-client-shell .lmh-client-mobile-btn,
body.lmh-client-shell .lmh-theme-toggle,
#lmhThemeToggle,
.lmh-dt-btn,
.lmh-domain-segment-btn,
.lmh-domain-tools-input,
#lmhDomainToolsInput,
#btnEmailVerificationClose,
#btnResendVerificationEmail,
.btn.close,
.btn-resend-verify {
    border-color: var(--lmh-control-border) !important;
}

/* The inactive segment had no boundary at all; the active one keeps the
   brand colour, because selected state is exactly what purple is for. */
.lmh-domain-segment-btn.is-active {
    border-color: var(--lmh-purple, #6D4CDB) !important;
}

body.lmh-client-shell .lmh-client-mobile-btn:hover,
.lmh-dt-btn:hover,
.lmh-domain-segment-btn:hover,
#btnResendVerificationEmail:hover,
#btnEmailVerificationClose:hover {
    border-color: var(--lmh-control-border-hover) !important;
}

#lmhDomainToolsInput:focus,
.lmh-domain-tools-input:focus,
.lmh-dt-btn:focus-visible,
.lmh-domain-segment-btn:focus-visible,
#lmhThemeToggle:focus-visible {
    border-color: var(--lmh-purple, #6D4CDB) !important;
}

/* The warning glyph in the email-verification banner was #F7F3FF on the
   banner's warm light ground - 1.14:1. A status icon has to read. */
.lmh-icon--alert-triangle,
.lmh-icon--alert-circle,
.lmh-icon--info {
    color: var(--lmh-icon-ink) !important;
}

/* ==========================================================================
   13. Issue 25 - telephone field offset
   ==========================================================================
   The phone input sat 19px lower than the email input beside it.

   ROOT CAUSE - and it is not the intl-tel-input wrapper, which was the
   obvious suspect and the wrong one. Measured:

     email field grid rows   30.25px  44px  31.25px   label, input, help text
     phone field grid rows   48.875px 62.625px        label, control - no help

   `.lmh-form-grid` stretches sibling `.lmh-form-field`s to a common height
   (118px here). The email field spends that on three rows; the phone field
   has no help text, so it has only two, and with the default
   `align-content: stretch` the surplus is shared out between them. Its label
   row grows from 30px to 49px and takes the control down with it.

   So the label's 41.875px height was a symptom - a grid item stretching into
   an inflated row - not a wrapping label, and not a padding bug.

   The fix is to stop the rows absorbing the surplus. `align-content: start`
   packs them to the top and leaves the slack at the bottom, so every field in
   a row starts its label and its control at the same y whether or not it
   carries help text.
   ========================================================================== */

.lmh-form-grid > .lmh-form-field {
    align-content: start;
}

/* The phone input was also the one control on the page still drawing the
   old border token, because it is addressed by id elsewhere. */
#inputPhone,
.intl-tel-input .form-control,
.iti input[type="tel"] {
    border-color: var(--lmh-control-border) !important;
}

/* --------------------------------------------------------------------------
   14. The last two, at the specificity that wins
   --------------------------------------------------------------------------
   The verification banner paints everything inside it with
   `.email-verification * { color: … !important }`. A blanket rule like that
   catches the warning glyph too, which is how a status icon ended up at
   1.14:1 on the banner's own ground. Matched with the banner in the selector
   so the icon is addressed more specifically than "everything in here".

   The active domain segment kept the old translucent purple through a
   two-class rule, so it is stated against its container as well.
   -------------------------------------------------------------------------- */

.email-verification .lmh-icon--alert-triangle,
.email-verification .lmh-icon--alert-circle,
.email-verification .lmh-icon--info,
.email-verification svg.lmh-icon {
    color: var(--lmh-icon-ink) !important;
    stroke: var(--lmh-icon-ink) !important;
}

.lmh-domain-segments .lmh-domain-segment-btn.is-active,
.lmh-domain-tools .lmh-domain-segment-btn.is-active,
button.lmh-domain-segment-btn.is-active {
    border-color: var(--lmh-purple, #6D4CDB) !important;
}

.lmh-domain-segments .lmh-domain-segment-btn,
.lmh-domain-tools .lmh-domain-segment-btn,
button.lmh-domain-segment-btn {
    border-color: var(--lmh-control-border) !important;
}

/* --------------------------------------------------------------------------
   15. The final fourteen
   --------------------------------------------------------------------------
   Three separate reasons, each worth recording:

   MOOve   `<input id="current_url">` carries no `type` attribute at all, and
           `input[type="text"]` requires the attribute to be present - it does
           not match an input that merely defaults to text. So the element
           selectors here are bare.

   Profile `#inputFirstName` / `#inputLastName` were simply missing from the
           id list in section 9, and a secondary button was still on the
           panel-edge token.

   Dashboard  the active domain segment needed one more step of specificity.
   -------------------------------------------------------------------------- */

body input:not([type="checkbox"]):not([type="radio"]):not([type="submit"]):not([type="button"]):not([type="hidden"]),
body textarea,
body select {
    border-color: var(--lmh-control-border) !important;
}

body input:not([type="checkbox"]):not([type="radio"]):not([type="submit"]):not([type="button"]):not([type="hidden"]):focus,
body textarea:focus,
body select:focus {
    border-color: var(--lmh-purple, #6D4CDB) !important;
}

#inputFirstName, #inputLastName, #current_url, #additional_domains,
#destination_choice, #inputCompanyName, #inputAddress1, #inputAddress2,
#inputCity, #inputState, #inputPostcode, #inputCountry, #inputLanguage {
    border-color: var(--lmh-control-border) !important;
}

.lmh-btn-secondary,
a.lmh-btn.lmh-btn-secondary,
button.lmh-btn.lmh-btn-secondary {
    border-color: var(--lmh-control-border) !important;
}

body button.lmh-domain-segment-btn.is-active {
    border-color: var(--lmh-purple, #6D4CDB) !important;
}

/* --------------------------------------------------------------------------
   16. Last two
   --------------------------------------------------------------------------
   The active domain segment is held by lmh-contract.css at
   `body.lmh-client-shell .lmh-domain-segment-btn.is-active` - specificity
   (0,3,1). Every attempt above topped out at (0,2,2) and lost. Matching the
   selector exactly, from a later sheet, is what wins - not a bigger hammer.

   `.lmh-field-help` was 4.44:1 against white: under 4.5:1 by a hair, but
   under it.
   -------------------------------------------------------------------------- */

body.lmh-client-shell .lmh-domain-segment-btn.is-active {
    border-color: var(--lmh-purple, #6D4CDB) !important;
}

body.lmh-client-shell .lmh-domain-segment-btn {
    border-color: var(--lmh-control-border) !important;
}

.lmh-field-help,
small.lmh-field-help {
    color: var(--lmh-icon-ink-muted) !important;
}

/* --------------------------------------------------------------------------
   17. The mobile client shell (Issue 24, completed)
   --------------------------------------------------------------------------
   These only render below the shell's mobile breakpoint, so every pass
   measured at desktop widths reported clean and they survived.

   In the light theme the menu trigger and the notification bell were drawing
   white glyphs on a near-white lavender button: measured 1.16:1. The earlier
   Issue 24 work covered `.lmh-client-mobile-btn` and the header links, but
   `.lmh-client-menu-trigger` was not in that list, and the bell carries its
   own trigger class.
   -------------------------------------------------------------------------- */

body.lmh-client-shell .lmh-client-menu-trigger,
body.lmh-client-shell .lmh-client-sidebar-toggle,
body.lmh-client-shell .lmh-notify__trigger {
    border-color: var(--lmh-control-border) !important;
    color: var(--lmh-icon-ink) !important;
}

body.lmh-client-shell .lmh-client-menu-trigger .lmh-icon,
body.lmh-client-shell .lmh-client-menu-trigger i,
body.lmh-client-shell .lmh-client-sidebar-toggle .lmh-icon,
body.lmh-client-shell .lmh-notify__trigger .lmh-icon,
body.lmh-client-shell .lmh-notify__trigger i,
body.lmh-client-shell .lmh-client-mobile-btn .lmh-icon,
body.lmh-client-shell .lmh-client-mobile-btn i {
    color: var(--lmh-icon-ink) !important;
    stroke: currentColor !important;
}

body.lmh-client-shell .lmh-client-menu-trigger:hover,
body.lmh-client-shell .lmh-notify__trigger:hover {
    border-color: var(--lmh-control-border-hover) !important;
}

/* --------------------------------------------------------------------------
   18. Header link glyphs: dark ink by default, purple only on state
   --------------------------------------------------------------------------
   After section 17 the six header controls measured, in light:

     hamburger / notifications / theme toggle  #241F3A  13.64:1
     account                                   #16132B  18.07:1
     help / support                            #6D4CDB   5.67:1

   Help and support pass comfortably, but they were still purple in their
   DEFAULT state, and the rule for this portal is that purple is a signal -
   hover, active, selected, focus - not the colour of a resting functional
   glyph. So the resting state takes the icon ink and purple moves to the
   interaction states, where it means something.
   -------------------------------------------------------------------------- */

body.lmh-client-shell .lmh-client-header-link,
body.lmh-client-shell .lmh-client-header-link .lmh-icon,
body.lmh-client-shell .lmh-client-header-help,
body.lmh-client-shell .lmh-client-header-help .lmh-icon,
body.lmh-client-shell .lmh-client-header-ticket,
body.lmh-client-shell .lmh-client-header-ticket .lmh-icon {
    color: var(--lmh-icon-ink) !important;
}

body.lmh-client-shell .lmh-client-header-link:hover,
body.lmh-client-shell .lmh-client-header-link:hover .lmh-icon,
body.lmh-client-shell .lmh-client-header-link:focus-visible,
body.lmh-client-shell .lmh-client-header-link:focus-visible .lmh-icon,
body.lmh-client-shell .lmh-client-header-link.is-active,
body.lmh-client-shell .lmh-client-header-link.is-active .lmh-icon {
    color: var(--lmh-purple, #6D4CDB) !important;
}