html,
body {
  min-height: 100%;
  background-color: ghostwhite !important;
  background-image: radial-gradient(circle, lightsteelblue 1px, ghostwhite 1px) !important;
  background-size: 15px 15px !important;
  background-attachment: fixed !important;
}

@media (prefers-color-scheme: dark) {
  html,
  body {
    background-color: hsl(0 0% 10%) !important;
    background-image: radial-gradient(circle, hsl(0 0% 14%) 1px, hsl(0 0% 10%) 1px) !important;
  }
}
/* Forgejo's own theme switcher sets data-theme (forgejo-auto/-light/-dark,
   persisted per-account) independent of prefers-color-scheme. "-auto"
   already matches the OS preference the shared stylesheet reacts to, so
   only the explicit -light/-dark overrides need a rule here -- same fix
   as LLDAP's html.dark/html.light override in
   hosts/blunix/localServices/lldap.nix. */
html[data-theme*="dark"],
html[data-theme*="dark"] body {
  background-color: hsl(0 0% 10%) !important;
  background-image: radial-gradient(circle, hsl(0 0% 14%) 1px, hsl(0 0% 10%) 1px) !important;
}

html[data-theme*="light"],
html[data-theme*="light"] body {
  background-color: ghostwhite !important;
  background-image: radial-gradient(circle, lightsteelblue 1px, ghostwhite 1px) !important;
}

/* Launcher palette's primary/hover pair (palette-2 resting, palette-1
   hover) -- same convention as the guide tile on 0ff.space and LLDAP's
   button override. Only --color-primary itself, not the derived
   -dark-N/-light-N/-alpha-N/-hover/-active shades Forgejo computes from
   it at build time (those stay Forgejo's own, so contrast against its
   own surface colors is preserved in both light and dark). Unconditional
   (not wrapped in the data-theme selectors above): forgejo redefines the
   entire :root block per theme, so a plain :root override here, loaded
   after forgejo's own stylesheet, wins in both regardless. */
:root {
  --color-primary: #d91e4d;
  --color-primary-hover: #ff0026;
  --color-primary-active: #ff0026;
  --color-accent: #d91e4d;
}

/* Dark mode's box/card/nav backgrounds (--color-body, --color-box-header,
   --color-box-body, --color-card, --color-menu, --color-input-background,
   etc.) all derive from this one --steel-* scale, which is blue-tinted,
   not neutral. Replacing it with true grays at roughly the same
   lightness steps -- --steel-700 (--color-box-header/--color-card) lands
   on hsl(0 0% 18%), the same tone as the resting dark tile background on
   0ff.space (see .box in launcher/style.css), so cards read as the same
   material as the launcher tiles instead of Forgejo's own blue-gray.

   Two rules, not one: html[data-theme*="dark"] only matches the
   *explicit* forgejo-dark/gitea-dark theme choice, never the default
   "forgejo-auto" -- that string never contains "dark" even while it's
   visually rendering dark via the OS preference. Missed this the first
   time around: only the explicit rule existed, so this only ever took
   effect for someone who'd manually switched off "auto". */
html[data-theme*="dark"] {
  --steel-900: hsl(0 0% 8%);
  --steel-850: hsl(0 0% 10%);
  --steel-800: hsl(0 0% 12%);
  --steel-750: hsl(0 0% 15%);
  --steel-700: hsl(0 0% 18%);
  --steel-650: hsl(0 0% 24%);
  --steel-600: hsl(0 0% 25%);
  --steel-550: hsl(0 0% 30%);
  --steel-500: hsl(0 0% 35%);
  --steel-450: hsl(0 0% 41%);
  --steel-400: hsl(0 0% 47%);
  --steel-350: hsl(0 0% 54%);
  --steel-300: hsl(0 0% 61%);
  --steel-250: hsl(0 0% 68%);
  --steel-200: hsl(0 0% 74%);
  --steel-150: hsl(0 0% 81%);
  --steel-100: hsl(0 0% 88%);
}

@media (prefers-color-scheme: dark) {
  html[data-theme="forgejo-auto"] {
    --steel-900: hsl(0 0% 8%);
    --steel-850: hsl(0 0% 10%);
    --steel-800: hsl(0 0% 12%);
    --steel-750: hsl(0 0% 15%);
    --steel-700: hsl(0 0% 18%);
    --steel-650: hsl(0 0% 24%);
    --steel-600: hsl(0 0% 25%);
    --steel-550: hsl(0 0% 30%);
    --steel-500: hsl(0 0% 35%);
    --steel-450: hsl(0 0% 41%);
    --steel-400: hsl(0 0% 47%);
    --steel-350: hsl(0 0% 54%);
    --steel-300: hsl(0 0% 61%);
    --steel-250: hsl(0 0% 68%);
    --steel-200: hsl(0 0% 74%);
    --steel-150: hsl(0 0% 81%);
    --steel-100: hsl(0 0% 88%);
  }
}

/* .flex-item-trailing.muted-links wraps exactly the language dot,
   star count, and fork count on repo list rows (explore, user profile,
   org pages) -- nothing else, confirmed against /explore/repos'
   rendered HTML. */
.flex-item-trailing.muted-links {
  display: none !important;
}

/* Explore: center repo names instead of left-aligned. */
.page-content.explore .flex-item-header {
  justify-content: center;
}

/* Wiki pages: content (+ its TOC sidebar) directly after the site
   navbar, everything else -- the lukas/nixos-config breadcrumb, watch/
   star/fork buttons, and the Code/Issues/Pulls/.../Wiki tab bar (all
   inside .secondary-nav), the page title/revision-count/"edited this
   page" line (.ui.dividing.header), and the page-picker/clone-panel
   button row -- pushed below it instead of above. Confirmed working
   live on /wiki/userguide across three iterations: the reorder itself,
   then the breadcrumb+tabs (.secondary-nav wasn't reordered the first
   time), then the title/revision header (a third direct child of
   .ui.container.file-content the first two passes didn't touch). */
.page-content.repository.wiki {
  display: flex;
  flex-direction: column;
}
.page-content.repository.wiki > .secondary-nav {
  order: 2;
}
.page-content.repository.wiki .ui.container.file-content {
  display: flex;
  flex-direction: column;
  order: 1;
}
.page-content.repository.wiki .repo-button-row {
  order: 1;
}
.page-content.repository.wiki .ui.container.file-content > .ui.dividing.header {
  order: 1;
}