/* Drake KB ??? header region.
 * Targets real DOM confirmed on http://localhost:8090/kb/Banking/10763.htm:
 *   <header class="wp-block-template-part">           full-width header band
 *     .wp-block-group ...                             nested group wrappers
 *       figure.wp-block-image > a > img                logo (white-on-blue OK)
 *       .wp-block-group ... > nav.wp-block-navigation   top nav links
 *         ul.wp-block-navigation__container
 *           li.wp-block-navigation-item
 *             a.wp-block-navigation-item__content
 *
 * The BetterDocs search box sits just BELOW the header in its own
 * `.betterdocs-search-form-wrapper` block (not inside <header>), but the
 * brief wants it visually "on the blue bar", so we pull its wrapper up
 * against the header and paint that band Drake-blue too.
 */

header.wp-block-template-part {
  background: var(--drake-blue); /* header bar only */
  font-family: var(--drake-font);
}

/* Kill any theme background on nested wrappers so only the header's own
 * Drake-blue band shows through. */
header.wp-block-template-part .wp-block-group {
  background: transparent;
}

/* Logo: theme markup wraps it in a plain wp-block-image figure (no
 * wp-block-site-logo class on this template), already swapped to the
 * white Drake PNG by loader.php in most contexts; keep it readable and
 * give it breathing room on the blue bar. */
header.wp-block-template-part .wp-block-image img,
header.wp-block-template-part .custom-logo {
  max-height: 42px;
  width: auto;
  height: auto;
}

/* Top nav links: make readable (white) on the blue band, with a subtle
 * hover state instead of the theme's default ink-on-white underline. */
header.wp-block-template-part .wp-block-navigation-item__content,
header.wp-block-template-part a.wp-block-navigation-item__content {
  color: #ffffff !important;
  text-decoration: none !important;
  font-weight: 600;
}

header.wp-block-template-part .wp-block-navigation-item__content:hover,
header.wp-block-template-part .wp-block-navigation-item__content:focus {
  color: #eaf2fa !important;
  text-decoration: underline !important;
}

/* Mobile menu toggle icon + close icon: white strokes/fills on blue. */
header.wp-block-template-part .wp-block-navigation__responsive-container-open svg,
header.wp-block-template-part .wp-block-navigation__responsive-container-close svg {
  fill: #ffffff;
  color: #ffffff;
}

/* When the mobile nav overlay opens it renders a light modal panel;
 * force readable ink-on-white text there instead of inheriting header
 * white-on-transparent. */
header.wp-block-template-part .wp-block-navigation__responsive-container.has-background {
  background: #ffffff !important;
}

header.wp-block-template-part .wp-block-navigation__responsive-container.has-background .wp-block-navigation-item__content {
  color: var(--drake-ink) !important;
}

header.wp-block-template-part .wp-block-navigation__responsive-container.has-background .wp-block-navigation-item__content:hover {
  color: var(--drake-blue) !important;
}

/* --- Search box band ---------------------------------------------------
 * DOM (confirmed on /kb/Banking/10763.htm):
 *   </header>                                         <- blue logo bar (above)
 *   <div class="wp-block-group has-background"         <- BODY WRAPPER, bg #f2f4f7
 *        style="background-color:#f2f4f7;...">            (wraps the ENTIRE article
 *                                                          body ??? MUST stay light)
 *     <div class="wp-block-group has-accent-1-background-color has-background
 *                 has-global-padding ...">              <- THE SEARCH BAND (darker
 *                                                          preset "accent-1" blue)
 *       <div class="betterdocs-search-form-wrapper"> ...
 *     ...rest of article body...
 *
 * THE TRAP: the body wrapper is `.wp-block-group.has-background`. Any rule that
 * matches it (`.wp-block-group.has-background`, `header + ...`, or a bare
 * `:has(.betterdocs-search-form-wrapper)` high on the tree) floods the WHOLE
 * page blue. So we target ONLY the search band via its own distinguishing
 * class `.has-accent-1-background-color`, further pinned with `:has(the search
 * wrapper)`. The body wrapper does NOT carry `.has-accent-1-background-color`,
 * so it is never matched ??? the article body stays #f2f4f7 light.
 *
 * DESIGN GOAL (per the real Drake KB header): the search must NOT be a
 * full-width blue band below the logo bar. Instead it is a COMPACT search box
 * docked INLINE at the top-right of the single blue header bar, on the same
 * blue as the logo.
 *
 * How: take the whole search band OUT OF FLOW with position:absolute so the
 * article body collapses up to sit directly beneath the 73px blue header. The
 * band's nearest positioned ancestor is none (the body wrapper + wp-site-blocks
 * are static), so absolute positioning is relative to the viewport/initial
 * containing block ??? top:0 == the top of the header bar. We dock the band into
 * the header's top-right, aligned to the theme's centered content edge
 * (--wp--style--global--wide-size = 1340px; right inset = (100% - 1340px)/2,
 * floored at 24px so it never runs off-screen on narrow viewports), strip its
 * background/padding so no separate blue band remains, and shrink the input to
 * a small right-aligned box.
 *
 * This selector still matches ONLY the search band (it carries
 * `.has-accent-1-background-color`); the body wrapper does NOT, so the article
 * body keeps its light #f2f4f7 background ??? no page-wide blue flood. */
.wp-block-group.has-accent-1-background-color:has(.betterdocs-search-form-wrapper) {
  position: absolute !important;
  top: 16px !important;
  right: max(24px, calc((100% - 1340px) / 2)) !important;
  left: auto !important;
  /* Was min(300px, ???): the box now holds the product filter <select> as well as
   * the field (see "Product filter" below), and at 300px the two together left the
   * placeholder clipped to about two words. 470px fits "Drake Accounting (DAS)"
   * without the select stealing width from the input. Still capped against the
   * viewport so it cannot collide with the logo on a narrow window.
   *
   * The budget is `100%`, not `100vw`. This band is absolutely positioned with no
   * positioned ancestor, so `100%` resolves against the initial containing block ???
   * the viewport MINUS a classic vertical scrollbar. `100vw` INCLUDES that
   * scrollbar, so on a scrollbarred desktop window it over-reported the space
   * available by the scrollbar width (~15px) and moved the box that much further
   * left, toward the logo. The 470px term wins at every viewport above ~690px, so
   * this changes nothing on desktop; it only tightens the narrow-window guard.
   *
   * 220px is the logo's width budget: 24px root inset + 132px logo + 64px gap.
   * Measured clearance between the logo's right edge (x=156) and this band's left
   * edge (x=196) is 40px at every width from 264px up. That clearance depends on
   * the logo actually rendering at the 132px the template asks for ??? if the inline
   * width were ever dropped AND the max-height cap above lost, the PNG's intrinsic
   * 300px would run straight under this box (measured: 128px of overlap). Keep
   * both. */
  width: min(470px, calc(100% - 220px)) !important;
  margin: 0 !important;
  padding: 0 !important;
  background: transparent !important;
  z-index: 5;
}

/* Belt-and-suspenders: also clear the theme's own inline accent-1 background so
 * no stray blue rectangle shows behind the compact box. */
.wp-block-group.has-accent-1-background-color:has(.betterdocs-search-form-wrapper),
.wp-block-group.has-accent-1-background-color:has(.betterdocs-search-form-wrapper) > * {
  background-color: transparent !important;
}

/* Zero the inner block-spacing/margins BetterDocs bakes into the searchbox
 * wrappers so the input centers within the 73px header bar (otherwise ~28px of
 * top margin pushes the box below the blue bar's bottom edge). */
.wp-block-group.has-accent-1-background-color:has(.betterdocs-search-form-wrapper)
  [class*="betterdocs-searchbox-"],
.wp-block-group.has-accent-1-background-color:has(.betterdocs-search-form-wrapper)
  .betterdocs-live-search {
  margin: 0 !important;
  padding: 0 !important;
}

.betterdocs-search-form-wrapper {
  /* The form wrapper ships its own off-blue background; clear it and drop its
   * padding so the box sits flush and compact on the blue header bar. */
  background: transparent !important;
  margin: 0 !important;
  padding: 0 !important;
  width: 100% !important;
}

/* The `.betterdocs-searchform` is a white, padded, rounded CARD by default ???
 * that padding is what made the search overhang the header as a white panel.
 * Strip it so ONLY the input box itself sits on the blue bar. */
.betterdocs-search-form-wrapper .betterdocs-searchform {
  background: transparent !important;
  padding: 0 !important;
  border-radius: 0 !important;
  box-shadow: none !important;
  /* BetterDocs also puts `border: 1px solid #f1f1f1` on the FORM. Invisible on its
   * own near-white card, but on the blue bar it drew a white rectangle around both
   * controls. Measured via getComputedStyle, not guessed ??? the rule is in
   * search-modal.css and does not appear in the page's inline CSS. */
  border: 0 !important;
  /* And keep the field flush against the product select: the flex row's default
   * spacing left a blue sliver between two controls that should read as one box. */
  gap: 0 !important;
}

/* Hide BETTERDOCS' OWN "All Categories" dropdown (`.betterdocs-search-category`,
 * present wherever the searchbox block has categorySearch on ??? the category
 * archive templates do).
 *
 * The original reason was cosmetic: it crammed the compact box and clipped the
 * placeholder. The reason it MUST stay hidden is functional. That select feeds
 * BetterDocs Pro's live-search AJAX, whose tax_query pairs operator=AND with
 * include_children, so a parent product matches nothing ??? measured 0 hits for
 * ?s=check&drake-tax where the answer is 561. Showing it would put a control on the
 * page that silently returns empty results.
 *
 * The header is NOT a plain search field any more: it carries our own product
 * filter, `.drake-kbcat--header` (styled below), which submits `kbcat` to the
 * results page and filters correctly. See
 * mu-plugins/drake-kb-search-filter.php. */
.wp-block-group.has-accent-1-background-color:has(.betterdocs-search-form-wrapper)
  .betterdocs-search-category {
  display: none !important;
}

/* BetterDocs emits `<input type="hidden" class="betterdocs-search-submit">`. A
 * hidden input still counts as a FLEX ITEM, so in this flex row it reserved a
 * blank gap between the search field and our product select ??? a stray white
 * square on the blue bar. `type=hidden` means it is never interactive, so there is
 * nothing to preserve by leaving it in flow. */
.betterdocs-search-form-wrapper .betterdocs-searchform input[type="hidden"] {
  display: none !important;
}

.betterdocs-search-form-wrapper .betterdocs-searchform-input-wrap {
  background: #ffffff;
  border: 1px solid var(--drake-blue-dark);
  border-radius: 6px;
  height: 38px;
  /* Was width:100%, which is fine when the field is the form's only child but
   * makes it demand the whole row now that the product filter shares it ??? the
   * select then got squeezed to its minimum and the two overlapped. flex-basis 0
   * lets both children size from their content and share the 470px box. */
  width: auto;
  min-width: 0;
  flex: 1 1 0;
}

/* --- Product filter <select> (header) -----------------------------------
 * Injected into BetterDocs' rendered form by
 * mu-plugins/drake-kb-search-filter.php as `<select class="drake-kbcat
 * drake-kbcat--header" name="kbcat">`, matching the filter Drake's real KB header
 * carries. It is deliberately NOT BetterDocs' own `.betterdocs-search-category`
 * (which the rule above hides): that class routes the value into Pro's live-search
 * AJAX, whose tax_query uses operator=AND with include_children and returns zero
 * results for every parent product. See the mu-plugin's docblock.
 *
 * Styled as a peer of the input ??? same 38px height, same white-on-blue treatment,
 * same border ??? so the pair reads as one control docked on the blue bar rather
 * than a field with a widget bolted on. It sits to the RIGHT of the field, which
 * is where Drake's own filter sits. */
.betterdocs-search-form-wrapper .betterdocs-searchform .drake-kbcat--header {
  flex: 0 1 auto;
  /* Long labels ("Drake Accounting (DAS)") must not push the input to nothing, and
   * the closed select must still be readable. */
  max-width: 175px;
  min-width: 105px;
  height: 38px;
  margin: 0 0 0 6px;
  padding: 0 26px 0 9px;
  font-family: var(--drake-font);
  font-size: 0.8rem;
  line-height: 36px;
  color: var(--drake-ink);
  background-color: #ffffff;
  /* Native arrow removed and redrawn in Drake blue, so the control matches the
   * magnifier's accent instead of the OS default grey chevron. */
  background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 12 8' fill='none' stroke='%231b75bc' stroke-width='2' stroke-linecap='round' stroke-linejoin='round'%3E%3Cpath d='M1 1.5L6 6.5L11 1.5'/%3E%3C/svg%3E");
  background-repeat: no-repeat;
  background-position: right 9px center;
  background-size: 10px 7px;
  border: 1px solid var(--drake-blue-dark);
  border-radius: 6px;
  cursor: pointer;
  appearance: none;
  -webkit-appearance: none;
  text-overflow: ellipsis;
}

.betterdocs-search-form-wrapper .betterdocs-searchform .drake-kbcat--header:focus-visible {
  outline: 2px solid #ffffff;
  outline-offset: 1px;
}

/* Below 768px the header bar has no room for field + select side by side; the
 * field alone is the more important half, so the filter drops out of the header
 * (the results page's own facet rail still offers every category).
 *
 * WHY 767px AND NOT THE 700px THIS RULE USED TO CARRY. 767px is BetterDocs' own
 * breakpoint, and it is the number that matters here because of what BetterDocs
 * does at it (betterdocs/assets/public/css/search.css, `@media only screen and
 * (max-width:767px)`):
 *
 *   .betterdocs-searchform          { flex-direction: column }
 *   .betterdocs-searchform-input-wrap { height: 50px; padding: 10px;
 *                                       margin-bottom: 10px; border: 1px solid #d3d9ef }
 *
 * That turns the docked box from a 40px-tall row into a COLUMN. With the old
 * 700px cutoff there was a 701???767px band where the select was still visible and
 * the form had already gone vertical, so the box measured 100px tall inside a
 * 73.4px header: the select rendered BELOW the blue band, floating on the grey
 * article canvas (measured at 701px: band bottom y=116 vs header bottom y=73.4).
 * Even with the select hidden the wrap's 50+10+10 made the band 62px tall and
 * overhang the bar by 4.6px at every width from 264px up.
 *
 * So: hide the filter across the whole of BetterDocs' column range, and put the
 * field's own geometry back to the 38px row the desktop header uses, so the
 * docked box stays one row inside the 73.4px blue band at every narrow width.
 * Scoped to the docked header band (`.has-accent-1-background-color:has(...)`),
 * never to BetterDocs' search boxes elsewhere. */
@media (max-width: 767px) {
  /* Narrow viewports: the docked search shares the blue bar with the logo. The
   * desktop budget (100% ??? 220px) assumes a 132px-wide logo; on staging the
   * white logo art often renders wider (two-line ???Drake Software / Knowledge
   * Base???), which lets the search box slide left over the wordmark. Tie the two
   * widths together so they never overlap. */
  :root {
    --drake-header-search-w: clamp(112px, 34vw, 168px);
  }

  .wp-block-group.has-accent-1-background-color:has(.betterdocs-search-form-wrapper) {
    width: var(--drake-header-search-w) !important;
    right: 16px !important;
    top: 18px !important;
  }

  header.wp-block-template-part .wp-block-image img,
  header.wp-block-template-part .custom-logo,
  header.wp-block-template-part .drake-header__logo img {
    max-width: calc(100vw - 24px - 16px - var(--drake-header-search-w) - 12px);
    max-height: 48px;
    width: auto !important;
    height: auto !important;
    object-fit: contain;
    object-position: left center;
  }

  .betterdocs-search-form-wrapper .betterdocs-searchform .drake-kbcat--header {
    display: none;
  }

  .wp-block-group.has-accent-1-background-color:has(.betterdocs-search-form-wrapper)
    .betterdocs-searchform {
    flex-direction: row !important;
  }

  /* Same 38px box as desktop. `padding: 0` restores the flush field the docked
   * look depends on; the 1px Drake-blue border above is kept, so BetterDocs'
   * near-invisible #d3d9ef is simply overridden rather than fought. The control
   * stays a real focusable input with its "Search Input" accessible name ??? only
   * its box metrics change. */
  .wp-block-group.has-accent-1-background-color:has(.betterdocs-search-form-wrapper)
    .betterdocs-searchform-input-wrap {
    height: 38px !important;
    padding: 0 !important;
    margin-bottom: 0 !important;
    border: 1px solid var(--drake-blue-dark) !important;
  }
}

.betterdocs-search-form-wrapper .betterdocs-search-field {
  color: var(--drake-ink) !important;
  font-family: var(--drake-font);
}

.betterdocs-search-form-wrapper .betterdocs-search-field::placeholder {
  color: var(--drake-gray);
}

.betterdocs-search-form-wrapper .docs-search-icon {
  fill: var(--drake-blue);
}