/* * Loaded into 's own shadow root via its `css-file` attribute * (RapiDoc clones a matching from the light DOM into its shadow * root - confirmed by reading node_modules/rapidoc/dist/rapidoc.js's own * `render()` - so plain selectors like `.nav-bar` work here even though * they can't from an ordinary external stylesheet piercing a shadow * boundary from outside). Despite the filename, this now also carries * general responsive fixes for RapiDoc's own CSS below desktop width, * not just the mobile nav. * * RapiDoc's own "read" render style has no mobile fallback at all for its * endpoint nav: `.nav-bar` only gets `display:flex` inside * `@container (min-width: 768px)` (see rapidoc.js line ~12007) - below * that it's `display:none` with no toggle anywhere in the component. * Without this override, a phone visitor would have no way to jump to a * specific endpoint at all. `[data-mobile-nav-open="true"]` is toggled by * RapiDocClient.tsx's own floating "Browse endpoints" button. */ @container (max-width: 767px) { :host([data-mobile-nav-open="true"]) .nav-bar { display: flex !important; position: fixed; inset: 0; z-index: 1000; width: 100% !important; } } /* * RapiDoc's own side padding on the content column (.section-gap--read- * mode, the class its "read" render style actually uses - confirmed by * reading overviewTemplate() in rapidoc.js) is 4px below a 768px * container width and only 8px between 768-1023px - both read as "no * padding at all" next to the 80px it uses at 1024px+, so every heading * and paragraph sits flush against the edge on anything narrower than a * full desktop window. Widened here to something that actually reads as * a margin at each tier; the 1024px+ rule already in rapidoc.js is left * alone since nothing was wrong with it. */ @container (max-width: 767px) { .section-gap--read-mode { padding: 16px 20px !important; } } @container (min-width: 768px) and (max-width: 1023px) { .section-gap--read-mode { padding: 24px 36px !important; } } /* * Two real nav-sidebar misalignments, both in RapiDoc's own markup/CSS, * confirmed by reading rapidoc.js directly rather than guessing: * * 1. The search bar row's padding (`padding:8px 24px 12px 24px`) is a * plain inline style in RapiDoc's own template, not a class - 24px * each side, while every real nav row below it (.nav-bar-info, * .nav-bar-path, via --nav-item-padding) uses 10px. That's what reads * as the search box being "inset" relative to everything above and * below it. `!important` here is required to beat that inline style * (nothing weaker can). * 2. "OPERATIONS" sits inside `.nav-bar-section`, which is * `justify-content: space-between` between two children - normally * the left child holds expand-all/collapse-all icons, but those only * render in RapiDoc's "focused" render style (rapidoc.js: `${this. * renderStyle === 'focused' ? ... : ''}`). We only ever use "read", so * that first child is always empty, and space-between shoves * "OPERATIONS" - the only real content - all the way to the right * edge instead of the left. Safe to force flex-start unconditionally * since "focused" mode is never used here. */ [part="section-navbar-search"] { padding: 8px 10px 12px 10px !important; } .nav-bar-section { justify-content: flex-start !important; } /* * flex-start alone wasn't enough - confirmed by measuring actual * getBoundingClientRect() on the real elements: "OPERATIONS" still * rendered its text starting at left:20px while every other nav row * (.nav-bar-info/.nav-bar-tag, including the injected Guides ones) starts * at left:10px. The empty icon-container div (expand-all/collapse-all, * "focused" mode only) still carries its own inline `margin-left:10px` * even with nothing inside it - .nav-bar-section's own 10px left padding * plus that empty div's 10px margin is exactly the extra 10px. Zeroed * unconditionally since "focused" mode is never used, so this div is * always empty in this app. */ .nav-bar-section.operations > div:first-child { margin-left: 0 !important; } /* * RapiDocClient.tsx's operations-top slot content (the 3 guides) needs * the exact same left/right padding #overview uses (.section-gap--read- * mode above), to line up with the API title/description sitting right * above it in the same content column. That div is *slotted* light-DOM * content though (a real React element, merely projected into the shadow * tree via ) - confirmed directly that applying the * "section-gap--read-mode" class name to it does nothing at all * (measured padding-left: 0px), because a shadow root's own stylesheet * (RapiDoc's, or this one, cloned in alongside it) only reaches slotted * content through ::slotted(), never through a plain class selector like * the ones .nav-bar-info/.nav-bar-tag match with (those work because * RapiDocClient.tsx inserts them as genuine shadow-DOM children directly, * not through a slot). So the values are duplicated here via ::slotted() * instead of reusing the class - same numbers as .section-gap--read-mode * above and RapiDoc's own 1024px+ rule, kept in sync by hand. */ ::slotted(.krewfield-guides-slot) { padding: 16px 20px !important; } @container (min-width: 768px) and (max-width: 1023px) { ::slotted(.krewfield-guides-slot) { padding: 24px 36px !important; } } @container (min-width: 1024px) { ::slotted(.krewfield-guides-slot) { padding: 24px 80px 12px 80px !important; } } /* * Relevance-ranked search (RapiDocClient.tsx's own "input" listener) sets * a CSS `order` on each operation row and each tag wrapper - `order` is a * flex/grid-only property, silently ignored by ordinary block-flow * children, and both of these render as plain