@writedocs/generator 0.1.0

package/src/layout/styles/mobile-menu.css

@@ -0,0 +1,258 @@
+/* MobileMenu.astro's own styling - the <= 860px drawer panel itself (not
+   the hamburger toggle button that opens it, which lives in topbar.css
+   alongside the rest of TopBar.astro's own markup). */
+
+.wd-mobile-menu { display: none; }
+@media (max-width: 860px) {
+  .wd-mobile-menu {
+    display: block;
+    /* Always laid out (positioned off-screen via the panel's own
+       transform below), not display:none, so .open can transition
+       smoothly instead of snapping - a transition can't animate *out of*
+       display:none. visibility is what keeps it non-visible/out of the
+       tab order while closed (visibility: hidden also removes descendants
+       from hit-testing and the accessibility tree); initMobileMenu()
+       (src/scripts/mobile-menu.ts) toggles the `inert` attribute
+       alongside .open as a second, JS-driven layer of the same
+       guarantee, since not every browser/AT combination is guaranteed to
+       treat visibility:hidden identically. pointer-events is deliberately
+       NOT toggled here on the container itself - see the comment below
+       for why: this element's own box spans the *entire* viewport
+       (position: fixed; inset: 0), so giving *it* pointer-events: auto
+       would make its empty top strip (behind the topbar) swallow clicks
+       meant for the topbar underneath, even though nothing of this
+       element's own visible content is painted there. */
+    visibility: hidden;
+  }
+  .wd-mobile-menu.open {
+    visibility: visible;
+  }
+}
+.wd-mobile-menu {
+  position: fixed;
+  inset: 0;
+  z-index: 40;
+  /* Never toggled: this box covers the full viewport (inset: 0). If this
+     were pointer-events: auto while open, its own box would be a valid
+     hit target everywhere within it (an element with no background is
+     not "invisible" to hit-testing - only pointer-events: none makes it
+     click-through), and being a higher z-index than the topbar, would
+     swallow clicks meant for whatever's underneath. Interactivity is
+     granted instead to the backdrop and panel individually below. */
+  pointer-events: none;
+}
+.wd-mobile-menu-backdrop,
+.wd-mobile-menu-panel {
+  pointer-events: none;
+}
+.wd-mobile-menu.open .wd-mobile-menu-backdrop,
+.wd-mobile-menu.open .wd-mobile-menu-panel {
+  pointer-events: auto;
+}
+.wd-mobile-menu-backdrop {
+  position: absolute;
+  /* Full viewport (top: 0, not 5rem) - the panel itself also reaches
+     top: 0 with its own header (brand/close/theme, see
+     .wd-mobile-menu-header below) replicating the real topbar's row, so
+     there's nothing under the backdrop still worth keeping
+     un-dimmed/interactive: the real topbar is either fully covered by the
+     panel's own opaque background (its width) or genuinely just dimmed
+     decoration past it. */
+  inset: 0;
+  background: rgba(0, 0, 0, 0.4);
+  opacity: 0;
+  transition: opacity 0.25s ease;
+}
+.wd-mobile-menu.open .wd-mobile-menu-backdrop {
+  opacity: 1;
+}
+/* A left-anchored drawer (Mintlify's own mobile nav - the reference this
+   was built against - works the same way), not a centered/inset floating
+   card: flush to the screen's left edge, full viewport height top to
+   bottom (top: 0, not just below the topbar - see .wd-mobile-menu-header
+   below for why), sliding in from off-screen rather than just appearing. */
+.wd-mobile-menu-panel {
+  position: absolute;
+  inset: 0 auto 0 0;
+  width: min(88vw, 340px);
+  display: flex;
+  flex-direction: column;
+  /* Same --wd-navbar-background as .wd-topbar (topbar.css) - this panel's
+     own header row replicates the real topbar's brand row (see the
+     comment on .wd-mobile-menu-header below), so it should share its
+     background too rather than looking like a separate, differently-
+     colored surface once a site configures theme.colors.navbar. */
+  background: var(--wd-navbar-background);
+  border-right: 1px solid var(--wd-border);
+  box-shadow: 8px 0 24px rgba(0, 0, 0, 0.15);
+  transform: translateX(-100%);
+  transition: transform 0.25s ease;
+}
+.wd-mobile-menu.open .wd-mobile-menu-panel {
+  transform: translateX(0);
+}
+/* Replicates the real topbar's brand row - same left-to-right order
+   (close-toggle, brand, theme) - as a fixed header pinned to the top of
+   the panel, so it reads as one continuous navbar with the real one
+   underneath rather than a separate piece with a seam. `flex-shrink: 0`
+   keeps it pinned above .wd-mobile-menu-scroll's own independent
+   scrolling below. .wd-topbar-brand and .wd-theme-toggle themselves are
+   defined in topbar.css, imported by this component too - see this
+   file's own top comment. */
+.wd-mobile-menu-header {
+  display: flex;
+  align-items: center;
+  gap: 0.5rem;
+  flex-shrink: 0;
+  padding: 0.75rem 1rem;
+  border-bottom: 1px solid var(--wd-border);
+}
+.wd-mobile-menu-header .wd-topbar-brand {
+  flex: 1;
+  min-width: 0;
+}
+.wd-mobile-menu-close {
+  display: flex;
+  align-items: center;
+  justify-content: center;
+  width: 2rem;
+  height: 2rem;
+  padding: 0;
+  border: none;
+  border-radius: 0.4rem;
+  background: none;
+  cursor: pointer;
+  /* --wd-navbar-foreground-muted, not --wd-text-muted - this button sits
+     on the panel's own --wd-navbar-background (see .wd-mobile-menu-panel
+     above), same reasoning as topbar.css's identical swap for its
+     desktop-row counterparts. Falls back to var(--wd-text-muted) when
+     theme.navbar has no `foreground` set, so this is a no-op unless a
+     site actually configures one. */
+  color: var(--wd-navbar-foreground-muted);
+  flex-shrink: 0;
+}
+.wd-mobile-menu-close:hover { color: var(--wd-navbar-foreground); background: var(--wd-surface); }
+.wd-mobile-menu-scroll {
+  flex: 1;
+  min-height: 0;
+  overflow-y: auto;
+  padding: 1rem 0.75rem;
+}
+.wd-mobile-menu-selectors {
+  display: flex;
+  flex-direction: column;
+  gap: 0.5rem;
+  margin-bottom: 0.75rem;
+  padding-bottom: 0.75rem;
+  border-bottom: 1px solid var(--wd-border);
+}
+/* position: relative makes this the containing block for its own
+   .wd-mobile-accordion-options panel below, which floats over whatever
+   comes after it instead of pushing it down the page - a `<details>`'s
+   open content is normal, in-flow block content by default, which *would*
+   push later siblings down; taking the options panel out of flow via
+   position: absolute is what avoids that. The [open] z-index bump is what
+   then guarantees *this* accordion's floating panel paints above the
+   *later*, still-closed accordion rows below it: any position: relative
+   element - open or not - already paints above its plain in-flow siblings
+   regardless of z-index (per CSS's stacking rules), but two position:
+   relative siblings with no z-index of their own paint in DOM order, i.e.
+   a later closed row would otherwise sit on top of an earlier open one's
+   panel despite being visually "behind" it. */
+.wd-mobile-accordion {
+  position: relative;
+  border: 1px solid var(--wd-border);
+  border-radius: 0.5rem;
+}
+.wd-mobile-accordion[open] {
+  z-index: 5;
+}
+/* --wd-navbar-foreground, not --wd-text: this row (and every other
+   selector row/link directly inside .wd-mobile-menu-scroll, down through
+   .wd-mobile-menu-link below) sits directly on .wd-mobile-menu-panel's own
+   --wd-navbar-background, same as the header above - only the *floating*
+   .wd-mobile-accordion-options-panel a click reveals (further down this
+   file) sits on the ordinary --wd-background instead, which is why that
+   one's own rules are deliberately left on --wd-text/--wd-primary,
+   unchanged. */
+.wd-mobile-accordion-trigger {
+  display: flex;
+  align-items: center;
+  gap: 0.5rem;
+  padding: 0.65rem 0.75rem;
+  cursor: pointer;
+  font-size: 0.9rem;
+  color: var(--wd-navbar-foreground);
+  list-style: none;
+}
+.wd-mobile-accordion-trigger::-webkit-details-marker { display: none; }
+.wd-mobile-accordion-trigger::marker { content: ''; }
+.wd-mobile-accordion-label { flex: 1; min-width: 0; }
+.wd-mobile-accordion-caret {
+  flex-shrink: 0;
+  color: var(--wd-navbar-foreground-muted);
+  transition: transform 0.15s ease;
+}
+.wd-mobile-accordion[open] > .wd-mobile-accordion-trigger .wd-mobile-accordion-caret {
+  transform: rotate(180deg);
+}
+/* Floats directly below the trigger (top: 100%, same "padding-top for the
+   gap, not a top offset, so there's no dead unhoverable/untappable strip
+   between them" reasoning as .wd-dropdown-menu in dropdown.css) rather
+   than sitting in normal flow beneath it, so opening one of these
+   overlays the accordion rows/sidebar content below it instead of shoving
+   them further down the page. */
+.wd-mobile-accordion-options {
+  position: absolute;
+  top: 100%;
+  left: 0;
+  right: 0;
+  padding-top: 0.35rem;
+}
+.wd-mobile-accordion-options-panel {
+  display: flex;
+  flex-direction: column;
+  gap: 0.3rem;
+  max-height: 45vh;
+  overflow-y: auto;
+  background: var(--wd-background);
+  border: 1px solid var(--wd-border);
+  border-radius: 0.5rem;
+  box-shadow: 0 8px 24px rgba(0, 0, 0, 0.12);
+  padding: 0.4rem;
+}
+.wd-mobile-accordion-options a {
+  display: flex;
+  align-items: center;
+  gap: 0.5rem;
+  padding: 0.55rem 0.65rem;
+  border: 1.5px solid transparent;
+  border-radius: 0.4rem;
+  text-decoration: none;
+  color: var(--wd-text);
+  font-size: 0.9rem;
+}
+.wd-mobile-accordion-options a:hover { background: var(--wd-surface); }
+.wd-mobile-accordion-options a.active {
+  border-color: var(--wd-primary);
+  color: var(--wd-primary);
+  font-weight: 500;
+}
+.wd-mobile-accordion-option-label { flex: 1; min-width: 0; }
+.wd-mobile-accordion-check { flex-shrink: 0; color: var(--wd-primary); }
+.wd-mobile-menu-link {
+  display: flex;
+  align-items: center;
+  gap: 0.5rem;
+  padding: 0.65rem 0.75rem;
+  border: 1px solid var(--wd-border);
+  border-radius: 0.5rem;
+  text-decoration: none;
+  color: var(--wd-navbar-foreground);
+  font-size: 0.9rem;
+}
+.wd-mobile-menu-link:hover { background: var(--wd-surface); }
+/* The sidebar copy living in here needs none of .wd-sidebar-col's own
+   column sizing (width/border/min-height) - it's just flowing content
+   inside an already-padded, already-scrollable panel. */
+.wd-mobile-menu-sidebar .wd-sidebar { padding: 0; }

package/src/layout/styles/search-modal.css

@@ -0,0 +1,122 @@
+/* SearchModal.astro's own styling - the overlay/modal itself, opened by
+   TopBar.astro's .wd-search-trigger button (styled in topbar.css) via
+   src/scripts/search.ts. */
+
+.wd-search-overlay {
+  position: fixed;
+  inset: 0;
+  z-index: 100;
+  display: flex;
+  align-items: flex-start;
+  justify-content: center;
+  padding: 10vh 1rem 2rem;
+  background: rgba(15, 23, 42, 0.5);
+}
+.wd-search-overlay[hidden] { display: none; }
+.wd-search-modal {
+  width: 100%;
+  max-width: 560px;
+  max-height: 70vh;
+  display: flex;
+  flex-direction: column;
+  background: var(--wd-background);
+  border: 1px solid var(--wd-border);
+  border-radius: 0.75rem;
+  box-shadow: 0 20px 60px rgba(0, 0, 0, 0.3);
+  overflow: hidden;
+}
+.wd-search-input-row {
+  display: flex;
+  align-items: center;
+  gap: 0.6rem;
+  padding: 0.85rem 1rem;
+  border-bottom: 1px solid var(--wd-border);
+  flex-shrink: 0;
+  color: var(--wd-text-muted);
+}
+/* Same one-line rule as topbar.css's own copy for the trigger's icon -
+   not worth a shared file over. */
+.wd-search-icon { flex-shrink: 0; }
+.wd-search-input {
+  flex: 1;
+  min-width: 0;
+  border: none;
+  outline: none;
+  background: none;
+  color: var(--wd-text);
+  font-size: 0.95rem;
+  font-family: inherit;
+}
+.wd-search-input::placeholder { color: var(--wd-text-muted); }
+.wd-search-results {
+  overflow-y: auto;
+  padding: 0.5rem;
+}
+/* All of .wd-search-result's contents are built with
+   document.createElement()/innerHTML in src/scripts/search.ts
+   (runSearch()), not by this component's own template - these selectors
+   still need to be here regardless, since a plain imported .css file
+   applies to the whole document either way. */
+.wd-search-result {
+  display: block;
+  padding: 0.65rem 0.8rem;
+  border-radius: 0.55rem;
+  text-decoration: none;
+  color: inherit;
+}
+.wd-search-result:hover,
+.wd-search-result.wd-search-result-active {
+  background: var(--wd-surface);
+}
+.wd-search-result-title {
+  font-size: 0.92rem;
+  font-weight: 600;
+  color: var(--wd-text);
+  margin-bottom: 0.3rem;
+  white-space: nowrap;
+  overflow: hidden;
+  text-overflow: ellipsis;
+}
+/* Clamped to 2 lines rather than left to run however long the matched
+   excerpt happens to be - keeps every result the same rough height so the
+   list reads as a scannable set of rows instead of a wall of wrapped
+   text. */
+.wd-search-result-excerpt {
+  font-size: 0.82rem;
+  color: var(--wd-text-muted);
+  line-height: 1.5;
+  display: -webkit-box;
+  -webkit-line-clamp: 2;
+  -webkit-box-orient: vertical;
+  overflow: hidden;
+}
+/* Pagefind returns each excerpt as sanitized HTML with <mark> around
+   matched terms - restyled to a tinted-primary weight instead of the
+   browser's default yellow highlight, to match the rest of the site's own
+   "tint primary" pattern for active/matched state (sidebar links,
+   selector options, ...). */
+.wd-search-result-excerpt mark {
+  background: none;
+  color: var(--wd-primary);
+  font-weight: 600;
+}
+.wd-search-empty,
+.wd-search-hint {
+  padding: 2rem 1rem;
+  text-align: center;
+  color: var(--wd-text-muted);
+  font-size: 0.85rem;
+}
+/* Same declaration block as topbar.css's own .wd-search-kbd (this
+   component's "Esc" hint instead of the trigger's "⌘K") - duplicated
+   rather than factored into a third shared file for six lines. */
+.wd-search-esc {
+  flex-shrink: 0;
+  font-family: inherit;
+  font-size: 0.7rem;
+  padding: 0.15rem 0.4rem;
+  border-radius: 0.3rem;
+  border: 1px solid var(--wd-border);
+  background: var(--wd-background);
+  color: var(--wd-text-muted);
+}