@writedocs/generator 0.1.0

package/src/layout/styles/topbar.css

@@ -0,0 +1,437 @@
+/* TopBar.astro's own styling. Also imported by MobileMenu.astro, for two
+   classes its own drawer header reuses verbatim: .wd-topbar-brand (the
+   brand link, replicated in the drawer's own header) and .wd-theme-toggle
+   (the drawer renders its own second copy of this button - see
+   src/scripts/theme-toggle.ts for why that's safe). */
+
+.wd-topbar {
+  border-bottom: 1px solid var(--wd-border);
+  position: sticky;
+  top: 0;
+  /* --wd-navbar-background - falls back to the page's own --wd-background
+     when writedocs.json doesn't set theme.colors.navbar (see BaseLayout.astro),
+     so an unconfigured navbar keeps blending into the page as before. */
+  background: var(--wd-navbar-background);
+  z-index: 10;
+}
+/* Two stacked rows: brand + switchers on top, tabs/global dropdowns
+   underneath - only the top row is always present, the second only
+   renders when the writedocs.json actually has tabs or global dropdowns. */
+.wd-topbar-row-brand {
+  /* border-bottom: 1px solid var(--wd-border); */
+}
+.wd-topbar-row-brand:last-child {
+  border-bottom: none;
+}
+.wd-topbar-inner {
+  max-width: 1440px;
+  margin: 0 auto;
+  padding: 0.75rem 0;
+  display: flex;
+  align-items: center;
+  gap: 1rem;
+}
+.wd-topbar-row-tabs .wd-topbar-inner {
+  padding-top: 0.4rem;
+  /* No bottom padding, deliberately - .wd-tab-link's own border-bottom
+     (below) sits flush against this row's bottom edge (the outer
+     .wd-topbar's own border-bottom, since this is the last row) rather
+     than floating partway up inside a padded gap. That's what lets a
+     plain border-bottom color change read as a real underline on hover,
+     and what makes the active tab's own fill look like it's actually
+     attached to the row's bottom edge instead of a floating pill. */
+  padding-bottom: 0;
+}
+.wd-topbar-brand {
+  display: flex;
+  align-items: center;
+  gap: 0.5rem;
+  font-weight: 600;
+  text-decoration: none;
+  /* --wd-navbar-foreground, not --wd-text - falls back to var(--wd-text)
+     when theme.navbar has no `foreground` set (see BaseLayout.astro), so
+     this is a no-op for the common case; only matters once a site's
+     navbar background is far enough from the page background that
+     --wd-text reads poorly against it. Also picked up by
+     MobileMenu.astro's own copy of this same class in its drawer header -
+     see this file's own top comment. */
+  color: var(--wd-navbar-foreground);
+  font-size: 1.05rem;
+  flex-shrink: 0;
+}
+/* Switchers sit right next to the brand (no auto margin here) -
+   .wd-topbar-links below is what gets pushed to the far right. */
+.wd-topbar-switchers {
+  display: flex;
+  align-items: center;
+  gap: 0.4rem;
+}
+/* --wd-navbar-border, not --wd-border - falls back to the literal
+   var(--wd-border) reference when theme.navbar isn't configured (see
+   BaseLayout.astro), so this is a no-op for the common case. Once a
+   navbar background is set, though, the flat neutral --wd-border reads as
+   a harsh, near-white outline against it (not picked with any navbar hue
+   in mind) - --wd-navbar-border is a soft tint of the navbar's own
+   already-contrast-correct text color instead, so the pill's edge stays
+   legible without standing out. */
+.wd-switcher-trigger {
+  border: 1px solid var(--wd-navbar-border);
+}
+/* .wd-dropdown-trigger's own base rule (dropdown.css) is deliberately
+   generic - it's shared by every dropdown in the codebase, including
+   CopyPageMenu.astro's trigger, which sits on the ordinary page
+   background, not the navbar's. Overriding it here, scoped to `.wd-topbar`
+   specifically (which every dropdown trigger this file renders - the
+   version/language/product switchers, a tab-as-dropdown, the small-screen
+   topbar.links ellipsis - actually lives inside), is what lets the topbar's
+   own triggers pick up --wd-navbar-foreground-muted without touching that
+   unrelated one. Two classes beats dropdown.css's one-class base rule on
+   specificity regardless of the two files' own import order, so this is
+   safe either way. The caret arrow inside needs no rule of its own - its
+   `stroke="currentColor"` already inherits whatever `color` wins here. */
+.wd-topbar .wd-dropdown-trigger {
+  color: var(--wd-navbar-foreground);
+}
+.wd-topbar .wd-dropdown-trigger:hover {
+  color: var(--wd-navbar-foreground);
+}
+.wd-topbar-tabs {
+  display: flex;
+  /* stretch (not center) - every direct flex item in this row (a plain
+     .wd-tab-link <a>, or the .wd-dropdown <div> wrapping a tab-as-
+     dropdown's own trigger <button>) now spans this row's full height,
+     so its own border-bottom (see .wd-tab-link below) always lands
+     exactly on the row's bottom edge. Centering by natural content
+     height instead would leave a gap for a <button>-based item: browsers
+     give <button> a shorter default line-height than the 1.6 an <a>
+     inherits from <body>, and TopBar.astro doesn't override it - so an
+     un-stretched trigger button ends up genuinely shorter than a plain
+     tab, and centering it within the row leaves empty space above *and*
+     below it instead of flush at the bottom. Real bug this fixes, not a
+     hypothetical - a dropdown-as-tab's hover border-bottom used to sit
+     visibly above the row's own divider line instead of touching it. */
+  align-items: stretch;
+  gap: 0.25rem;
+  flex: 1;
+  flex-wrap: wrap;
+}
+/* .wd-dropdown itself is just a plain block (position: relative, for its
+   own .wd-dropdown-menu to anchor to) - stretching *it* to the row's
+   height (above) doesn't automatically stretch its child trigger
+   <button> too, since a plain block doesn't center/stretch its own
+   children. display: flex makes it a flex container of its own single
+   child - flexbox's own default align-items is already 'stretch', so
+   the trigger button fills it completely with no extra rule needed.
+   Scoped to just this row (not every .wd-dropdown site-wide - switcher
+   triggers and CopyPageMenu.astro also use this same class, and don't
+   have this row's height-flushing concern) so nothing about their own
+   layout changes. Applies to both a tab-as-dropdown's own wrapper and a
+   global-dropdown's, when either renders inside the tabs row - keeping
+   both consistent with each other, not just with plain tabs. */
+.wd-topbar-tabs .wd-dropdown {
+  display: flex;
+}
+.wd-tab-link {
+  display: flex;
+  align-items: center;
+  gap: 0.4rem;
+  padding: 0.2rem 0.625rem;
+  /* Rounded top corners, square bottom - reads as an actual "tab"
+     attached to the row's bottom edge (see .wd-topbar-row-tabs
+     .wd-topbar-inner's own comment) rather than a floating pill. Same
+     radius for every tab, active or not, so nothing needs to change
+     shape on top when a tab becomes active - only the fill/border-bottom
+     below do. */
+  border-radius: 0.5rem 0.5rem 0 0;
+  /* Transparent by default - this is what a hover (below) or the active
+     state colors in, rather than a separate underline element. Sized to
+     land exactly on the row's own bottom edge now that this row's inner
+     wrapper has no bottom padding of its own. */
+  border-bottom: 2px solid transparent;
+  text-decoration: none;
+  color: var(--wd-navbar-foreground);
+  font-size: 0.92rem;
+  font-weight: 600;
+}
+/* The selected tab: a solid fill, not just a tinted background -
+   AppIcon's <svg> render mode already uses fill="currentColor" (astro-
+   icon's default), so its icon recolors along with the text; the
+   emoji/text <span> fallback inherits `color` the same way.
+   border-bottom-color matches the fill (rather than being reset to
+   transparent) so there's no 2px seam of the row's own background
+   showing between the fill and the row's bottom edge/border.
+   --wd-navbar-accent (falls back to --wd-primary - see BaseLayout.astro),
+   not a bare --wd-primary reference: without this, a site whose navbar
+   background *is* --wd-primary (a plausible "brand-colored navbar" choice
+   - the exact case that motivated this variable) would have its active
+   tab's own fill disappear into the row's background entirely. Text color
+   is --wd-navbar-accent-text (also BaseLayout.astro) rather than a
+   hardcoded #fff for the matching reason - a light accent color needs
+   dark text, not white, to stay legible on top of it. */
+.wd-tab-link.active {
+  color: var(--wd-navbar-accent-text);
+  background: var(--wd-navbar-accent);
+  border-bottom-color: var(--wd-navbar-accent);
+}
+/* Inactive tabs just get their border-bottom colored in on hover -
+   simpler than a separate underline element, and lines up naturally
+   with the active tab's own border-bottom above since both are the same
+   property. Text/icon color deliberately stays as-is on hover (only the
+   border appears), matching the reference this was built against. */
+.wd-tab-link:hover:not(.active) {
+  border-bottom-color: var(--wd-navbar-accent);
+}
+.wd-topbar-links {
+  display: flex;
+  gap: 1.25rem;
+  font-size: 0.9rem;
+  flex-shrink: 0;
+  margin-left: auto;
+}
+.wd-topbar-links a {
+  display: inline-flex;
+  align-items: center;
+  gap: 0.35rem;
+  text-decoration: none;
+  color: var(--wd-navbar-foreground-muted);
+}
+.wd-topbar-links a:hover {
+  color: var(--wd-navbar-foreground);
+}
+/* Hidden above 860px - .wd-topbar-links (the plain inline row) is what
+   shows there instead. Same margin-left: auto as that row so it lands in
+   the same "pushed to the far right, right before search/theme" spot once
+   the media query below swaps which of the two is visible. */
+.wd-topbar-links-mobile {
+  display: none;
+  margin-left: auto;
+  flex-shrink: 0;
+}
+/* The extra .wd-topbar-links-mobile qualifier (2 classes) is load-bearing,
+   not decoration: a bare .wd-topbar-links-toggle selector would tie on
+   specificity with .wd-dropdown-trigger's own padding/width (dropdown.css)
+   - whichever of the two files happens to load/cascade later would
+   silently win regardless of intent, and this button needs to reliably
+   become a square icon button, not keep the trigger's default text-button
+   padding. */
+.wd-topbar-links-mobile .wd-topbar-links-toggle {
+  width: 2rem;
+  height: 2rem;
+  justify-content: center;
+  padding: 0;
+}
+.wd-topbar-links-mobile .wd-dropdown-menu {
+  left: auto;
+  right: 0;
+}
+
+/* The topbar trigger looks like a real search box but is a <button>, not
+   an <input> - it never accepts text itself, clicking (or the ⌘K/Ctrl K
+   shortcut, see src/scripts/search.ts) opens the real .wd-search-modal
+   (SearchModal.astro) instead. A genuinely-typable fake input would be
+   confusing (why can't I select my typed text after opening the modal?)
+   and worse for a11y than a button that's honest about being a button. */
+.wd-search-trigger {
+  display: flex;
+  align-items: center;
+  gap: 0.5rem;
+  width: 100%;
+  max-width: 220px;
+  padding: 0.4rem 0.6rem;
+  border: 1px solid var(--wd-border);
+  border-radius: 0.5rem;
+  background: var(--wd-surface);
+  /* Deliberately NOT --wd-navbar-foreground(-muted) - this box always sits
+     on --wd-surface (a fixed light/dark neutral), never on the navbar's
+     own background, so tying its text to the navbar's computed contrast
+     color is wrong: a navbar dark enough to need white text would make
+     this white-on-light-surface text unreadable (the actual bug this
+     replaced). --wd-text-muted instead - same var the "Ctrl K" kbd chip
+     inside this same trigger already uses, so both pieces of text read as
+     one consistent color, and it already tracks light/dark mode on its
+     own without a separate [data-theme="dark"] override here. */
+  color: var(--wd-text-muted);
+  font-size: 0.85rem;
+  font-family: inherit;
+  cursor: pointer;
+  flex-shrink: 1;
+}
+.wd-search-trigger:hover {
+  border-color: color-mix(in srgb, var(--wd-navbar-accent) 40%, var(--wd-border));
+}
+/* Also used (as its own copy) by SearchModal.astro's own input row - one
+   line, not worth a shared file over. */
+.wd-search-icon {
+  flex-shrink: 0;
+}
+.wd-search-placeholder {
+  flex: 1;
+  text-align: left;
+  overflow: hidden;
+  text-overflow: ellipsis;
+  white-space: nowrap;
+}
+/* .wd-search-kbd (this trigger's "⌘K" hint) and SearchModal.astro's own
+   .wd-search-esc share this exact declaration block - duplicated there
+   rather than factored into a third shared file for six lines. */
+.wd-search-kbd {
+  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);
+}
+
+.wd-theme-toggle {
+  position: relative;
+  display: flex;
+  align-items: center;
+  justify-content: center;
+  width: 2rem;
+  height: 2rem;
+  padding: 0;
+  border: none;
+  border-radius: 0.4rem;
+  background: none;
+  cursor: pointer;
+  color: var(--wd-navbar-foreground-muted);
+  flex-shrink: 0;
+  overflow: hidden;
+}
+/* Softer than a flat --wd-surface swap or a text-color change (both read
+   as too strong a jolt, and the color swap doesn't help legibility here
+   the way it does for e.g. .wd-topbar-links) - a low-opacity tint of the
+   navbar's own foreground, so it stays a subtle "this is hoverable" cue
+   against any navbar background/mode instead of a hard color flip. */
+.wd-theme-toggle:hover {
+  background: color-mix(in srgb, var(--wd-navbar-foreground) 12%, transparent);
+}
+/* Both icons occupy the same spot (absolutely positioned, centered on the
+   button) so exactly one is ever visible - the inactive one is
+   faded/rotated/scaled out rather than display:none'd, which is what
+   gives the click a smooth crossfade instead of an instant swap.
+   [data-theme] is what actually drives which state is active; the
+   toggle's click handler (src/scripts/theme-toggle.ts) just flips that
+   attribute, so this transition runs automatically whenever it changes,
+   including via the OS-preference/localStorage choice on first load. */
+.wd-theme-icon {
+  position: absolute;
+  top: 50%;
+  left: 50%;
+  width: 1.1em;
+  height: 1.1em;
+  transform: translate(-50%, -50%) rotate(0deg) scale(1);
+  opacity: 1;
+  transition:
+    transform 0.35s ease,
+    opacity 0.25s ease;
+}
+.wd-theme-icon-moon {
+  opacity: 0;
+  transform: translate(-50%, -50%) rotate(-90deg) scale(0.5);
+}
+[data-theme="dark"] .wd-theme-icon-sun {
+  opacity: 0;
+  transform: translate(-50%, -50%) rotate(90deg) scale(0.5);
+}
+[data-theme="dark"] .wd-theme-icon-moon {
+  opacity: 1;
+  transform: translate(-50%, -50%) rotate(0deg) scale(1);
+}
+
+/* The hamburger-turned-close button (below 860px only) that opens
+   MobileMenu.astro's own panel - rendered as the first child of
+   .wd-topbar-inner, so its styling lives here alongside the rest of the
+   topbar row rather than with the panel it opens. */
+.wd-mobile-menu-toggle {
+  display: none;
+  position: relative;
+  align-items: center;
+  justify-content: center;
+  width: 2rem;
+  height: 2rem;
+  padding: 0;
+  border: none;
+  border-radius: 0.4rem;
+  background: none;
+  cursor: pointer;
+  color: var(--wd-navbar-foreground-muted);
+  flex-shrink: 0;
+}
+.wd-mobile-menu-toggle:hover {
+  color: var(--wd-navbar-foreground);
+  background: var(--wd-surface);
+}
+/* Same crossfade-two-icons-in-place technique as .wd-theme-toggle's
+   sun/moon above - .open (set by initMobileMenu(), src/scripts/mobile-menu.ts)
+   swaps which of the two is visible. */
+.wd-mobile-menu-icon {
+  position: absolute;
+  top: 50%;
+  left: 50%;
+  transform: translate(-50%, -50%) rotate(0deg) scale(1);
+  opacity: 1;
+  transition:
+    transform 0.35s ease,
+    opacity 0.25s ease;
+}
+.wd-mobile-menu-icon-close {
+  opacity: 0;
+  transform: translate(-50%, -50%) rotate(-90deg) scale(0.5);
+}
+.wd-mobile-menu-toggle.open .wd-mobile-menu-icon-bars {
+  opacity: 0;
+  transform: translate(-50%, -50%) rotate(90deg) scale(0.5);
+}
+.wd-mobile-menu-toggle.open .wd-mobile-menu-icon-close {
+  opacity: 1;
+  transform: translate(-50%, -50%) rotate(0deg) scale(1);
+}
+
+@media (max-width: 1500px) {
+  .wd-topbar-inner,
+  .wd-shell {
+    padding: 0.75rem;
+  }
+}
+
+@media (max-width: 860px) {
+  .wd-search-trigger {
+    max-width: none;
+    order: 1;
+    flex-basis: 100%;
+  }
+}
+@media (max-width: 860px) {
+  .wd-topbar-inner {
+    flex-wrap: wrap;
+    gap: 0.75rem;
+  }
+  /* Both move into MobileMenu.astro's own panel instead - version/
+     language/product/nested-dropdown switchers as one accordion row each,
+     the tabs bar and global dropdowns alongside them, all reusing the
+     same `selectors`/`globalDropdowns` props this row already renders
+     from. */
+  .wd-topbar-switchers {
+    display: none;
+  }
+  .wd-topbar-row-tabs {
+    display: none;
+  }
+  /* The inline link row would otherwise wrap onto its own line next to
+     the brand/theme controls, eating vertical space - collapsed behind
+     the single ellipsis button (.wd-topbar-links-mobile) instead, which
+     reuses the existing dropdown mechanism. */
+  .wd-topbar-links {
+    display: none;
+  }
+  .wd-topbar-links-mobile {
+    display: block;
+  }
+  .wd-mobile-menu-toggle {
+    display: flex;
+  }
+}