/* Supplemental CSS for behavior the original hosted documentation platform's own
   bundle expects React to drive client-side (tab panel visibility, mobile
   sidebar/outline drawers, search dropdown, theme toggle) — the reused CSS from
   that platform covers all visual tokens, this file only covers show/hide
   plumbing our vanilla JS controls. */

/* Real root cause of "wrong fonts": html{font-family:var(--font-content,...)} and
   code,kbd,pre,samp{font-family:var(--font-mono,...)} both reference variables the
   original hosted documentation platform normally injects as a 4th site-specific style
   block (alongside the color-scale one already wired in) -- confirmed by grepping the
   real pd4ml-*.css bundles, this is the exact same "variable referenced but never
   defined" bug as the color-scale fix, just for fonts. That platform self-hosts
   subsetted woff2 files per-variable via many @font-face rules; reusing the
   already-loaded Google Fonts equivalents here instead of rehosting ~30 font files is a
   deliberate scope cut, not an oversight. */
:root {
  --font-content: "Inter", "Inter Fallback", system-ui, arial;
  --font-mono: "IBM Plex Mono", monospace;
}

/* The real <pre> class list has no horizontal padding utility (verified: only "py-2.5"),
   so its visible left/right breathing room in the reference must come from a mechanism
   not present anywhere in the saved reference HTML/CSS (possibly per-line padding added by
   the original hosted documentation platform's own Shiki transformer, which isn't inspectable from static markup). Adding it
   directly is a pragmatic visual match rather than a rediscovered "real" class. */
pre.bg-tint-subtle { padding-left: 1rem; padding-right: 1rem; }

/* Real header layout: "Back to Home" (.header-links) is a CHILD of the
   search box's own outer shell (.pd4ml-search-shell), not a sibling of it in
   header-content -- confirmed directly via getComputedStyle/
   getBoundingClientRect (two earlier rounds guessed wrong from the class
   list alone). The original hosted documentation platform lays "search box + Back to Home" out as ONE flex
   group; .header-links' own margin-left:auto is what creates the gap and
   pins the button to that GROUP's right edge, which only lines up with the
   header's true right edge because the group itself is sized to fill the
   header's remaining space. Four things had to be true together, not any
   one alone:
   1. .pd4ml-search-shell needs flex-grow:1 -- its real classes
      (max-w-[50%]/grow-[0.8]/basis-56) leave it well short of the header's
      free space, so .header-links' auto margin has nothing to consume and
      the button lands mid-header with a huge dead gap after it.
   2. .pd4ml-search-box-wrapper (the "relative flex grow" div holding just
      .group/input) needs flex-grow REMOVED, not added -- it carries its own
      unconditional flex-grow:1 in the real markup, so once the shell above
      actually grows, THIS is what greedily ate the new space instead of
      .header-links' auto margin, stretching the search box's own border
      across the gap meant for the button instead of leaving a gap at all
      (exactly the "border stretched, still tiny input, button not
      separated" bug two earlier attempts produced, in each direction).
   3. .group/input (innermost) still needs its own container-query collapse
      (max-w-9.5 icon pill below "2xl", 14rem only on focus) neutralized
      unconditionally, same as before, independent of the two levels above.
   4. The <input> itself additionally carries a plain HTML size="1"
      attribute (removed at generation time in build-skeleton.js) -- a flex
      item's default min-width:auto otherwise lets that tiny intrinsic
      content width win over "grow" once nothing else forces it smaller, so
      the *input* stayed a couple of characters wide even inside a correctly
      -sized pill. width:100% below is the CSS-side backstop for that. */
.pd4ml-search-shell {
  order: 0 !important;
  flex-grow: 1 !important;
  flex-basis: 0 !important;
  max-width: none !important;
}
.pd4ml-search-box-wrapper {
  flex-grow: 0 !important;
  flex-basis: auto !important;
  width: 24rem !important;
  max-width: 100% !important;
}
.group\/input {
  position: relative !important;
  inset: auto !important;
  max-width: none !important;
  width: 100% !important;
}
.group\/input input {
  opacity: 1 !important;
  width: 100% !important;
  min-width: 0 !important;
}

.tab-panel[hidden] { display: none; }
.tab-btn { cursor: pointer; background: transparent; border: 0; }
.tabs-list { -ms-overflow-style: none; scrollbar-width: thin; }

/* Sidebar + outline: desktop-visible, mobile off-canvas toggled via .drawer-open on <html> */
@media (max-width: 1023px) {
  aside[data-gb-table-of-contents] { display: none; }
  html.sidebar-open aside[data-gb-table-of-contents] { display: flex !important; z-index: 45; background: var(--tint-base, #fff); }
}
@media (max-width: 1279px) {
  aside.group\/aside { display: none; }
  html.outline-open aside.group\/aside { display: flex !important; position: fixed; right: 0; top: 4rem; z-index: 45; background: var(--tint-base, #fff); max-height: calc(100vh - 4rem); overflow-y: auto; }
}

/* This container never actually existed in the skeleton until now (site.js
   has looked up #search-results since the search feature was first added,
   but nothing ever created it -- every keystroke threw inside the 'input'
   listener and silently did nothing; confirmed directly by simulating a
   search in a real browser and seeing the exact TypeError). Styled as a
   floating card using the same tokens as the rest of the reused
   theme (border-tint, bg-tint-base, rounded, shadow) now that it actually
   renders. */
#search-results {
  position: absolute; top: 100%; left: 0; right: 0; margin-top: .5rem;
  max-height: 60vh; overflow-y: auto; z-index: 50;
  background: rgb(var(--tint-1, 255 255 255)); color: rgb(var(--tint-12, 29 29 29));
  border: 1px solid rgb(var(--tint-6, 226 230 236)); border-radius: .75rem;
  box-shadow: 0 10px 25px -5px rgba(0,0,0,.1), 0 8px 10px -6px rgba(0,0,0,.1);
  padding: .375rem;
}
#search-results[hidden] { display: none; }
#search-results a { display: block; padding: .5rem .75rem; border-radius: .5rem; }
#search-results a:hover, #search-results a.active { background: var(--tint-hover, rgba(0,0,0,.05)); }
#search-results strong { font-weight: 700; }

/* Landed on the right paragraph after clicking a search result (see the
   jump-to-match block in site.js) -- a persistent highlight, not a fade-out,
   since the whole point is to still be visible once the smooth-scroll
   finishes settling on it. */
mark.search-jump-highlight {
  background: rgb(var(--warning-4, 255 239 225));
  color: inherit;
  border-radius: .2em;
  box-shadow: 0 0 0 .15em rgb(var(--warning-4, 255 239 225));
}

/* Code blocks now use the original hosted documentation platform's real <pre> classes (bg-tint-subtle etc.) for background --
   no override needed/wanted here anymore; shiki's own inline background style is discarded
   at generation time (see build.js), not fought with !important. */
pre.bg-tint-subtle:hover .codeblock-copy-btn { opacity: 1; }
/* Shiki emits a valid light-theme `color` plus a `--shiki-dark` custom property per token;
   nothing applies the latter without this rule, so dark mode would otherwise show light-theme
   text colors unchanged. (That platform's own semantic --primary-N/--warning-N/etc. token palette,
   applied via light-dark(), is not reproduced here -- see report.) */
html.dark pre.bg-tint-subtle span[style*="--shiki-dark"] { color: var(--shiki-dark) !important; }

img { max-width: 100%; height: auto; }
table { width: 100%; border-collapse: collapse; }
table th, table td { border: 1px solid var(--tint-subtle, #e5e5e5); padding: .5rem .75rem; text-align: left; }

/* A markdown table shaped like "Tag | Status | ..." (see build.js's
   enhanceTagStatusTables()) gets a pinned Tag-column width -- otherwise a
   multi-tag cell like "<em> <cite> <dfn> <var>" balloons that column out to
   fit itself on one line -- and its Status column's plain-word caption is
   swapped for a small colored icon at render time; these rules are what that
   icon actually looks like. */
.tag-status-table-wrap { overflow-x: auto; }
.tag-status-table { table-layout: fixed; }
.tag-status-table th:nth-child(1), .tag-status-table td:nth-child(1) { width: 125px; }
.tag-status-table th:nth-child(2), .tag-status-table td:nth-child(2) { width: 52px; }
.tag-status-table th:nth-child(3), .tag-status-table td:nth-child(3) { width: 300px; }
.tag-status-table th:nth-child(4), .tag-status-table td:nth-child(4) { width: 300px; }
.tag-status-table th:nth-child(5), .tag-status-table td:nth-child(5) { width: auto; }
.tag-status-table td, .tag-status-table th { overflow-wrap: break-word; }
.tag-status-table .pill {
  display: inline-flex; align-items: center; justify-content: center;
  width: 22px; height: 22px; border-radius: 50%; flex: none;
}
.tag-status-table .pill svg { width: 13px; height: 13px; }
.tag-status-table .pill.full { background: #e5f5ea; color: #1a7d3a; }
.tag-status-table .pill.partial { background: #fbf0dd; color: #a9600a; }
.tag-status-table .pill.none { background: #fbe9e7; color: #b3261e; }
.tag-status-table .pill.na { background: #eef0f2; color: #6b7280; }
html.dark .tag-status-table .pill.full { background: #12321f; color: #4ed17f; }
html.dark .tag-status-table .pill.partial { background: #3a2c14; color: #eab35c; }
html.dark .tag-status-table .pill.none { background: #3a1a17; color: #f37368; }
html.dark .tag-status-table .pill.na { background: #20282d; color: #93a0a8; }
.sr-only { position: absolute; width: 1px; height: 1px; padding: 0; margin: -1px; overflow: hidden; clip: rect(0,0,0,0); white-space: nowrap; border: 0; }
