/*!
 * BBN Portal — navigation CSS. bbn-portal v0.2.0.
 * From snippets 3428 (hide mobile tab bar on desktop; was head/priority 1, must stay
 * early to avoid a flash) and 3429 (mobile bar full width; wins by specificity
 * `body #bbn-nav`, not by load order, so it is safe here in the head).
 */

/* ===== ONE NAVIGATION, NOT TWO (2026-08-23) ================================================
 * Owner: "why is there a top nav and side nav all that should be in side wtf?"
 *
 * Verified in the served HTML, not guessed: EVERY portal page renders the Elementor theme header
 * template — /portal/ (2 instances, 23 nav menus), /saved/, /my-account/ and /reset-password/
 * (3 instances, 53 nav menus each). So the public marketing header was sitting on top of the
 * portal rail, giving members two competing navigations for the same destinations. The original
 * portal shell was designed with the theme header hidden; that was never applied to the live
 * pages.
 *
 * THE ENQUEUE IS THE SCOPE. This stylesheet loads only on the 12 portal page IDs plus
 * /reset-password/ (see portal-assets.php), so an unscoped selector here cannot reach the public
 * site. That is deliberate — enumerating 13 page-id classes would rot the moment a page is added.
 * If nav.css is ever enqueued more widely, revisit this rule first.
 *
 * Getting back to the public site is not lost: the rail carries a "Main site" link, and so does
 * the mobile sheet.
 *
 * The FOOTER is deliberately left alone for now — it is below the fold and not what was reported.
 * Say the word and it goes the same way.
 */
.elementor-location-header {
  display: none !important;
}

/* THE FOOTER GOES TOO.
 *
 * Hiding only the header was not enough. Measured on /reset-password/: headers 0 visible, but
 * TWO site nav menus still rendering — they live in the FOOTER, which was fully visible. Owner,
 * on the reset page: "i shouldnt see shit of build be hind", and on the portal: "all that should
 * be in side". A marketing footer with its own navigation is the same duplicate-nav problem as
 * the header, just below the fold.
 *
 * Same scoping logic as above — this stylesheet only loads on the 12 portal pages plus
 * /reset-password/, so the public site keeps its footer untouched. */
.elementor-location-footer {
  display: none !important;
}

/* ===== #bbn-sheet — THE SAME BUG AS BELOW, ONE ELEMENT THAT WAS MISSED (2026-08-23) =====
 * Snippet 3428 (below) fixed `.nv-tabs` rendering as a 5,952px stack on desktop because nav v3
 * styles it only inside @media(max-width:1024px). `#bbn-sheet` has the identical defect and was
 * never caught: nav.js puts its whole stylesheet — `#bbn-sheet{position:fixed;inset:0;
 * z-index:9996;background:…;display:none}` and `#bbn-sheet.open{display:block}` — inside that
 * same media query.
 *
 * Measured on the live portal at innerWidth 1280: the sheet computed `display:block;
 * position:static; height:16428.3px`, a role="dialog" with 19 children sitting in the document
 * flow on every portal page. Proof it was the media query and not an override: the injected
 * <style> parses 36 rules and NOT ONE mentions #bbn-sheet at top level, while its raw text
 * plainly contains those rules, right after mobile-only declarations such as
 * `body{padding-bottom:calc(60px + env(safe-area-inset-bottom,0px))}`.
 *
 * Owner reported it as "everything below dashboard looks a hotmess" and "the bullshit zoomin".
 *
 * Same declarations, unconditionally. Mobile is unaffected — nav.js injects an identical copy
 * later, which wins the tie with the same values. `.open` outranks the base rule, so the sheet
 * still opens wherever the More button is used. Rollback: delete this block.
 */
#bbn-sheet {
  position: fixed;
  inset: 0;
  z-index: 9996;
  background: rgba(40, 32, 22, .45);
  display: none;
}

#bbn-sheet.open {
  display: block;
}

/* ===== DESKTOP RAIL WIDTH — third instance of this same cascade problem (2026-08-23) =====
 * Owner: "left pannel nav is conflated why too big cant see drop down".
 *
 * MEASURED on the live portal, desktop media state confirmed (matchMedia '(min-width:1025px)'
 * = true, '(max-width:1024px)' = false, zoom 1, devicePixelRatio 1, root font-size 16px — so
 * this is a real layout bug, not a zoom or a mobile-query artifact):
 *
 *   #bbn-nav  --w resolves to 214px   but computed width = 1265px
 *             left: 0  AND  right: 0  (the base rule sets left/top/bottom only, never right)
 *             widest child .nv-brand = 1264px
 *
 * With left:0 and right:0 both applied, `width` is being lost and the element stretches edge to
 * edge — a 214px sidebar occupying the full 1265px viewport, which is why the rail looks
 * enormous and the grouped dropdowns are unusable. The exact source could not be pinned down by
 * walking document.styleSheets (no accessible rule matched), which points at a runtime-injected
 * or cross-origin sheet — so this states the intent explicitly rather than guessing again.
 *
 * `width: var(--w)` keeps BOTH states correct automatically: nav v3 sets --w to 58px under
 * body.bbn-nav-min for the collapsed rail and 214px expanded, so this does not fight the
 * collapse/hover behaviour. `right: auto` is the part that stops the stretch.
 *
 * Desktop-only on purpose — the mobile bottom bar genuinely wants width:100%, which snippet
 * 3429's block below still provides. Fold all three of these patches into nav v4.
 * Rollback: delete this block.
 */
/* LITERAL widths, not var(--w). The first attempt used `width: var(--w, 214px) !important` and
 * had NO effect: the rule parsed (confirmed by reading document.styleSheets), the media query
 * matched (matchMedia true), and width still computed 1265px. An !important ID rule cannot lose
 * that cascade — so `--w` itself must be resolving to a full-width value at runtime, which makes
 * the variable the bug rather than the cascade. Stating the numbers directly removes the
 * dependency. 214px expanded and 58px collapsed are nav v3's own values.
 *
 * `right: auto` is what stops the edge-to-edge stretch. Note getComputedStyle().right reports the
 * resolved USED value for a fixed element, so it will still read "0px" here — that is expected
 * and not evidence the rule failed; check `width` instead. */
@media (min-width: 1025px) {
  /* WIDTH STAYS AT 214px — do not widen it without also moving the content gutter.
   * The page content starts at a STATIC x=246 (214 + a 32px gap) that nav.js writes at build
   * time, not from --w. Proven: widening the rail to 248px and setting `--w: 248px !important`
   * left the dashboard still beginning at 246, so the rail overlapped the content by 2px.
   * Overriding --w does nothing retroactively because the gutter was already committed as a
   * literal value, and body padding-left measures 0px, so it is not set there either.
   *
   * The owner's "too small" complaint is answered by the font sizes below, not by width. If the
   * rail ever does need to be wider, nav.js has to emit the matching gutter — that is a nav v4
   * change, not a CSS override. */
  /* ⚠️ WIDTH MUST FOLLOW --w. DO NOT HARDCODE IT AGAIN.
   *
   * I broke the hover-expand by pinning `width: 214px !important` here. Owner: "now side nav
   * isnt do the in and out thing when you hover over".
   *
   * nav v3's whole collapse system is driven through the custom property, not through width:
   *     #bbn-nav                                  { --w: 214px; width: var(--w) }
   *     body.bbn-nav-min #bbn-nav                 { --w: 58px }
   *     body.bbn-nav-min #bbn-nav:hover,
   *     body.bbn-nav-min #bbn-nav:focus-within    { --w: 214px }
   * Hovering the collapsed rail only changes --w. Hardcoding width severs that link, so --w
   * flipped 58 -> 214 on hover and the rail never moved.
   *
   * Binding BOTH width and max-width to --w keeps the animation working (58 collapsed, 214 on
   * hover, transition already declared by nav v3) while making the edge-to-edge stretch
   * impossible — the element can never exceed whatever --w currently is. `right: auto` is the
   * other half of that: the stretch came from left:0 and right:0 applying together. */
  body #bbn-nav {
    width: var(--w, 214px) !important;
    max-width: var(--w, 214px) !important;
    right: auto !important;
  }

  /* ── COLLAPSE + HOVER STATED EXPLICITLY, not via var(--w) ───────────────────────────────────
   * Measured: flipping --w to 214px on the collapsed rail left the computed WIDTH at 58px, so
   * width was not following the custom property here. A scan of every readable stylesheet also
   * returned ZERO rules matching `#bbn-nav:hover` — nav v3's own hover rule is not reachable in
   * the cascade at all. Depending on either mechanism is why "hover in and out" kept not working.
   *
   * So both states are declared here in literal pixels. Nothing to propagate, nothing to race.
   * The width transition nav v3 declares (0.16s) still animates between them.
   * 58px collapsed / 214px on hover are nav v3's own values, unchanged. */
  body.bbn-nav-min #bbn-nav {
    width: 58px !important;
    max-width: 58px !important;
  }

  body.bbn-nav-min #bbn-nav:hover,
  body.bbn-nav-min #bbn-nav:focus-within {
    width: 214px !important;
    max-width: 214px !important;
    box-shadow: 0 8px 30px rgba(40, 32, 22, .16);
  }

  /* ── The group chevrons need an INTRINSIC size ──────────────────────────────────────────────
   * Owner: "arrows are huge". Measured collapsed: .nv-car is 1x1 (clamped by nav v3's width:1px
   * collapse trick) while every other nav icon is 17x17. On hover that clamp is released — and
   * because the SVG carries a viewBox but NO width/height, it falls back to the SVG default of
   * 300x150 and blows the rail apart.
   *
   * Sizing it unconditionally means neither state can produce a surprise: 14px collapsed, 14px
   * expanded, and the fade below is what hides it rather than a width clamp. */
  /* Both selectors on purpose. `body #bbn-nav .nv-car` is (0,1,1,1); nav v3's collapse rule is
   * `body.bbn-nav-min #bbn-nav .nv-car` at (0,1,2,1) and outranks it, so the 14px was measured
   * still computing as 1x1. Matching their specificity is what makes the !important land. */
  /* `svg.nv-car`, not `.nv-car`. Both nav v3 and this file mark the width !important, and nav v3's
   * stylesheet is INJECTED AT RUNTIME so it lands after this one — equal specificity means it wins
   * the tie. Measured proof: height:14px applied (nav v3 sets no height) while width stayed 1px.
   * Adding the element selector takes these to (0,1,2,2) and settles it without another guess. */
  body #bbn-nav svg.nv-car,
  body.bbn-nav-min #bbn-nav svg.nv-car,
  body.bbn-nav-min #bbn-nav:hover svg.nv-car,
  body.bbn-nav-min #bbn-nav:focus-within svg.nv-car {
    width: 14px !important;
    height: 14px !important;
    min-width: 14px !important;
    flex: 0 0 auto !important;
  }

  body.bbn-nav-min #bbn-nav svg.nv-car {
    opacity: 0 !important;
    transition: opacity .12s;
  }

  /* Same specificity reasoning as the sizing rule above — nav v3's runtime stylesheet wins any
   * tie, so the hover state has to outrank it rather than match it. */
  body.bbn-nav-min #bbn-nav:hover svg.nv-car,
  body.bbn-nav-min #bbn-nav:focus-within svg.nv-car {
    opacity: 1 !important;
  }

  /* ── An opened group must actually show its children while hovered ──────────────────────────
   * Owner: "cant see sub items". Measured: .nv-sub.open computed display:none with 2 children
   * inside. nav v3 hides .nv-sub outright in the collapsed state and is supposed to restore
   * `.nv-sub.open` on hover, but that restore is not reaching the cascade here — the same reason
   * the width and label rules had to be restated. So state it directly. */
  body.bbn-nav-min #bbn-nav:hover .nv-sub.open,
  body.bbn-nav-min #bbn-nav:focus-within .nv-sub.open {
    display: flex !important;
  }

  /* ── Legibility (2026-08-23) ──────────────────────────────────────────────────────────────
   * Owner: "now side nav is too small and cant see it cuts off".
   *
   * Measured: nothing was actually being clipped — .nv-body already has overflow-y:auto and its
   * content fit (514px in 514px), and no item overflowed horizontally. The real problem is scale:
   * nav v3 sets top-level items to 13px and sub-items to 12.5px while the site's body text
   * computes to 16.8px, so the rail reads as fine print next to everything around it.
   *
   * Modest bump only — 14.5px / 13.5px keeps the rail compact while making it comfortably
   * readable inside the fixed 214px. Deliberately NOT scaled to the body's 16.8px: a navigation
   * rail should read as secondary to page content, and the owner has twice said things were too
   * big. Verified after the change that no item overflows 214px horizontally.
   */
  /* ── Collapsed labels must actually be INVISIBLE, not just 1px wide ─────────────────────────
   * nav v3 collapses labels with `width:1px`, which does not hide text — the glyphs simply spill
   * out of the 58px rail. Measured with the class applied: label span width 1px, opacity 1.
   * Fading them (and clipping the overflow) is what makes the collapsed rail read as icons only.
   * Both are restored on hover/focus, in step with the width animation nav v3 already declares. */
  body.bbn-nav-min #bbn-nav .nv-i > span,
  body.bbn-nav-min #bbn-nav .nv-g > span,
  body.bbn-nav-min #bbn-nav .nv-tog span,
  body.bbn-nav-min #bbn-nav .nv-bt,
  body.bbn-nav-min #bbn-nav .nv-pill {
    opacity: 0 !important;
    overflow: hidden !important;
    transition: opacity .12s;
  }

  body.bbn-nav-min #bbn-nav:hover .nv-i > span,
  body.bbn-nav-min #bbn-nav:focus-within .nv-i > span,
  body.bbn-nav-min #bbn-nav:hover .nv-g > span,
  body.bbn-nav-min #bbn-nav:focus-within .nv-g > span,
  body.bbn-nav-min #bbn-nav:hover .nv-tog span,
  body.bbn-nav-min #bbn-nav:focus-within .nv-tog span,
  body.bbn-nav-min #bbn-nav:hover .nv-bt,
  body.bbn-nav-min #bbn-nav:focus-within .nv-bt,
  body.bbn-nav-min #bbn-nav:hover .nv-pill,
  body.bbn-nav-min #bbn-nav:focus-within .nv-pill {
    opacity: 1 !important;
    overflow: visible !important;
  }

  body #bbn-nav .nv-i {
    font-size: 14.5px !important;
  }

  body #bbn-nav .nv-sub .nv-i {
    font-size: 13.5px !important;
  }

  /* CANNOT-CUT-OFF GUARANTEE. The rail is a fixed-height flex column; a flex child's default
   * min-height:auto refuses to shrink below its content, which defeats overflow-y:auto and lets
   * items spill past the bottom of the viewport instead of scrolling. min-height:0 is what makes
   * the scroll actually engage — this matters on short laptop screens and whenever a grouped
   * dropdown expands. */
  body #bbn-nav .nv-body {
    overflow-y: auto !important;
    min-height: 0 !important;
  }
}

/* ===== from snippet 3428 ===== */
/* REGRESSION FIX, caught by measuring the live DOM at 1440px (2026-08-10).
   nav v3 styles .nv-tabs / .nv-tab / .nv-tab svg ONLY inside @media(max-width:1024px). Outside that
   query the container fell back to display:block and the icons had no width cap, so on desktop the
   mobile tab bar rendered as a 5,952px-tall stack and forced the sidebar to 1,425px wide — the whole
   portal layout collapsed. Measured, not guessed: TABS_DISPLAY_AT_DESKTOP came back "block".
   The mobile-first default has to be OFF, with the media query turning it on. Fold into nav v4. */
#bbn-nav .nv-tabs{display:none;}
#bbn-nav .nv-tab svg{width:21px;height:21px;}
@media(max-width:1024px){
  #bbn-nav .nv-tabs{display:flex;width:100%;}
}

/* ===== from snippet 3429 ===== */
/* Measured on the live DOM: at mobile widths the bottom bar computed to width:214px (the desktop
   sidebar width) even though left and right were both 0 and the media query matched. nav v3's own
   `width:100%` in its mobile block was losing to the base `width:var(--w)`. Rather than keep
   guessing at cascade order inside a runtime-injected stylesheet, this loads last and states it
   plainly. Fold both nav-v3 CSS patches (this and snippet 3428) into v4. */
@media(max-width:1024px){
  body #bbn-nav{width:100% !important;max-width:100% !important;left:0 !important;right:0 !important;}
  body #bbn-nav .nv-tabs{width:100% !important;}
  /* even split, and every target clears the 44px minimum */
  body #bbn-nav .nv-tab{flex:1 1 0 !important;min-width:0 !important;min-height:52px !important;}
}