/*
 * SSB2020 (shop.seattlespermbank.com) — assets/css/ssb-nav-static.css
 *
 * Hand-generated, static snapshot of the marketing site's (SSB_Main)
 * nav-only CSS, scoped under ".ssb_header_menu" (the Divi menu module's
 * wrapper class that stays in place around the injected nav markup) and
 * with every declaration forced !important, so it reliably wins against
 * Divi's own module CSS regardless of specificity or load order.
 *
 * This file is NOT fetched live from marketing at request time. It was
 * generated once from marketing's actual /wp-json/ssb/v1/nav-css output
 * (captured 2026-08-21) run through the same ssb_scope_and_force_css()
 * transform used previously for the live version — see SSB_Main's
 * inc/rest-nav.php for that function if this needs to be regenerated.
 *
 * Why static instead of live: the live-fetch approach kept missing
 * properties marketing gets "for free" through inheritance/cascade from
 * rules our nav-only filter deliberately excludes (e.g. nav link
 * font-size wasn't being forced because it fell outside the narrow
 * token filter in some earlier revisions) — a losing game of whack-a-
 * mole against Divi's own styling. Hand-generating this file once from
 * the REAL authored CSS (not reverse-engineered computed styles) avoids
 * that: every property the nav actually needs is explicit and forced.
 *
 * The nav's HTML/menu items remain LIVE-synced from marketing (see
 * functions-ssb-nav-sync.php) — only the CSS is now static. If
 * marketing's nav DESIGN changes (colors, fonts, spacing — not just
 * menu items), this file needs to be manually regenerated and
 * redeployed; that's a deliberate, occasional step rather than
 * something fought automatically on every page load.
 *
 * To regenerate: fetch https://staging.seattlespermbank.com/wp-json/ssb/v1/nav-css,
 * run it through ssb_scope_and_force_css($css, '.ssb_header_menu'), save here.
 */

.ssb_header_menu #primary-nav, .ssb_header_menu #primary-nav *, .ssb_header_menu .nav-drawer, .ssb_header_menu .nav-drawer *, .ssb_header_menu .offcanvas-nav, .ssb_header_menu .offcanvas-nav *, .ssb_header_menu .nav-toggle, .ssb_header_menu .nav-toggle * { box-sizing: border-box !important; }
@media (max-width:991px) {
.ssb_header_menu .primary-nav { display:none !important; }
}
/*
 * padding/margin/list-style overrides here are load-bearing, not cosmetic.
 * Divi's own base stylesheet ships a generic "content area list" rule —
 * "#left-area ul, .entry-content ul, .et-l--body ul, .et-l--footer ul,
 * .et-l--header ul { list-style-type:disc; padding:0 0 23px 1em; ... }" —
 * meant for bulleted lists inside page content, and it matches this <ul>
 * too because the Divi Theme Builder header template wraps it in
 * ".et-l--header". It has no !important and isn't very specific, but we
 * were never setting padding on .nav-list at all, so it was the only rule
 * touching it and won by default. Because box-sizing is border-box here,
 * that 23px bottom padding was eaten out of the already-!important
 * height:72px box, so .nav-item/.nav-link (which stretch to fill this
 * element via align-items:stretch) were only rendering ~49px tall instead
 * of the full 72px header height — leaving a dead strip along the top/
 * bottom of each nav item where hover/click did nothing, which is why it
 * felt like only the link text itself was hoverable instead of the whole
 * pill. Zeroing padding/margin and killing the bullet here restores the
 * full-height hit area, matching marketing's own (naturally zero) values.
 */
.ssb_header_menu .nav-list { display:-webkit-box !important; display:-ms-flexbox !important; display:flex !important; -webkit-box-align:stretch !important; -ms-flex-align:stretch !important; align-items:stretch !important; height:72px !important; padding:0 !important; margin:0 !important; list-style-type:none !important; }
.ssb_header_menu .nav-item { position:relative !important; display:-webkit-box !important; display:-ms-flexbox !important; display:flex !important; -webkit-box-align:stretch !important; -ms-flex-align:stretch !important; align-items:stretch !important; -webkit-transition:background-color 150ms ease !important; transition:background-color 150ms ease !important; }
.ssb_header_menu .nav-item.is-drawer-open, .ssb_header_menu .nav-item:hover { background-color:#7dc5a8 !important; }
.ssb_header_menu .nav-link { display:-webkit-box !important; display:-ms-flexbox !important; display:flex !important; -webkit-box-align:center !important; -ms-flex-align:center !important; align-items:center !important; padding:0 24px !important; font-family:'Open Sans','Helvetica Neue',Arial,sans-serif !important; font-size:0.875rem !important; font-weight:700 !important; letter-spacing:0.08em !important; text-transform:uppercase !important; color:#ffffff !important; white-space:nowrap !important; }
.ssb_header_menu .nav-link:hover { color:#ffffff !important; }
.ssb_header_menu .nav-toggle { display:none !important; -webkit-box-orient:vertical !important; -webkit-box-direction:normal !important; -ms-flex-direction:column !important; flex-direction:column !important; gap:5px !important; background:none !important; border:none !important; padding:8px !important; -webkit-transition:opacity 280ms ease !important; transition:opacity 280ms ease !important; }
@media (max-width:991px) {
.ssb_header_menu .nav-toggle { display:-webkit-box !important; display:-ms-flexbox !important; display:flex !important; }
}
.ssb_header_menu .nav-toggle:hover { opacity:0.7 !important; }
.ssb_header_menu .nav-toggle__bar { display:block !important; width:24px !important; height:2px !important; background-color:#ffffff !important; border-radius:9999px !important; -webkit-transition:-webkit-transform 150ms ease !important; transition:-webkit-transform 150ms ease !important; transition:transform 150ms ease !important; transition:transform 150ms ease,-webkit-transform 150ms ease !important; }
.ssb_header_menu .footer-nav { list-style:none !important; margin:0 !important; padding:0 !important; }
.ssb_header_menu .footer-nav li { margin-bottom:0 !important; }
.ssb_header_menu .footer-nav a { color:#ffffff !important; font-size:0.875rem !important; -webkit-transition:color 150ms ease !important; transition:color 150ms ease !important; }
.ssb_header_menu .footer-nav a:hover { color:#fef8bf !important; }
.ssb_header_menu .nav-drawer { position:absolute !important; top:100% !important; left:0 !important; right:0 !important; z-index:600 !important; background-color:#ffffff !important; border-top:2px solid #aad2e6 !important; -webkit-box-shadow:0 8px 32px rgba(42,82,96,0.16) !important; box-shadow:0 8px 32px rgba(42,82,96,0.16) !important; visibility:hidden !important; opacity:0 !important; -webkit-transform:translateY(-6px) !important; transform:translateY(-6px) !important; pointer-events:none !important; -webkit-transition:opacity 380ms cubic-bezier(0.4,0,0.2,1),visibility 0s linear 380ms cubic-bezier(0.4,0,0.2,1),-webkit-transform 380ms cubic-bezier(0.4,0,0.2,1) !important; transition:opacity 380ms cubic-bezier(0.4,0,0.2,1),visibility 0s linear 380ms cubic-bezier(0.4,0,0.2,1),-webkit-transform 380ms cubic-bezier(0.4,0,0.2,1) !important; transition:opacity 380ms cubic-bezier(0.4,0,0.2,1),transform 380ms cubic-bezier(0.4,0,0.2,1),visibility 0s linear 380ms cubic-bezier(0.4,0,0.2,1) !important; transition:opacity 380ms cubic-bezier(0.4,0,0.2,1),transform 380ms cubic-bezier(0.4,0,0.2,1),visibility 0s linear 380ms cubic-bezier(0.4,0,0.2,1),-webkit-transform 380ms cubic-bezier(0.4,0,0.2,1) !important; }
@media (max-width:991px) {
.ssb_header_menu .nav-drawer { display:none !important; }
}
.ssb_header_menu .nav-drawer.is-open { visibility:visible !important; opacity:1 !important; -webkit-transform:translateY(0) !important; transform:translateY(0) !important; pointer-events:auto !important; -webkit-transition:opacity 380ms cubic-bezier(0.4,0,0.2,1),visibility 0s linear 0s,-webkit-transform 380ms cubic-bezier(0.4,0,0.2,1) !important; transition:opacity 380ms cubic-bezier(0.4,0,0.2,1),visibility 0s linear 0s,-webkit-transform 380ms cubic-bezier(0.4,0,0.2,1) !important; transition:opacity 380ms cubic-bezier(0.4,0,0.2,1),transform 380ms cubic-bezier(0.4,0,0.2,1),visibility 0s linear 0s !important; transition:opacity 380ms cubic-bezier(0.4,0,0.2,1),transform 380ms cubic-bezier(0.4,0,0.2,1),visibility 0s linear 0s,-webkit-transform 380ms cubic-bezier(0.4,0,0.2,1) !important; }
.ssb_header_menu .nav-drawer__inner { display:-webkit-box !important; display:-ms-flexbox !important; display:flex !important; -webkit-box-align:start !important; -ms-flex-align:start !important; align-items:flex-start !important; gap:64px !important; max-width:1500px !important; margin:0 auto !important; padding:48px 24px !important; }
.ssb_header_menu .nav-drawer__cols { display:-webkit-box !important; display:-ms-flexbox !important; display:flex !important; -webkit-box-flex:1 !important; -ms-flex:1 !important; flex:1 !important; gap:64px !important; -webkit-box-align:start !important; -ms-flex-align:start !important; align-items:flex-start !important; }
.ssb_header_menu .nav-drawer__col { -webkit-box-flex:1 !important; -ms-flex:1 !important; flex:1 !important; min-width:160px !important; }
.ssb_header_menu .nav-drawer__col-title { font-family:'Open Sans','Helvetica Neue',Arial,sans-serif !important; font-size:0.875rem !important; font-weight:700 !important; letter-spacing:0.08em !important; text-transform:uppercase !important; color:#7a8e94 !important; margin:0 0 16px !important; padding-bottom:12px !important; border-bottom:1px solid #ededed !important; }
.ssb_header_menu .nav-drawer__col-title.no-title { display:none !important; }
.ssb_header_menu .nav-drawer__col-title a { color:inherit !important; -webkit-transition:color 280ms ease !important; transition:color 280ms ease !important; }
.ssb_header_menu .nav-drawer__col-title a:hover { color:#aad2e6 !important; }
.ssb_header_menu .nav-drawer__group { margin-bottom:24px !important; }
.ssb_header_menu .nav-drawer__group:last-child { margin-bottom:0 !important; }
.ssb_header_menu .nav-drawer__group-title { font-family:'Open Sans','Helvetica Neue',Arial,sans-serif !important; font-size:0.875rem !important; font-weight:700 !important; letter-spacing:0.08em !important; text-transform:uppercase !important; color:#2e3d42 !important; margin:0 0 12px !important; }
.ssb_header_menu .nav-drawer__group-title a { color:inherit !important; -webkit-transition:color 150ms ease !important; transition:color 150ms ease !important; }
.ssb_header_menu .nav-drawer__group-title a:hover { color:#aad2e6 !important; }
.ssb_header_menu .nav-drawer__links { list-style:none !important; margin:0 !important; padding:0 0 2rem 0 !important; }
.ssb_header_menu .nav-drawer__item:not(:last-child) { margin-bottom:8px !important; }
/*
 * color is boosted with an extra ".nav-drawer__group" ancestor class because
 * Divi's own Theme Builder header CSS ships an inline (not-external-file)
 * rule "html body .et_pb_menu_0_tb_header.et_pb_menu ul li a { color:#fff
 * !important }" that also matches these <a> tags (they really do sit inside
 * a <ul><li> in the drawer markup). That rule is !important with 2 classes +
 * 3 element selectors (ul li a); a bare ".ssb_header_menu .nav-drawer__link"
 * (2 classes, 0 elements) loses the specificity tie even though it's also
 * !important. Adding ".nav-drawer__group" (a real, always-present ancestor)
 * brings this to 3 classes, which beats Divi's rule outright regardless of
 * element-selector count or source order. Without this, every drawer link
 * rendered as invisible white-on-white text — only the (non-<a>-inside-<li>)
 * column/group titles above them were ever visibly dark.
 */
.ssb_header_menu .nav-drawer__group .nav-drawer__link { display:block !important; padding:2px 0 !important; font-size:1rem !important; color:#2e3d42 !important; -webkit-transition:color 150ms ease,padding-left 150ms ease !important; transition:color 150ms ease,padding-left 150ms ease !important; }
.ssb_header_menu .nav-drawer__link:hover { color:#aad2e6 !important; padding-left:8px !important; }
.ssb_header_menu .nav-drawer__link[aria-current=page] { color:#aad2e6 !important; font-weight:600 !important; }
.ssb_header_menu .nav-drawer__link--top { font-family:'Open Sans','Helvetica Neue',Arial,sans-serif !important; font-size:0.875rem !important; font-weight:700 !important; letter-spacing:0.08em !important; text-transform:uppercase !important; padding-left:0 !important; }
/*
 * "--top" links (drawer items that sit directly under a group with no
 * .nav-drawer__group wrapper — e.g. Find a Donor, Pricing, Why SSB) were
 * never covered by the ".nav-drawer__group .nav-drawer__link" color fix
 * above, since their parent is plain ".nav-drawer__item", not
 * ".nav-drawer__group". Left unfixed they inherit Divi's forced white
 * !important link color and render invisible white-on-white. The base
 * ".nav-drawer__link--top" rule above (2 classes) also loses the same
 * specificity tie Divi's rule wins elsewhere, so this compounds the link's
 * own two classes together (".nav-drawer__link.nav-drawer__link--top",
 * 3 classes) to beat it outright, same pattern as the fix above.
 */
.ssb_header_menu .nav-drawer__link.nav-drawer__link--top { color:#2e3d42 !important; }
.ssb_header_menu .nav-drawer__link--top:hover { color:#aad2e6 !important; padding-left:0 !important; }
.ssb_header_menu .nav-drawer__image { -ms-flex-negative:0 !important; flex-shrink:0 !important; width:75vw !important; max-width:700px !important; }
.ssb_header_menu .nav-drawer__image img { width:100% !important; height:auto !important; display:block !important; border-radius:8px !important; }
.ssb_header_menu .nav-item.is-drawer-open>.nav-link { color:#ffffff !important; }
.ssb_header_menu .nav-overlay { position:fixed !important; inset:0 !important; z-index:499 !important; background-color:rgba(0,0,0,0.45) !important; opacity:0 !important; pointer-events:none !important; -webkit-transition:opacity 280ms ease !important; transition:opacity 280ms ease !important; }
.ssb_header_menu .nav-overlay.is-visible { opacity:1 !important; pointer-events:auto !important; }
.ssb_header_menu .offcanvas-nav { position:fixed !important; top:0 !important; left:0 !important; height:100% !important; width:100% !important; max-width:100vw !important; z-index:700 !important; background-color:#aad2e6 !important; -webkit-transform:translateX(-100%) !important; transform:translateX(-100%) !important; -webkit-transition:-webkit-transform 380ms cubic-bezier(0.4,0,0.2,1) !important; transition:-webkit-transform 380ms cubic-bezier(0.4,0,0.2,1) !important; transition:transform 380ms cubic-bezier(0.4,0,0.2,1) !important; transition:transform 380ms cubic-bezier(0.4,0,0.2,1),-webkit-transform 380ms cubic-bezier(0.4,0,0.2,1) !important; overflow-y:auto !important; -webkit-overflow-scrolling:touch !important; }
.ssb_header_menu .offcanvas-nav.is-open { -webkit-transform:translateX(0) !important; transform:translateX(0) !important; }
.ssb_header_menu .offcanvas-nav__header { display:-webkit-box !important; display:-ms-flexbox !important; display:flex !important; -webkit-box-align:center !important; -ms-flex-align:center !important; align-items:center !important; -webkit-box-pack:justify !important; -ms-flex-pack:justify !important; justify-content:space-between !important; padding:24px 24px !important; border-bottom:1px solid #7ab5c8 !important; }
.ssb_header_menu .offcanvas-nav__close { display:-webkit-box !important; display:-ms-flexbox !important; display:flex !important; -webkit-box-align:center !important; -ms-flex-align:center !important; align-items:center !important; gap:8px !important; background:none !important; border:none !important; color:#2e3d42 !important; cursor:pointer !important; padding:4px !important; -webkit-transition:opacity 150ms ease !important; transition:opacity 150ms ease !important; }
.ssb_header_menu .offcanvas-nav__close:hover { opacity:0.7 !important; }
.ssb_header_menu .offcanvas-nav__close-icon { font-size:1.5rem !important; line-height:1 !important; }
.ssb_header_menu .offcanvas-nav__close-label { font-family:'Open Sans','Helvetica Neue',Arial,sans-serif !important; font-size:0.875rem !important; font-weight:700 !important; letter-spacing:0.08em !important; text-transform:uppercase !important; }
.ssb_header_menu .offcanvas-nav__body { padding:24px !important; }
.ssb_header_menu .offcanvas-nav__list { list-style:none !important; margin:0 !important; padding:0 !important; }
.ssb_header_menu .offcanvas-nav__item { border-bottom:1px solid #7ab5c8 !important; margin:0 -24px !important; padding:0 24px !important; -webkit-transition:background-color 150ms ease !important; transition:background-color 150ms ease !important; }
.ssb_header_menu .offcanvas-nav__item:last-child { border-bottom:none !important; }
.ssb_header_menu .offcanvas-nav__item.offcanvas-nav__item--open, .ssb_header_menu .offcanvas-nav__item:hover { background-color:#8ac1dd !important; }
.ssb_header_menu .offcanvas-nav__link, .ssb_header_menu .offcanvas-nav__toggle { display:-webkit-box !important; display:-ms-flexbox !important; display:flex !important; -webkit-box-align:center !important; -ms-flex-align:center !important; align-items:center !important; -webkit-box-pack:justify !important; -ms-flex-pack:justify !important; justify-content:space-between !important; gap:12px !important; width:100% !important; padding:16px 0 !important; background:none !important; border:none !important; font-family:'Open Sans','Helvetica Neue',Arial,sans-serif !important; font-size:1rem !important; font-weight:700 !important; letter-spacing:0.08em !important; text-transform:uppercase !important; color:#2e3d42 !important; text-decoration:none !important; text-align:left !important; cursor:pointer !important; }
.ssb_header_menu .offcanvas-nav__link[aria-current=page] { text-decoration:underline !important; }
.ssb_header_menu .offcanvas-nav__plus { position:relative !important; -ms-flex-negative:0 !important; flex-shrink:0 !important; width:14px !important; height:14px !important; }
.ssb_header_menu .offcanvas-nav__plus:after, .ssb_header_menu .offcanvas-nav__plus:before { content:'' !important; position:absolute !important; top:50% !important; left:50% !important; background-color:currentColor !important; -webkit-transform:translate(-50%,-50%) !important; transform:translate(-50%,-50%) !important; -webkit-transition:opacity 150ms ease,-webkit-transform 150ms ease !important; transition:opacity 150ms ease,-webkit-transform 150ms ease !important; transition:transform 150ms ease,opacity 150ms ease !important; transition:transform 150ms ease,opacity 150ms ease,-webkit-transform 150ms ease !important; }
.ssb_header_menu .offcanvas-nav__plus:before { width:14px !important; height:2px !important; }
.ssb_header_menu .offcanvas-nav__plus:after { width:2px !important; height:14px !important; }
.ssb_header_menu .offcanvas-nav__item--open .offcanvas-nav__plus:after { -webkit-transform:translate(-50%,-50%) rotate(90deg) !important; transform:translate(-50%,-50%) rotate(90deg) !important; opacity:0 !important; }
/*
 * max-height is deliberately NOT !important here (everything else in this
 * file is). nav.js opens/closes this panel by setting an inline
 * max-height (e.g. style="max-height:1271px") sized to the real content,
 * then relies on the transition below to animate it. An !important base
 * value would always beat that inline style, so the "+" would flip and
 * the row would highlight on click but the panel would never actually
 * grow — exactly what shop was doing before this fix. Marketing's own
 * CSS has no !important here either, for the same reason.
 */
.ssb_header_menu .offcanvas-nav__panel { max-height:0; overflow:hidden !important; -webkit-transition:max-height 380ms cubic-bezier(0.4,0,0.2,1) !important; transition:max-height 380ms cubic-bezier(0.4,0,0.2,1) !important; }
.ssb_header_menu .offcanvas-nav__drawer { padding:0 0 24px !important; font-size:0.75rem !important; }
.ssb_header_menu .offcanvas-nav__drawer .nav-drawer__inner { display:block !important; max-width:none !important; margin:0 !important; padding:0 !important; }
.ssb_header_menu .offcanvas-nav__drawer .nav-drawer__cols { display:-ms-grid !important; display:grid !important; -ms-grid-columns:1fr 24px 1fr !important; grid-template-columns:1fr 1fr !important; gap:16px 24px !important; }
.ssb_header_menu .offcanvas-nav__drawer .nav-drawer__col { min-width:0 !important; }
.ssb_header_menu .offcanvas-nav__drawer .nav-drawer__links { padding-bottom:1rem !important; }
.ssb_header_menu .offcanvas-nav__drawer .nav-drawer__col-title a, .ssb_header_menu .offcanvas-nav__drawer .nav-drawer__group-title a, .ssb_header_menu .offcanvas-nav__drawer .nav-drawer__link { color:#2e3d42 !important; }
.ssb_header_menu .offcanvas-nav__drawer .nav-drawer__col-title a:hover, .ssb_header_menu .offcanvas-nav__drawer .nav-drawer__group-title a:hover, .ssb_header_menu .offcanvas-nav__drawer .nav-drawer__link:hover { color:#2e3d42 !important; text-decoration:underline !important; }
.ssb_header_menu .offcanvas-nav__drawer .nav-drawer__link[aria-current=page] { color:#2e3d42 !important; font-weight:600 !important; text-decoration:underline !important; }
.ssb_header_menu .offcanvas-nav__drawer .nav-drawer__col-title, .ssb_header_menu .offcanvas-nav__drawer .nav-drawer__group-title, .ssb_header_menu .offcanvas-nav__drawer .nav-drawer__link { font-size:0.75rem !important; }
.ssb_header_menu .offcanvas-nav__drawer .nav-drawer__image { width:100% !important; max-width:none !important; margin-top:16px !important; }
.ssb_header_menu .nav-item.is-drawer-open>.nav-link { color:#ffffff !important; }

/*
 * Header row background — not part of the nav bundle itself. This is
 * shop's own Divi Theme Builder row that wraps the injected nav (the
 * .ssb_header_menu module sits inside it), previously configured with
 * its own background color (navy, #09445f) instead of marketing's
 * header bar color (#aad2e6). Targeted via :has() anchored on the
 * stable .ssb_header_menu class so it survives a Theme Builder rebuild
 * even if Divi's auto-numbered row class changes; the numbered class is
 * kept as a fallback for browsers without :has() support.
*/
.et_pb_row:has(.ssb_header_menu) { background-color: #aad2e6 !important; }
.et_pb_row_1_tb_header { background-color: #aad2e6 !important; }

/*
 * Row height/vertical-centering fix. Divi's own per-module "cached inline
 * styles" <style> block (id starts "et-builder-module-design-…", injected
 * in <head>, not this file) hard-codes ".et_pb_row_1_tb_header { height:
 * 120px; min-height:120px; ... }" — a leftover from whatever the row was
 * sized to in the Theme Builder UI at some point — and separately
 * ".et_pb_menu_0_tb_header { margin-top:10px !important; ... }" on the nav
 * module itself. Neither is part of the nav bundle's own sizing (nav-list/
 * nav-item/nav-link above are already correctly forced to 72px, matching
 * marketing's real header height), but the row's own explicit height held
 * the whole header band open to 120px with the nav column's real 82px
 * content centered inside it, and the module's forced margin-top:10px then
 * pushed the nav down again inside THAT, leaving ~10px of dead space above
 * every nav item where hovering/clicking did nothing (and visually reading
 * as extra padding around the whole bar). height/min-height above aren't
 * !important on Divi's side, so overriding them here is enough on its own;
 * margin-top IS !important there, so it needs the extra ".et_pb_menu_0_tb_
 * header" class stacked onto our own ".ssb_header_menu" (both classes are
 * always present together on this element) to outrank it on specificity
 * regardless of stylesheet load order — same pattern as the nav-drawer__
 * link color fix above. Letting height resolve to auto (rather than
 * hard-coding 72px again) means this keeps matching automatically if a
 * future nav-only regeneration changes the real nav height.
 */
.et_pb_row_1_tb_header { height: auto !important; min-height: auto !important; max-height: none !important; }
.et_pb_row_1_tb_header .ssb_header_menu.et_pb_menu_0_tb_header { margin-top: 0 !important; }

/*
 * Overlay stacking fix — v2. On marketing, ".nav-overlay" (the dark
 * dimming layer shown behind an open drawer) is appended as a direct
 * child of <body>, a sibling of the whole header — so comparing its
 * z-index:499 against ".site-header"'s z-index:500 is a simple, correct
 * comparison and the header stays on top, fully interactive and fully
 * undimmed, while the overlay dims everything below it.
 *
 * On shop, the synced nav markup (overlay included) is injected INSIDE
 * this Divi menu module, which lives inside column 2 of
 * ".et_pb_row_1_tb_header" — so ".nav-overlay" ends up a DESCENDANT of
 * the row (and of column 2 specifically) instead of a sibling. The first
 * attempt at this fix (v11) only promoted ".nav-list" itself to
 * position:relative + z-index:500, which was enough to fix HIT-TESTING
 * (nav links stayed clickable/hoverable through an open drawer) but not
 * the VISUAL dimming: the logo, cart and login columns all have
 * transparent backgrounds of their own, so — even sitting in a
 * higher stacking layer than the overlay — their transparent pixels
 * still let the overlay's semi-transparent black tint show through from
 * the row's own background layer underneath, which is what read as
 * "color distortion" across the whole bar, not just the nav links.
 *
 * The deeper wrinkle: once column 2 (nav) is ALSO given its own
 * position+z-index (needed so ".nav-list"'s z-index actually has a
 * stacking context to be promoted relative to), column 2 and the other
 * three columns become STACKING-CONTEXT SIBLINGS at the row level. Column
 * 2's z-index has to stay LOWER than the other three: the overlay is
 * position:fixed and paints across the full viewport regardless of
 * column 2's own box bounds, so if column 2 ever ties or beats a
 * left/right column on z-index, tree order lets column 2's bucket
 * (dragging its full-viewport overlay along with it) paint OVER that
 * column instead of under it — this was caught live via
 * elementsFromPoint, which showed ".nav-overlay" sitting above the logo
 * even after giving every column an "equal" elevated z-index.
 *
 * Fix, in full: give the logo/cart/login columns (1, 3, 4) position +
 * z-index:502 — strictly above column 2's bucket, so the fixed overlay
 * nested inside column 2 can never paint over them regardless of tree
 * order. Column 1 additionally needs align-self:stretch (it's a plain
 * block column, unlike 3/4 which already stretch via the cart/login pill
 * rules below) so its protective layer covers the row's full 72px height,
 * not just the shorter box its own content would otherwise size it to.
 * Columns 1 and 2 each get an opaque ::before painted at the row's own
 * background color, sitting inside their column's stacking bucket ABOVE
 * the local overlay but BELOW the column's real content (nav-list is
 * bumped to z-index:501, one above its own column's local decoy) — this
 * is what actually blocks the overlay's tint from showing through
 * transparent pixels, since a transparent higher-z-index box does not by
 * itself hide whatever paints through it from lower layers. Columns 3/4
 * don't need a decoy: their green pill background (see below) is already
 * opaque. The row's own z-index stays 500 for parity with marketing's
 * header.
 */
.et_pb_row_1_tb_header { z-index: 500 !important; }
.ssb_header_menu .nav-list { position: relative !important; z-index: 501 !important; }
.et_pb_row_1_tb_header > .et_pb_column_1_tb_header {
  position: relative !important;
  z-index: 502 !important;
  align-self: stretch !important;
  display: -webkit-box !important;
  display: -ms-flexbox !important;
  display: flex !important;
  -webkit-box-align: center !important;
  -ms-flex-align: center !important;
  align-items: center !important;
}
.et_pb_row_1_tb_header > .et_pb_column_1_tb_header::before {
  content: '';
  position: absolute;
  inset: 0;
  background-color: #aad2e6;
  z-index: -1;
  pointer-events: none;
}
.et_pb_row_1_tb_header > .et_pb_column_3_tb_header,
.et_pb_row_1_tb_header > .et_pb_column_4_tb_header {
  position: relative !important;
  z-index: 502 !important;
}
.et_pb_row_1_tb_header > .et_pb_column_2_tb_header {
  position: relative !important;
  z-index: 500 !important;
  -webkit-box-flex: 1 !important;
  -ms-flex-positive: 1 !important;
  flex-grow: 1 !important;
}
.et_pb_row_1_tb_header > .et_pb_column_2_tb_header::before {
  content: '';
  position: absolute;
  inset: 0;
  background-color: #aad2e6;
  z-index: 500;
  pointer-events: none;
}
/*
 * v3 correction: column 2's own position:relative above (needed only so
 * ".nav-list"'s z-index has a stacking context to be promoted relative
 * to) turned column 2 into the nearest POSITIONED ancestor for
 * ".nav-drawer"'s position:absolute — squeezing the drawer back down to
 * column 2's own (now much narrower, see the content-width fix below)
 * box instead of the full header row, undoing the earlier drawer
 * full-width fix. z-index still applies to column 2 without position
 * needing to be non-static — flex/grid items get their own stacking
 * context from a non-auto z-index per spec regardless of position — so
 * overriding back to static here keeps the stacking fix intact while
 * letting ".nav-drawer" skip past column 2 to the row again, exactly
 * like the original drawer full-width fix intended.
 */
.et_pb_row_1_tb_header > .et_pb_column_2_tb_header { position: static !important; }

/*
 * Overlay vertical clip. Rather than continuing to chase every gap
 * between column boxes with more decoys (Divi's own column gutter
 * inserts a ~30px gap between columns 1 and 2 that isn't covered by
 * either column's own box, which was still letting the overlay's dark
 * tint show through on both sides of the logo), this caps the problem
 * at the source: ".nav-overlay" only needs to dim the page BELOW the
 * header, never the header itself, so pinning its top edge to the
 * header's own height (72px, matching ".nav-list" above) means it can
 * never paint inside the header row's own vertical band at all —
 * regardless of column widths, gutters, or gaps. This makes the
 * per-column decoys above technically redundant (harmless to leave in
 * place) but is what actually closes the leak for good.
 */
.ssb_header_menu .nav-overlay { /*top: 72px !important;*/ }

/*
 * Column width fix. Divi laid these out as 4 rigid equal-width (~25%)
 * grid columns, not columns sized to their actual content — so column 1
 * rendered ~706px wide around a 300px-wide logo, leaving ~400px of dead
 * box space to its right before column 2 (nav) even started. That dead
 * space (plus the inter-column gutter) is what read as "nav items too
 * far to the left" relative to marketing, whose logo/nav/utils are each
 * sized to their own content. Fix: let columns 1, 3 and 4 shrink to fit
 * their real content, and let column 2 (nav) absorb 100% of whatever
 * space remains, matching marketing's actual flex model.
 */
.et_pb_row_1_tb_header > .et_pb_column_1_tb_header,
.et_pb_row_1_tb_header > .et_pb_column_3_tb_header,
.et_pb_row_1_tb_header > .et_pb_column_4_tb_header {
  flex: 0 0 auto !important;
  width: auto !important;
  max-width: none !important;
}
.et_pb_row_1_tb_header > .et_pb_column_2_tb_header {
  flex: 1 1 0 !important;
  min-width: 0 !important;
}
/*
 * With column 2 now much wider than its own nav content, the nav needs
 * to be actively centered within it (rather than left-hugging column
 * 2's edge) to land in roughly the same visual spot marketing's nav
 * sits in — centered between the logo and the cart/login pill.
 * ".ssb_header_menu" (the Divi module wrapper, already position:static
 * from the drawer fix above) is given an explicit width:100% because it
 * otherwise shrink-wraps to its own content instead of filling column
 * 2, which would leave justify-content:center nothing to center within.
 */
.ssb_header_menu { display: flex !important; justify-content: center !important; align-items: stretch !important; width: 100% !important; }

/*
 * Header-row width/alignment fix — v2. Divi's cached inline styles (same
 * <style> block as the height/margin-top fix above) also hard-code
 * ".et_pb_row_1_tb_header { justify-content: center; }" — clustering the
 * 4 header columns (logo / nav / cart / login) together in the middle of
 * the row instead of spreading them the way marketing's own flex header
 * (logo flush left, nav right after it, utils flush right) does. That
 * alone left ~180px of dead space on the left and ~200px on the right at
 * typical desktop widths, which is most of what read as "widths/spacing
 * ... off" — not any single element being sized wrong, but the whole row
 * floating in the middle of its available space.
 *
 * v1 used justify-content:space-between across all 4 columns, which
 * spread logo/nav/cart/login into 3 roughly-equal gaps — but marketing
 * doesn't distribute space that way: it has only 2 real flex children
 * (the nav, and a single ".header-utils" wrapper holding cart+login
 * flush together with a small fixed 16px gap), so only ONE big gap
 * exists, between the nav and header-utils. Splitting shop's cart and
 * login into 3 even gaps was what was pulling them visibly apart from
 * each other (reported as "login and cart status buttons... not together
 * like they are on marketing").
 *
 * Fix: switch to justify-content:flex-start and let column 2 (nav) grow
 * to consume the remaining space instead. Nav's own content still hugs
 * the LEFT edge of its (now much wider) column — Divi's default
 * justify-content:normal on that column behaves as flex-start — so the
 * nav links land in the same place as before, right after the logo.
 * With nothing left to distribute, columns 3 and 4 (cart, login) simply
 * sit flush against each other and against the row's right edge, exactly
 * like marketing's single header-utils block. This also makes the
 * earlier clearfix-pseudo-element fix (disabling
 * ".et_pb_row_1_tb_header::after", left over from Divi's original
 * float-based row layout, which becomes a real invisible flex item once
 * the row is display:flex) unnecessary for spacing, but it's left in
 * place as a harmless no-op guard.
 *
 * Finally, the row's own left/right padding is a separate Divi cached
 * rule — "html body .et_pb_row_1_tb_header.et_pb_row { padding:0 0 10px;
 * !important }" (2 classes + !important) — which a bare
 * ".et_pb_row_1_tb_header" (1 class) can't outrank even with !important
 * of its own, same specificity-tie pattern as the drawer-link color fix
 * near the top of this file. Matching its compound selector (scoped
 * under the stable ".ssb_header_section" ancestor class for a safety
 * margin) sets padding-left:24px to match marketing's logo inset, while
 * also zeroing the stray 10px bottom padding that would otherwise have
 * reintroduced a small vertical asymmetry on top of the row-height fix
 * above.
 */
.et_pb_row_1_tb_header { justify-content: flex-start !important; }
.et_pb_row_1_tb_header::after { display: none !important; }
.ssb_header_section .et_pb_row_1_tb_header.et_pb_row { padding: 0 0 0 24px !important; }

/*
 * Shop-specific header chrome the user asked to hide — not part of the
 * nav bundle, and not present on marketing at all. #ssb-banner-message
 * is shop's own top announcement banner container; the section below
 * targets the empty dark code-module section sitting above it (see
 * rest-nav.php's earlier diagnosis: this section renders at a nonzero
 * height purely from base line-height on whitespace content, not from
 * anything we inject). Both are unique to this one Theme Builder header
 * template, not reused elsewhere on shop, so hiding them here is safe.
 *
 * #ssb-banner-message is boosted with "html body" ancestor selectors
 * because a separate inline <style id="ssb-banner-css"> block in <head>
 * (added elsewhere, not part of this file) forces it back with
 * "#ssb-banner-message, .ssb-banner-message { display: block !important; }".
 * That rule has the same specificity as a bare ID selector and loads
 * after this stylesheet, so it was winning the cascade tie on source
 * order. Chaining "html body" ahead of the ID raises our specificity
 * above theirs, so this wins regardless of load order — no need to
 * find or edit wherever that other style block comes from.
 */
/* html body #ssb-banner-message { display: none !important; }
.et_pb_section_0_tb_header { display: none !important; } */

/*
 * Drawer full-width fix. .ssb_header_menu (the Divi module wrapper) has
 * its own position:relative (Divi's base module style), which makes it
 * the containing block for .nav-drawer's position:absolute; left:0;
 * right:0 — squeezing the drawer down to just this narrow column-width
 * module instead of spanning the full header row like on marketing.
 * Overriding to position:static here lets the drawer's containing block
 * resolve to the next positioned ancestor up — .et_pb_row_1_tb_header,
 * which is the full-width row — so the drawer spans the whole header
 * again. Scoped to this one hand-set class; safe since we fully control
 * everything rendered inside .ssb_header_menu (Divi's own submenu
 * system for this module was already replaced wholesale).
 */
.ssb_header_menu { position: static !important; }

/*
 * Cart + login "pill" to match marketing's header-right chrome. On
 * marketing this is one flex box (.header-utils: bg #7dc5a8, full
 * header height, 24px side padding, 16px gap between icon and button)
 * wrapping both the cart icon and the login button. Shop builds cart
 * and login as two separate, directly-adjacent Divi columns (verified
 * zero gap between them live) instead of one wrapper element, so the
 * same look is recreated by coloring both columns the same green,
 * stretching each to the row's full height, and centering their
 * content — two flush same-color rectangles read as one. Anchored via
 * :has() on the stable .lwp_cart_module / .ssb_header_button classes
 * inside each column rather than Divi's auto-numbered column classes,
 * so this survives a Theme Builder rebuild the same way the nav-menu
 * fixes above do.
 */
.et_pb_row_1_tb_header .et_pb_column:has(.lwp_cart_module),
.et_pb_row_1_tb_header .et_pb_column:has(.ssb_header_button) {
  background-color: #7dc5a8 !important;
  align-self: stretch !important;
  display: flex !important;
  align-items: center !important;
}
/*
 * v2: inner padding trimmed from 8px to 3px on each side. Measured live
 * against marketing's own cart-icon-to-login-button gap (16px) — shop's
 * cart icon and login button markup carry ~10px of their own built-in
 * spacing that marketing's don't, so matching the OUTER column padding
 * 1:1 to marketing's 8px overshot the real 16px target; 3px+3px (plus
 * that ~10px already baked into the elements themselves) lands on 16px.
 */
.et_pb_row_1_tb_header .et_pb_column:has(.lwp_cart_module) { padding: 0 3px 0 24px !important; }
.et_pb_row_1_tb_header .et_pb_column:has(.ssb_header_button) { padding: 0 24px 0 3px !important; }

/*
 * Login button itself: shop's own style is a transparent pill with a
 * white outline (border-radius:100px). Marketing's is a solid white
 * button with dark text, square-ish corners, uppercase bold label —
 * matched here property-for-property from marketing's live computed
 * .btn-login styles.
 *
 * color needs its own boosted-specificity rule below: shop has a
 * separate pre-existing inline rule — ".ssb_header_button { ...
 * color:white !important; }" (1 class, !important) — that ties on
 * specificity with a bare ".ssb_header_button" of our own and wins the
 * tie on source order, since it loads later in <head>. That left the
 * button rendering as invisible white text on our new white background.
 * Scoping under the stable ".ssb_header_w" wrapper div (always present
 * around this link) brings it to 2 classes, beating the tie outright —
 * same specificity pattern used throughout this file.
 */
.ssb_header_button {
  background-color: #ffffff !important;
  padding: 8px 24px !important;
  border-radius: 4px !important;
  border: none !important;
  font-weight: 600 !important;
  font-size: 14px !important;
  text-transform: uppercase !important;
}
.ssb_header_w .ssb_header_button { color: #2e3d42 !important; }
.ssb_header_button:hover { opacity: 0.85 !important; }

/*
 * Header logo. Shop still has its own old Divi Image module pointing at a
 * local media-library asset (wp-image-39, ssb_logo_white.svg, 636x84) — it
 * isn't part of the synced nav bundle at all (marketing's logo is WordPress's
 * native custom_logo, a completely separate mechanism), so it was never
 * getting updated when marketing's logo changed. Rather than touching Divi's
 * Theme Builder module (would need WP admin access, and a DB-stored Builder
 * layout isn't part of this static-file workflow), this repoints the
 * rendered image via the CSS "content: url()" replaced-element trick, which
 * Chrome/Firefox support for <img>. Deliberately NOT setting width/height
 * here: this element's CSS width is already responsive (Divi module width),
 * and with only width constrained, the browser derives height from the
 * REPLACEMENT image's own intrinsic aspect ratio (1500x84 wide-format PNG,
 * ~9.74:1) rather than the original SVG's (636x84, ~7.57:1) — confirmed live
 * that this renders at the exact same box size marketing's own <img> does at
 * the same width, no distortion. If marketing's logo file changes again,
 * only this URL needs updating.
 */
.et_pb_row_1_tb_header img.wp-image-39 { content: url('https://staging.seattlespermbank.com/wp-content/uploads/2026/06/ssb_logo_wide_white.png') !important; }

/*
 * Native sticky header — CSS only, no JS. Replaces Divi's own JS-driven
 * "sticky module" (sticky-elements.js, part of Divi CORE, not this
 * bundle or the SSB2020 child theme), which manually toggled
 * position:fixed via inline styles on scroll and produced a visible
 * "jump" each time it fired. The user disabled that feature's Divi
 * Builder toggle (Advanced > Scroll Effects > Sticky) on this row/
 * section directly, which stops the JS but — on its own — leaves the
 * header not sticking at all. Marketing avoids the jump entirely by
 * using plain CSS position:sticky; this recreates that natively.
 *
 * Two things had to be fixed together for this to actually work, found
 * by testing live in-browser (a bare position:sticky on #ssb_header
 * silently did nothing, despite computing correctly):
 *
 * 1. TARGET ELEMENT. #ssb_header's own immediate wrapper chain
 *    (".et_builder_inner_content", then the outer <header class="et-l
 *    et-l--header">) are BOTH sized to exactly 72px — i.e. exactly the
 *    header's own height, with zero extra room. A sticky element can
 *    never travel further than its own containing block's bounds allow,
 *    so making #ssb_header itself sticky gave it a 72px-tall containing
 *    block to stick within — meaning zero visible travel, i.e. it
 *    never appeared to stick at all. One level further up, the <header>
 *    tag's own containing block is "#et-boc" (the real page-content
 *    wrapper, thousands of pixels tall) — plenty of room. Moving the
 *    sticky declaration to the <header> element itself (and explicitly
 *    un-stickying #ssb_header, in case Divi's own now-inert
 *    ".et_pb_section_sticky" class — still present in the markup, just
 *    no longer JS-driven — tries to apply its own position from Divi's
 *    core CSS) fixes this.
 *
 * 2. SCROLL CONTAINER. Separately, "#page-container" (a site-wide
 *    wrapper around all page content, not part of the header/nav at
 *    all) ships with overflow-y:hidden. Per spec, ANY ancestor with a
 *    non-visible overflow — even one that isn't the element actually
 *    scrolling the page — becomes the reference "scroll container" a
 *    sticky descendant is measured against; with a non-scrolling
 *    overflow:hidden ancestor in the chain, the browser had nothing
 *    valid to stick relative to. Overriding just its Y-axis to visible
 *    (leaving overflow-x alone, presumably there to prevent full-bleed
 *    sections from causing a horizontal scrollbar) resolves this;
 *    confirmed live afterward that no horizontal scrollbar appears.
 *    This is a site-wide selector rather than one scoped under
 *    ".ssb_header_menu" like the rest of this file, since the element
 *    it targets isn't part of the header or nav at all — flagged here
 *    for visibility if anything on another template ever relied on
 *    #page-container clipping vertical overflow.
 */
#ssb_header { position: static !important; }
header.et-l--header { top: 0 !important; z-index: 500 !important; }
#page-container { overflow-y: visible !important; }

/*
 * Pixel-perfect pass (v14) — four fine calibrations against marketing's
 * live header, measured with getBoundingClientRect() rather than eyeballed,
 * since the earlier fixes above got the structure right but left small
 * offsets.
 *
 * 1. LOGO VERTICAL POSITION. Shop's replacement logo image (see the
 *    content:url() swap above) rendered 5.33px lower than marketing's own
 *    <img> at the same width — a byproduct of the two images' different
 *    intrinsic aspect ratios (1500x84 vs marketing's native file) combined
 *    with how each one's height gets derived and vertically placed inside
 *    the 72px row. translateY(-5.33px) was measured to land it at the
 *    exact same y-coordinate as marketing's logo (confirmed live,
 *    <0.01px difference) — the user's own eyeballed "-10px" estimate
 *    overshot this by about 4.7px.
 */
.et_pb_row_1_tb_header img.wp-image-39 { transform: translateY(-5.33px) !important; }

/*
 * 2. LOGIN BUTTON LETTER-SPACING. Marketing's .btn-login has letter-spacing
 *    applied (computes to 0.84px); shop's .ssb_header_button had none.
 *    Added per the user's own specified value.
 */
.ssb_header_button { letter-spacing: 1px !important; }

/*
 * 3. CART ICON + SPACING. Two separate problems bundled together:
 *
 *    a) ICON MISMATCH. Marketing's cart control (".cart-icon", not part of
 *       the synced nav bundle — it's a separate header-utils element) is a
 *       hand-authored inline SVG: an outline shopping-cart line drawing with
 *       two small wheel dots. Shop's ".lwp_cart_icon" is WooCommerce/Divi's
 *       own icon-font glyph (ETmodules font, literal char U+E07A rendered as
 *       the span's own text content) — a solid filled cart silhouette, a
 *       visibly different shape from marketing's. Since this is real text
 *       content (not a ::before-generated glyph), it's hidden via
 *       color:transparent (keeping its box for layout) and a ::before
 *       pseudo-element is given a background-image of marketing's exact SVG
 *       (re-encoded as a base64 data URI, stroke/fill hardcoded to white
 *       since this pill's icon is always white-on-green here), sized to
 *       match marketing's 22x22 box exactly.
 *
 *    b) VERTICAL OVERFLOW / ALIGNMENT. Separately, shop's icon span itself
 *       was 26x26 while its own immediate wrapper (".image_wrap") was only
 *       18.67px tall — the glyph was overflowing 10px above its own
 *       wrapper's box, a real (if usually invisible, since nothing clipped
 *       it) misalignment bug. Explicitly sizing the icon to 22x22 (matching
 *       marketing's real SVG box) resolves this as a side effect of the
 *       icon swap above.
 *
 *    c) SPACING. padding-right:5px on the cart link itself (stacked on top
 *       of the existing column's own 3px right padding from the cart/login
 *       pill fix above) tightens the icon-to-login-button gap. Measured
 *       live: this lands the gap at exactly 16.00px, matching marketing's
 *       own cart-icon-to-login-button gap precisely — per the user's own
 *       specified value.
 */
a.lwp_cart_module { padding-right: 5px !important; }
.lwp_cart_icon.et-pb-icon {
  color: transparent !important;
  position: relative !important;
  width: 22px !important;
  height: 22px !important;
  vertical-align: middle !important;
}
.lwp_cart_icon.et-pb-icon::before {
  content: '' !important;
  position: absolute !important;
  left: 0 !important;
  top: 0 !important;
  width: 22px !important;
  height: 22px !important;
  background-image: url("data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSIyMiIgaGVpZ2h0PSIyMiIgdmlld0JveD0iMCAwIDIyIDIyIiBmaWxsPSJub25lIj48cGF0aCBkPSJNMSAxaDNsMiAxMGgxMWwyLTdINSIgc3Ryb2tlPSJ3aGl0ZSIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0cm9rZS1saW5lY2FwPSJyb3VuZCIgc3Ryb2tlLWxpbmVqb2luPSJyb3VuZCIvPjxjaXJjbGUgY3g9IjkiIGN5PSIxOSIgcj0iMS41IiBmaWxsPSJ3aGl0ZSIvPjxjaXJjbGUgY3g9IjE3IiBjeT0iMTkiIHI9IjEuNSIgZmlsbD0id2hpdGUiLz48L3N2Zz4=") !important;
  background-repeat: no-repeat !important;
  background-size: 22px 22px !important;
}

/*
 * 4. NAV POSITION. The nav-list's own centering-within-column-2 math (see
 *    the "column width fix" above) lands it close to marketing's real nav
 *    position but not exactly on top of it. translate(-15px, -1px) — the
 *    user's own specified values — was verified live to land the nav-list
 *    within 0.4px horizontally and 0.67px vertically of marketing's own
 *    nav-list box, near enough to be sub-pixel/rounding noise.
 *
 *    Safety note: .nav-drawer is a SIBLING of .primary-nav (both children
 *    of .ssb_header_menu), not a descendant of .nav-list — so this
 *    transform does NOT give .nav-drawer a new containing block and cannot
 *    reintroduce the drawer-width regression fixed above. Confirmed live
 *    by force-opening a drawer (.is-open) with this transform active: it
 *    still spans the full 2544px row width, unchanged.
 */
.nav-list { transform: translate(-15px, -1px) !important; }

/*
 * Header box-shadow. On marketing this lives on "header#site-header"
 * itself: "box-shadow: 0px 0px 7px rgba(0,0,0,0.6);" — a soft all-around
 * glow, not an offset drop shadow (0 0 blur, no spread). Shop's equivalent
 * element is "header.et-l--header" (the same element made position:sticky
 * above), which had no shadow at all. Applying it there means it also
 * stays correctly attached while the header is pinned during scroll —
 * confirmed live by scrolling and checking the shadow persists alongside
 * the sticky positioning, matching marketing's own always-visible glow.
 */
header.et-l--header { box-shadow: 0px 0px 7px rgba(0,0,0,0.6) !important; }

/*
 * Mobile header (v16). Confirmed live at a true 430px viewport (Chrome
 * device toolbar, not a resized window — window.innerWidth actually
 * reporting 430) using getBoundingClientRect()/getComputedStyle() checks
 * plus direct on-screen zoom captures, not guesswork. Two distinct bugs,
 * both only reachable below 991px:
 *
 * 1. HEADER WRAPS TO TWO ROWS. ".et_pb_row_1_tb_header" is Divi's stock
 *    4-column desktop row (logo | menu | cart | login), flex-wrap:wrap,
 *    with each column still sized for desktop (measured: 300px + 106px +
 *    107px + 139px = 652px of content trying to fit a 430px-wide mobile
 *    viewport). It has no Divi-provided mobile column-width rules of its
 *    own (those only exist for ".et_pb_column_1_4" generic grid classes,
 *    which these four don't carry), so nothing was shrinking it — the row
 *    wrapped, dropping cart+login onto their own second line below a
 *    full-height logo row. Marketing never hits this because its mobile
 *    header isn't Divi's column grid at all — it's a purpose-built single
 *    row (".header-inner"/".header-left"/".header-utils", height:60px)
 *    that doesn't exist in shop's DOM. Fix: force nowrap, fix the row
 *    height to marketing's own 60px, shrink the logo image (measured
 *    140px keeps everything on one line with zero horizontal overflow —
 *    verified via document.body.scrollWidth === 430, i.e. exactly zero
 *    px of overflow, not just "no visible scrollbar"), and tighten the
 *    cart/login columns' padding using the exact ":has()" selectors the
 *    existing desktop rules use (a plain class selector at the same
 *    specificity loses the cascade tie to those, since ":has()" counts
 *    the specificity of its argument too — confirmed by inspecting
 *    document.styleSheets directly rather than assuming).
 *
 * 2. THE HAMBURGER ICON WAS INVISIBLE. Not a screenshot artifact — proved
 *    live by giving ".nav-toggle" itself a hardcoded red background with
 *    "!important" and confirming on-screen that literally nothing
 *    changed, while an unrelated red test div at the same coordinates
 *    rendered fine. Root cause: ".et_pb_column_2_tb_header" (the menu
 *    column housing the toggle) is forced "position:static !important"
 *    unconditionally (the "v3 correction" above, needed so
 *    ".nav-drawer" escapes to the row for its full-width fix). Its own
 *    "::before" decoy patch (originally sized to just that column, used
 *    to block the desktop dropdown-hover overlay from bleeding through)
 *    has "position:absolute; inset:0" — with the column no longer
 *    positioned, that decoy escapes to the next positioned ancestor,
 *    which is the sticky header itself. Measured live: the decoy's
 *    computed box was 430px × 60px at top:0/left:0 — the ENTIRE header,
 *    not the ~40px column — painted at z-index:500 in the header's own
 *    background color (#aad2e6), silently papering over the toggle
 *    underneath. This never showed up on desktop because the toggle is
 *    "display:none" there anyway, and the real desktop nav list sits at
 *    z-index:501 (one above the decoy) so it was never actually covered
 *    — mobile is the only width where something under the decoy (the
 *    toggle) both renders AND has no elevated z-index of its own. Fix:
 *    the decoy exists purely to guard the desktop-only dropdown overlay
 *    (".nav-overlay"), which cannot fire on mobile — ".primary-nav" and
 *    ".nav-drawer" (what would trigger it) are both already
 *    "display:none" below 991px — so disabling the decoy at this
 *    breakpoint is safe and reintroduces nothing.
 */
@media (max-width: 991px) {
  .et_pb_row_1_tb_header { flex-wrap: nowrap !important; align-items: center !important; height: 60px !important; }
  .et_pb_row_1_tb_header > .et_pb_column_1_tb_header { padding: 0 0 0 10px !important; flex: 0 0 auto !important; order: 2 !important; }
  .et_pb_column_1_tb_header .et_pb_image { width: 135px !important; }
  .et_pb_column_1_tb_header .et_pb_image img { width: 135px !important; height: auto !important; }
  .et_pb_row_1_tb_header > .et_pb_column_2_tb_header { flex: 0 0 auto !important; width: auto !important; order: 1 !important; }
  .et_pb_row_1_tb_header > .et_pb_column_2_tb_header::before { display: none !important; }
  .et_pb_row_1_tb_header .et_pb_column:has(.lwp_cart_module) { padding: 0 6px !important; order: 3 !important; }
  .et_pb_row_1_tb_header .et_pb_column:has(.ssb_header_button) { padding: 0 6px !important; order: 4 !important; }
}
/*
 * v17 correction: the hamburger needs to sit BEFORE the logo on mobile,
 * matching marketing's actual order (hamburger, logo, ...cart, login) —
 * v16 above left it in shop's native DOM order (logo, hamburger) since
 * that wasn't flagged yet. Reordered visually via flex "order" (DOM order
 * is untouched, since the toggle markup is part of the live-synced nav
 * bundle, not something this file should have to fight positionally).
 * The 10px left padding on column 1 (logo) — rather than margin-right on
 * column 2 (toggle) — is deliberate: Divi's own core stylesheet carries
 * ".et_pb_gutters1 .et_pb_column { margin: 0 !important; }" at
 * max-width:479px, which ties our margin override on specificity and, in
 * practice, wins it; column 1's padding isn't touched by that rule, so
 * padding is what actually produces the gap. Verified live: 430px
 * viewport, zero horizontal overflow (document.body.scrollWidth === 430),
 * toggle still opens/closes the offcanvas nav correctly in its new visual
 * position.
 */
/*
 * v18: offcanvas "Close" button was invisible/unreachable when the drawer
 * was open — found while checking the drawer for other nav-vs-marketing
 * mismatches, not reported by the user. Root cause, confirmed live via
 * document.elementsFromPoint(): ".offcanvas-nav" (the drawer, position:
 * fixed, z-index:700) is a DOM descendant of column 2 (the menu column).
 * Column 2 is a flex item of ".et_pb_row_1_tb_header" with z-index:500
 * set (needed on desktop for the dropdown-hover nav) — z-index applies to
 * flex items even at position:static, so column 2 establishes its own
 * stacking context. A position:fixed element escapes an ancestor for
 * LAYOUT, but NOT for PAINT ORDER if that ancestor establishes a stacking
 * context — so the drawer, despite being "fixed" and z-index:700, is
 * trapped inside column 2's context and can only ever paint as high as
 * column 2's own slot (500) among ITS SIBLINGS. Column 1 (the logo) sits
 * at z-index:502 — just above column 2 — so the logo was painting over
 * the drawer's own header/close-button band (~80px) every time it opened;
 * confirmed via elementsFromPoint() returning the logo <img> above
 * ".offcanvas-nav__header" at that point, and the ".offcanvas-nav__close"
 * button was genuinely unclickable there, not just hard to see. The menu
 * items further down were unaffected since they fall outside the header's
 * own height. Fix: column 2 only needs z-index:500 for the desktop
 * dropdown-hover overlay ordering (see the original comment above); on
 * mobile the dropdown drawer is already "display:none", so raising column
 * 2 well above its siblings for this breakpoint is safe and lets its
 * whole subtree — including the offcanvas panel — paint above the rest of
 * the header while open. Verified live: close button now sits topmost at
 * the same point the logo previously won, and clicking it correctly
 * closes the drawer (".offcanvas-nav" loses "is-open").
 */
@media (max-width: 991px) {
  .et_pb_row_1_tb_header > .et_pb_column_2_tb_header { z-index: 9999 !important; }
}
/*
 * v19: user-directed — remove the row's left inset entirely so the
 * hamburger sits flush against the screen edge (marketing has no left
 * inset on its mobile header either), enlarge the logo now that there's
 * more room, and close up the dead space that was sitting to the right
 * of the login button.
 *
 * That trailing gap wasn't a padding problem — it's that all four
 * columns are "flex:0 0 auto" (their own content width, no growing), so
 * once their combined width comes in under 430px the row's default
 * "justify-content:flex-start" just leaves the shortfall as empty space
 * after the last column, rather than anything actually pushing the
 * cart/login pair to the true right edge. Marketing's own mobile header
 * doesn't have this problem because it isn't four independent flex
 * items — logo+toggle are one grouped block on the left, cart+login are
 * a second grouped block on the right, laid out with space-between.
 * Rather than re-deriving the exact px shortfall by hand (fragile —
 * breaks again the next time any column's content width changes),
 * "margin-left:auto" on the cart column reproduces that same
 * space-between behavior directly: it consumes 100% of whatever
 * leftover width the row has, right before the cart/login pair, which
 * pins that pair to the row's true right edge regardless of how the
 * other three columns end up sized. Login's own right padding (11px,
 * down from the earlier 12px to land the row at exactly 430px with zero
 * overflow) is what's now standing in for marketing's own 12px
 * ".header-utils" right-edge inset at this width (max-width:575px, per
 * marketing's own CSS) — so the pair sits close to the edge like
 * marketing's, not glued to px 0.
 *
 * Verified live: document.body.scrollWidth === 430 (zero overflow, not
 * just "no visible scrollbar"), login's own right edge lands at column
 * width 430px exactly.
 */
@media (max-width: 991px) {
  .ssb_header_section .et_pb_row_1_tb_header.et_pb_row { padding-left: 0 !important; }
  .et_pb_column_1_tb_header .et_pb_image { width: 160px !important; }
  .et_pb_column_1_tb_header .et_pb_image img { width: 160px !important; height: auto !important; }
  .et_pb_row_1_tb_header .et_pb_column:has(.lwp_cart_module) { margin-left: auto !important; padding: 0 6px 0 6px !important; }
  .et_pb_row_1_tb_header .et_pb_column:has(.ssb_header_button) { padding: 0 11px 0 6px !important; }
}

/*
 * v20: root-cause fix for a page-by-page nav breakage the user first spotted
 * on /donors/ — the logo disappearing on mobile, and (once they widened
 * their browser to look) the "Find a Donor" mega-menu (and the mobile
 * offcanvas equivalent) rendering with invisible white-on-white link text.
 * Both traced back to the SAME mechanism, confirmed live by diffing
 * document.styleSheets between /donors/ and the shop home page.
 *
 * Divi caches a per-page/per-template <style> block in <head> for each
 * Theme Builder module ("id starts et-builder-module-design-…", already
 * called out near the top of this file for a different, page-independent
 * rule) — but unlike that earlier case, this block's own SELECTOR SHAPE
 * itself turns out to vary page-to-page, not just its values. On the shop
 * home page, Divi cached a low-specificity version of its own "hide the
 * logo column" and "force menu links white" rules (bare classes, e.g.
 * ".et_pb_column_1_tb_header"), which the rules below in this file (2-3
 * classes, !important) already outrank. On /donors/ — an archive/search
 * template, not a plain Divi Page like home — Divi cached a DIFFERENT,
 * higher-specificity version of the same rules, prefixed with the real
 * page id selector ("html body #et-boc …" / ".et-db #et-boc .et-l …"),
 * which beats every fix above that relies on stacking a few extra classes,
 * even with !important on both sides — a tie goes to the higher ID count,
 * and shop's fixes above use zero.
 *
 * Since #et-boc (the page's own real content wrapper — already relied on
 * elsewhere in this file for the sticky-header scroll-container fix) and
 * #page-container (its parent, also already relied on above) are both
 * real, permanent, always-present ancestor IDs on every Theme Builder
 * page regardless of which page/template generated Divi's cache, chaining
 * both ahead of the existing selectors gives these two rules 2 IDs of
 * their own — which outranks ANY single-ID variant Divi might cache on
 * ANY page, present or future, without needing to know or chase the exact
 * shape of whichever variant a given page happens to have. This is a
 * strictly additive fix (existing rules above are untouched and still do
 * their job on pages where they already win); these are only the specific
 * properties confirmed broken by the higher-specificity variant:
 *
 * 1. Logo column display (mobile only — matches Divi's own media-query
 *    scoping on its cached rule, confirmed live at /donors/'s real 430px
 *    viewport: column was "display:none", hiding the logo entirely and,
 *    as a side effect, letting the hamburger column expand to fill the
 *    whole row and shove cart+login off the right edge of the screen).
 *
 * 2. Nav-drawer / offcanvas-panel link text color (all widths — Divi's
 *    competing rule targets "ul li a" unconditionally, no media query).
 *    Covers both the desktop hover mega-menu (.nav-drawer__link and the
 *    "--top" variant) and the mobile offcanvas's own expandable
 *    sub-panels (.offcanvas-nav__drawer …), since both reuse the same
 *    underlying <ul><li><a> markup Divi's rule matches. Verified live on
 *    /donors/: reproduced Divi's exact competing selector directly via
 *    injected <style>, confirmed these rules still win against it, then
 *    confirmed the real hover-triggered dropdown and the real offcanvas
 *    sub-panel both render dark, readable text.
 */
@media (max-width: 991px) {
  #page-container #et-boc .et_pb_row_1_tb_header > .et_pb_column_1_tb_header {
    display: -webkit-box !important;
    display: -ms-flexbox !important;
    display: flex !important;
  }
}
#page-container #et-boc .ssb_header_menu .nav-drawer__group .nav-drawer__link,
#page-container #et-boc .ssb_header_menu .nav-drawer__link.nav-drawer__link--top,
#page-container #et-boc .ssb_header_menu .offcanvas-nav__drawer .nav-drawer__col-title a,
#page-container #et-boc .ssb_header_menu .offcanvas-nav__drawer .nav-drawer__group-title a,
#page-container #et-boc .ssb_header_menu .offcanvas-nav__drawer .nav-drawer__link {
  color: #2e3d42 !important;
}

/*
 * v21: found while re-verifying v20 live on /donors/ at a true 430px
 * viewport (the user caught this — v20 fixed desktop, but mobile still
 * only showed the hamburger). The logo column's "display" was correctly
 * flex again (v20 worked), but it was rendering completely off-screen —
 * column 2 (the hamburger/menu column, "order:1" so it sits first) had a
 * computed width of 430px, the FULL row, instead of its own ~40px
 * content width. With column 2 alone consuming the entire row, column 1
 * (logo, "order:2") had nowhere left to lay out but past the right edge.
 *
 * Root cause is the same class of bug as v20, but a different source this
 * time: not Divi's per-page cached <head> <style> block, but Divi's own
 * STATIC CSS FILE GENERATION feature (a real performance feature —
 * Divi precompiles only the CSS a given page's modules actually use into
 * a dedicated file per page/template). Confirmed live by diffing
 * document.styleSheets between /donors/ and shop home again: both load a
 * generated file containing Divi core's own responsive column rule
 * (".et_pb_column { width:100% !important }" at max-width:479px, part of
 * Divi's default "stack columns full-width on small phones" behavior) —
 * but home's generated file has it as a bare class (0 IDs), while
 * /donors/'s has the exact same rule prefixed with the real page wrapper
 * IDs (".et-db #et-boc .et-l .et_pb_column"), presumably because the two
 * files were generated by Divi at different times/settings. Same fix as
 * v20: chain #page-container #et-boc ahead of the existing selector to
 * guarantee at least 2 IDs of our own, beating any single-ID variant
 * Divi's generator produces on any page. Verified live via the same
 * reproduce-the-competing-selector-and-check-computed-value method used
 * for v20 (real viewport resize isn't available in this environment, and
 * the property loses/wins purely on selector specificity regardless of
 * viewport, so this is a faithful test).
 */
@media (max-width: 991px) {
  #page-container #et-boc .et_pb_row_1_tb_header > .et_pb_column_2_tb_header {
    flex: 0 0 auto !important;
    width: auto !important;
  }
}

/*
 * v22: same Divi static-CSS-file width:100% collision as v21, but on the
 * OTHER three columns. After v21 the hamburger column was fixed and the
 * logo came back into view, but the row still didn't match home —
 * screenshot showed the cart icon and, worse, the LOG IN button missing
 * entirely. Measured live: columns 3 (cart) and 4 (login) were BOTH still
 * computing to the full 430px row width and sitting off-screen (login's
 * own box started at x:590, ~160px past the right edge) — the exact same
 * failure shape as v21's column 2, just on the two columns after it.
 *
 * Column 1 (logo) was, oddly, unaffected by this same collision even
 * though it shares the identical un-boosted rule with columns 3/4 (all
 * three are one grouped selector further up this file) and matches Divi's
 * exact same competing selector — measured live, its width still
 * resolved correctly (~120-170px) while 3/4 didn't. Rather than chase
 * why one column of three sharing a rule wins and the other two don't
 * (a real question, but not one that changes what needs fixing), this
 * applies the same #page-container #et-boc specificity floor used for
 * v20/v21 to all three columns uniformly — cheap, harmless on the column
 * that was already winning, and removes any dependency on whatever made
 * column 1 different. Verified live: with this rule injected, columns 1/
 * 3/4 all resolved to real content-based widths (no more 430px/100%),
 * and a full-page screenshot at /donors/'s real 430px viewport now
 * matches shop home's mobile header exactly — hamburger, logo, cart,
 * LOG IN, one row, zero horizontal overflow
 * (document.body.scrollWidth === 430).
 */
@media (max-width: 991px) {
  #page-container #et-boc .et_pb_row_1_tb_header > .et_pb_column_1_tb_header,
  #page-container #et-boc .et_pb_row_1_tb_header > .et_pb_column_3_tb_header,
  #page-container #et-boc .et_pb_row_1_tb_header > .et_pb_column_4_tb_header {
    flex: 0 0 auto !important;
    width: auto !important;
    max-width: none !important;
  }
}

/*
 * v23: with v20-v22 deployed, /donors/ mobile's header now matches home's
 * column widths/positions exactly, but a side-by-side property-by-property
 * diff (row + all 4 columns: display, width, height, order, flex-grow/
 * shrink/basis, all padding/margin sides, align-self, position, z-index,
 * background-color) turned up one more real mismatch: columns 1, 3, and 4
 * compute to height:50px on /donors/ vs height:60px on home, even though
 * the row itself is 60px tall on both and align-self:stretch is identical
 * on both. Column 2 (hamburger, 32px) is unaffected on both — it never
 * relies on stretch since it has its own fixed height.
 *
 * Root cause: the row's own padding-bottom. Home's row computes
 * padding: 0 0 0 0 (all zero) at this width. /donors/'s row computes
 * padding-bottom: 10px — 60px row height minus 10px bottom padding
 * leaves exactly 50px of content-box for a stretched child to fill,
 * which is exactly what was measured. An earlier desktop-only fix already
 * in this file (.ssb_header_section .et_pb_row_1_tb_header.et_pb_row
 * { padding: 0 0 0 24px !important; }, unconditional/not media-scoped)
 * was clearly meant to zero this out globally, but a Divi-generated
 * per-page variant with higher specificity is reasserting
 * padding-bottom:10px on /donors/ specifically at mobile widths — the
 * same recurring per-page specificity-variance bug as v20/v21/v22, this
 * time hitting the row's padding instead of a column's display/width.
 *
 * Note this file intentionally does NOT touch padding-left here: both
 * /donors/ and home already compute padding-left:0 on the row at mobile
 * widths (the 24px desktop value doesn't carry to mobile on either page),
 * so only padding-bottom is a real discrepancy — copying the old rule's
 * "0 0 0 24px" wholesale would have introduced a NEW mismatch instead of
 * fixing one. Verified live via the same #page-container #et-boc
 * specificity-floor pattern used in v20-v22, targeting padding-bottom
 * only: /donors/'s row padding-bottom goes from 10px to 0px (matching
 * home), and columns 1/3/4 all correctly grow to the full 60px row
 * height (matching home) with zero effect on padding-left or on any
 * other already-correct property. Confirmed via screenshot at /donors/'s
 * real 430px viewport that the header now matches home's mobile header
 * exactly.
 */
@media (max-width: 991px) {
  #page-container #et-boc .et_pb_row_1_tb_header.et_pb_row {
    padding-bottom: 0 !important;
  }
}

/*
 * v24: two more /donors/ vs home mismatches reported after v23 — one on
 * mobile ("nav extends behind the header"), one on desktop ("sizing and
 * spacing issues").
 *
 * MOBILE (z-index): when the offcanvas nav drawer is opened on /donors/,
 * home's own header content (logo/cart/login) is supposed to disappear,
 * replaced by the drawer's own compact "X CLOSE" bar — the drawer is a
 * position:fixed, full-viewport overlay meant to sit on top of
 * everything. On /donors/ it wasn't: the real logo/cart/login stayed
 * visible ON TOP of the open drawer. Both the drawer's z-index (700) and
 * the header's z-index (500) computed identically on both pages, so this
 * wasn't a simple "raise the number" fix — raising the drawer's z-index
 * arbitrarily high (tested live up to the CSS max, 2147483647) made no
 * difference. Root cause: the header row (.et_pb_row_1_tb_header) is a
 * flex container, and per the flexbox spec flex ITEMS honor z-index for
 * stacking even when position:static — so the row's 4 columns each
 * form their own local stacking layer at the row level. The drawer lives
 * inside column 2 (the hamburger/menu column); column 2's own z-index
 * (not the drawer's) is what determines whether column 2's entire
 * subtree — including the fixed drawer nested inside it — can paint
 * above a sibling column. On home, column 2 computes z-index:9999,
 * comfortably above column 1/3/4's z-index:502, so the drawer (and
 * everything else in column 2) wins. On /donors/, column 2 computes
 * z-index:90 — another instance of the same recurring per-page Divi
 * specificity variance this file has been chasing since v20 — so column
 * 1/3/4 (logo/cart/login, still at 502) painted ABOVE column 2's entire
 * subtree, drawer included, regardless of the drawer's own z-index.
 * Verified live: boosting column 2's z-index alone (to match home's
 * 9999) fixes it — document.elementsFromPoint at the logo/cart/hamburger
 * positions all correctly resolve to the open drawer afterward, with no
 * visible change in the normal (closed-drawer) state.
 *
 * DESKTOP (sizing/spacing): three separate width/height mismatches,
 * found via a full row+column property diff against home at a real
 * 2560px viewport, all resolving to the same familiar bug: a Divi rule
 * that's supposed to lose to another rule on both pages, but wins on
 * /donors/ because its per-page generated selector picked up extra
 * specificity there.
 *   1. Row padding-left: home computes 24px (from this file's own
 *      pre-existing desktop fix — see the unconditional "padding: 0 0 0
 *      24px" rule further up), /donors/ computed 0px. Found the actual
 *      culprit: Divi's own per-page column-width rule
 *      ".et-db #et-boc .et-l .et_pb_column_1_tb_header { width: 28%
 *      !important }" (1 ID) on /donors/ was beating this file's existing
 *      unscoped padding fix in a DIFFERENT way — no, on inspection this
 *      specific padding regression traces to the same "#page-container
 *      #et-boc" boost simply needing to be reapplied at desktop widths,
 *      since the earlier desktop padding fix in this file targets
 *      ".ssb_header_section .et_pb_row_1_tb_header.et_pb_row" (0 IDs, 3
 *      classes) which loses outright to /donors/'s higher-specificity
 *      per-page variants.
 *   2. Column widths: logo (column 1) computed 712.5px on /donors/ vs
 *      300px on home; cart (column 3) computed 178.125px vs 106.521px.
 *      Root cause: Divi ships a generic per-page rule setting these
 *      columns to "width: 28% !important" — on home it's generated as a
 *      bare class (0 IDs), so it loses to this same file's existing
 *      unconditional ".et_pb_row_1_tb_header > .et_pb_column_1_tb_header
 *      ... { width: auto !important }" flex-fix (0 IDs, 2 classes),
 *      leaving the columns sized to their actual content (a 300px logo,
 *      a small cart icon). On /donors/, Divi generated the SAME 28% rule
 *      as ".et-db #et-boc .et-l .et_pb_column_1_tb_header" (1 ID, 3
 *      classes) — enough to beat the unboosted flex-fix rule — so the
 *      columns ballooned to 28% of the full row width instead of
 *      shrinking to content, throwing off every column's width and
 *      position after it.
 *   3. Column 2 (menu) height: computed 82px on /donors/ vs 72px on
 *      home, even after fixing #1 and #2 above (which brought every
 *      OTHER column back to 72px, matching home, via align-self:stretch
 *      off the row's own auto height). Column 2's actual nav content
 *      measures 72px on its own, and no explicit height/min-height rule
 *      targeting column 2 could be found via an exhaustive stylesheet
 *      scan (including checking its ::before pseudo-element, which
 *      unexpectedly also reports height:82px with no matching source
 *      rule found) — left unresolved exactly like v22's column-1
 *      oddity, but empirically, forcing column 2's height to 72px
 *      (matching home) via the same specificity-boost pattern fixes it
 *      completely with no visual side effects.
 * All three verified together live at a real 2560px viewport: every
 * column's x/width/height now matches home's exactly
 * (logo x:24 w:300, menu x:354 w:1945, cart x:2299 w:107,
 * login x:2406 w:139, all h:72), confirmed via both computed-style
 * comparison and a full-header screenshot.
 *
 * Scoped to min-width:992px (the exact inverse of this file's existing
 * max-width:991px mobile breakpoint) so these desktop-only fixes can't
 * interfere with the mobile-specific v20-v23 fixes above.
 */
@media (max-width: 991px) {
  #page-container #et-boc .et_pb_row_1_tb_header > .et_pb_column_2_tb_header {
    z-index: 9999 !important;
  }
}
@media (min-width: 992px) {
  #page-container #et-boc .et_pb_row_1_tb_header.et_pb_row {
    padding: 0 0 0 24px !important;
  }
  #page-container #et-boc .et_pb_row_1_tb_header > .et_pb_column_1_tb_header,
  #page-container #et-boc .et_pb_row_1_tb_header > .et_pb_column_3_tb_header,
  #page-container #et-boc .et_pb_row_1_tb_header > .et_pb_column_4_tb_header {
    flex: 0 0 auto !important;
    width: auto !important;
    max-width: none !important;
  }
  #page-container #et-boc .et_pb_row_1_tb_header > .et_pb_column_2_tb_header {
    height: 72px !important;
  }
}

/*
 * v25: user caught one more desktop-only offset after v24 — the nav menu
 * links ("FIND A DONOR", "SERVICES", etc.) sat visibly 10px lower than
 * they should, even though the row/column heights themselves now
 * matched home exactly (v24 #3). Same "10px" signature as the mobile
 * padding-bottom bug from v23 and the menu-column height bug from v24
 * #3, just showing up one level deeper this time: home's
 * ".ssb_header_menu" module (the direct wrapper around the <nav>
 * element) computes margin-top:0 at desktop widths, but on /donors/ it
 * computes margin-top:10px, pushing the whole nav down inside its
 * column and visually off-center. Couldn't trace this to a specific
 * competing Divi rule via a stylesheet scan (same as v24 #3's
 * unexplained column-2 height, which this may well be related to or
 * even be the direct cause of, since 72px column height minus 10px of
 * menu margin-top happens to land suspiciously close to the leftover
 * space math elsewhere in this file) — user found and verified the
 * practical fix themselves directly in DevTools before reporting it
 * back here. Re-verified live with the same #page-container #et-boc
 * specificity-boost pattern used throughout this file, targeting the
 * module wrapper's margin-top directly (cleaner than compensating with
 * a negative margin on the inner <nav>, and avoids stacking a positive
 * and negative 10px against each other): /donors/'s menu now sits at
 * y:0 within its column, matching home exactly, confirmed via
 * screenshot at a real 2560px viewport.
 *
 * Confirmed this does NOT affect mobile before shipping: at mobile
 * widths .ssb_header_menu's margin-top was already 0px on /donors/ (the
 * bug is desktop-only), and the desktop <nav> element itself is
 * display:none on mobile anyway (replaced entirely by the offcanvas
 * drawer UI from v20/v24), so this fix has no mobile surface at all
 * even before accounting for its min-width:992px scope.
 */
@media (min-width: 992px) {
  #page-container #et-boc .et_pb_row_1_tb_header .ssb_header_menu {
    margin-top: 0 !important;
  }
}