/*
 * local_jangronavui styles.
 *
 * ROOT CAUSE (confirmed live via getBoundingClientRect and the theme's
 * actual served/compiled CSS, not assumed):
 *
 * This theme's top nav is legacy Bootstrap-2 markup: .navbar-inner,
 * .nav-collapse.collapse, ul.nav and #search are all display:block/float
 * by default, not flexbox. The real layout is ul.nav (float:left, the
 * menu items) and #search form (float:right) both inside
 * .nav-collapse.collapse. On its own that container fits everything on
 * one line once it's wide enough - the problem is the theme's own
 * responsive breakpoint is too narrow for this specific menu:
 *
 *   Bootstrap 2's stock rule (confirmed in the compiled CSS bundle):
 *     .btn-navbar { display: none }
 *     @media (max-width: 979px) { .navbar .btn-navbar { display: block }
 *       .nav-collapse.collapse { height: 0; overflow: hidden } }
 *     @media (min-width: 980px) { .nav-collapse.collapse
 *       { height: auto !important; overflow: visible !important } }
 *
 *   So from 980px up, the theme forces the full desktop menu to always be
 *   expanded (hamburger toggle hidden) - but at 980-1279px there isn't
 *   actually enough room for it. Confirmed live: ul.nav's own natural
 *   single-line width is 817px at full padding, while the real available
 *   .nav-collapse.collapse container is only ~664-862px across that
 *   range (measured at 979/1024/1200px) - never enough, even with padding
 *   trimmed to the edge of readability. This is why "Health & Safety
 *   Info" wrapped onto its own row: the theme was trying to force a
 *   6-item, 817px-wide menu into a box that's sometimes only 664px wide.
 *
 * FIX (two parts, per instruction to prefer flex/padding/search-width
 * adjustments first and only fall back to "squeeze the desktop nav
 * indefinitely" never):
 *
 * 1. >=1280px: this is the narrowest width where the real math actually
 *    works (confirmed live: container is 934px at exactly 1280px, and
 *    every real breakpoint at or above it up to a 1320px body max-width
 *    cap gives at least that much) - trim item padding and the search
 *    box's own width just enough to fit the full menu AND search on one
 *    row, using the flex layout below.
 * 2. 980-1279px: rather than keep squeezing (impossible without either
 *    unreadable text or breaking the "no fixed/absolute" rule), extend
 *    the theme's OWN existing mobile hamburger navigation - which
 *    already works correctly below 980px - up through this range too,
 *    mirroring its own interior styling so the expanded panel looks and
 *    behaves the same way it already does on a phone.
 *
 * Below 980px: entirely untouched - the theme's native responsive nav
 * already handles it correctly.
 */

/* ==========================================================
   COLOURS, TYPOGRAPHY, PREMIUM CTA (client feedback round 2026-09-17)
   Real current colours confirmed via the theme's compiled CSS before
   this change: bar background #555 (mid-grey), hover/active/open-dropdown
   background #5d295f (Berry) with white text, brand/home tab background
   #5d295f with white text, dropdown-menu items #fff on #fff (a real
   pre-existing contrast bug - the last-applied rule in the cascade left
   dropdown link text white on the dropdown panel's own white background).
   Client wants: bar -> Berry, hover/focus/active -> Lavender. Since
   hover currently reuses the exact colour the brand tab and active-state
   both already use, simply repainting the whole bar Berry would make
   hover indistinguishable from "not hovering" - Lavender fixes that by
   construction, not just by request.
   ========================================================== */
.navbar,
.navbar-inner {
    background: #5d295f !important;
    background-image: none !important;
    border-color: #5d295f !important;
}

/* Brand/"JANGRO LMS COURSES" tab: was the same Berry as the rest of the
   bar - on a now-Berry bar that would make it disappear. Given Lavender
   +5d295f text is used for hover/active/focus below, using the same pair
   here reads as "the current section", consistent with an
   always-highlighted persistent tab rather than an arbitrary new colour. */
.navbar .brand {
    background: #c8ceea !important;
    color: #5d295f !important;
}

.navbar .nav > li > a {
    color: #ffffff !important;
}

.navbar .nav > li > a:hover,
.navbar .nav > li > a:focus,
.navbar .nav > .active > a,
.navbar .nav > .active > a:hover,
.navbar .nav > .active > a:focus,
.navbar .nav li.dropdown.open > .dropdown-toggle,
.navbar .nav li.dropdown.active > .dropdown-toggle,
.navbar .nav li.dropdown.open.active > .dropdown-toggle {
    background-color: #c8ceea !important;
    color: #5d295f !important;
}

.navbar .nav li.dropdown > .dropdown-toggle .caret {
    border-top-color: #ffffff !important;
}

.navbar .nav li.dropdown > a:hover .caret,
.navbar .nav li.dropdown > a:focus .caret,
.navbar .nav li.dropdown.open > .dropdown-toggle .caret,
.navbar .nav li.dropdown.active > .dropdown-toggle .caret {
    border-top-color: #5d295f !important;
}

/* Visible keyboard focus - confirmed live the theme applies no explicit
   focus-visible treatment to nav links beyond the same background as
   :hover, which is already covered above; this adds a real outline too
   so focus is distinguishable from a mouse hover for keyboard users. */
.navbar .nav > li > a:focus-visible {
    outline: 2px solid #5d295f !important;
    outline-offset: -2px;
}

/*
 * Dropdown panel: fixes two real pre-existing bugs found live via the
 * matched-rules cascade (not assumed):
 * 1. .dropdown-menu>li>a's last-applied colour was #fff, on the panel's
 *    own white background - invisible text.
 * 2. .navbar .dropdown-menu{background-color:#555!important} (specificity
 *    0,2,0) beats a plain .dropdown-menu rule (0,1,0) - confirmed live,
 *    forcing the open panel to a dark grey rather than white. Matching
 *    that specificity (.navbar .dropdown-menu) rather than adding another
 *    !important on top of the wrong selector.
 */
.navbar .dropdown-menu {
    background-color: #ffffff !important;
}

.dropdown-menu > li > a {
    color: #25133f !important;
}

.dropdown-menu > li > a:hover,
.dropdown-menu > li > a:focus {
    background-color: #c8ceea !important;
    color: #5d295f !important;
}

/*
 * Premium Training Course CTA. Tagged by amd/src/premiumcta.js (a real
 * DOM text check against the actual rendered link, not a hard-coded
 * href/id - menu order/wording can change without silently breaking
 * this) rather than assumed here. Leaf chosen over Forest/Raspberry:
 * Forest is too dark to read as a bright "call to action" pill (same
 * reasoning already applied to the dashboard's success-badge colour
 * earlier in this project), and Raspberry is already reserved as an
 * error/alert-adjacent colour elsewhere in the approved palette
 * guidance - Leaf reads as a clear, positive, on-brand CTA accent,
 * matching the real jangro.co.uk nav's own "Find your local
 * distributor" treatment (bright green pill on a dark bar).
 */
.navbar .nav > li.jangro-nav-cta > a {
    background-color: #78be21 !important;
    color: #1a2e05 !important;
    border-radius: 4px !important;
    margin: 6px 4px !important;
    padding: 8px 14px !important;
}

.navbar .nav > li.jangro-nav-cta > a:hover,
.navbar .nav > li.jangro-nav-cta > a:focus {
    background-color: #8fd42a !important;
    color: #1a2e05 !important;
}

.navbar .nav > li.jangro-nav-cta > a:focus-visible {
    outline: 2px solid #ffffff !important;
    outline-offset: -2px;
}

/* Always show the search input at a readable width and a solid, legible
   background/text colour - not dependent on :hover to become visible.
   Width-independent, applies at every breakpoint. */
#search input#coursesearchbox,
#search:hover input#coursesearchbox,
#search input#coursesearchbox:focus,
#search input#coursesearchbox:active {
    background-color: #ffffff !important;
    color: #333333 !important;
    opacity: 1 !important;
}

/* ==========================================================
   980-1279px: extend the theme's own mobile navigation
   There isn't enough room for the desktop menu here (confirmed live,
   see above) - rather than force it to fit, hand this range to the same
   toggle-driven collapsed nav the theme already uses below 980px.
   :not(.in) is required: Bootstrap 2's collapse plugin toggles the "in"
   class open via its own JS (a plain, non-!important inline height) -
   excluding it here means clicking the toggle still opens the panel
   normally, this rule only forces it closed by default.
   ========================================================== */
@media (min-width: 980px) and (max-width: 1279px) {
    .navbar .btn-navbar {
        display: block !important;
    }

    .nav-collapse.collapse:not(.in) {
        height: 0 !important;
        overflow: hidden !important;
    }

    .nav-collapse.collapse {
        display: block !important;
        clear: both !important;
    }

    .nav-collapse.collapse ul.nav {
        float: none !important;
        white-space: normal !important;
        margin: 0 0 10px !important;
    }

    .nav-collapse.collapse ul.nav > li {
        float: none !important;
    }

    .nav-collapse.collapse ul.nav > li > a {
        padding: 9px 15px !important;
    }

    .nav-collapse.collapse form#search {
        float: none !important;
        margin: 8px 15px !important;
        width: auto !important;
    }

    #search input#coursesearchbox,
    #search:hover input#coursesearchbox,
    #search input#coursesearchbox:focus,
    #search input#coursesearchbox:active {
        width: 100% !important;
        max-width: 300px !important;
    }
}

/* ==========================================================
   >=1280px: fit the whole menu AND the search box on one row
   Confirmed live (getBoundingClientRect, ul.nav given flex-shrink:0 to
   reveal its true natural single-line width of 817px) that the default
   item padding (10px, from theme/site custom.css) and default 200px
   search form don't fit even the 934px container at 1280px - trimming
   both, plus reclaiming a real ~55-64px strip of unused background the
   theme leaves between .nav-collapse.collapse's right edge and the true
   right edge of .navbar (confirmed live at 1280/1366/1440px), closes the
   gap with a safety margin instead of shrinking the search box further.
   Confirmed live: 155px is the minimum #coursesearchbox width that shows
   the full "Search courses" text without clipping it (112px clipped it).
   ========================================================== */
@media (min-width: 1280px) {
    .nav-collapse.collapse {
        display: flex !important;
        flex-wrap: nowrap !important;
        align-items: flex-start !important;
    }

    .nav-collapse.collapse ul.nav {
        float: none !important;
        flex-shrink: 0 !important;
        white-space: nowrap !important;
    }

    .nav-collapse.collapse ul.nav > li > a {
        padding: 10px 6px !important;
    }

    .nav-collapse.collapse form#search {
        float: none !important;
        margin-left: auto !important;
        margin-right: -55px !important;
        flex-shrink: 0 !important;
    }

    #search {
        width: 205px !important;
        flex-shrink: 0;
    }

    #search input#coursesearchbox,
    #search:hover input#coursesearchbox,
    #search input#coursesearchbox:focus,
    #search input#coursesearchbox:active {
        width: 155px !important;
        transition: none !important;
    }
}
