/* The site bar, shared by facecue.net and the documentation.
 *
 * ONE source, two builds. Eleventy passthrough-copies src/static to the site
 * root, so this lands at /assets/topbar.css. The MkDocs hook at
 * documentation/hooks/site_chrome.py adds the same source file to the docs
 * build as stylesheets/topbar.css. Neither build reaches across to the other at
 * runtime, so an isolated `mkdocs serve` still styles the bar correctly.
 *
 * ⛔ Edit this file, never a built copy. There is no second copy to keep in
 * step, and adding one is how a nav bar drifts on every page of one property.
 *
 * ⛔⛔ THE BAR'S OWN METRICS ARE IN PIXELS, DELIBERATELY. Material for MkDocs
 * sets `html { font-size: 125% }`, so the documentation's root is 20px where the
 * Eleventy site's is 16px. Every rem here therefore resolved 25% larger inside
 * the documentation, and the same bar came out 52px tall with 14.4px text there
 * against 41.6px and 11.5px on the site. A component shared across two
 * typographic contexts cannot take its size from whichever page it lands on.
 * Sizes are px, and anything that should scale with the bar's own text is em.
 *
 * The ONE exception is --fc-bar-grid below, which is intentionally rem: it
 * tracks each property's own content grid so the mark lines up with the page
 * beneath it, and the two grids are genuinely different widths.
 *
 * Colours come from the documentation theme's own tokens where they exist
 * (facecue.css defines --fc-* on the Material scheme), and fall back to the
 * same literal values on the Eleventy site, which has no Material theme. That
 * is why every var() here carries a fallback: the site would otherwise resolve
 * them against nothing, and a custom property that resolves to nothing makes
 * the whole declaration invalid, silently.
 */

.fc-sitebar {
  /* Not sticky. Material's own header sticks below it, so on scroll the site
     bar leaves and the documentation chrome stays, which is the behaviour you
     want when reading a long page. */
  position: relative;
  z-index: 5;
  display: flex;
  align-items: center;
  gap: 24px;
  padding: 0 20px;
  height: 42px;
  background: var(--fc-panel, #141414);
  border-bottom: 1px solid var(--fc-section-border, #3A3836);
  font-family: Inter, system-ui, -apple-system, "Segoe UI", sans-serif;
  font-size: 12.5px;
  letter-spacing: 0.04em;
  box-sizing: border-box;
}

/* ⛔⛔ FULL BLEED, NOT CENTRED ON A GRID. This started as `max-width: 76rem`,
   so the bar tracked each property's own content grid. That put the mark at
   x=235 on the site and x=20 in the documentation at the same 1700px viewport,
   a 215px jump every time someone crossed between them.
   The two grids cannot be reconciled: the site's is a fixed 1216px, while
   Material's root font-size SCALES WITH THE VIEWPORT (125%, then 137.5% above
   1600px, then 150%), so its 76rem grid is 1520px at one width and 1672px at
   another. There is no shared number to centre on.
   So the bar hugs the edges with fixed padding instead. The mark lands on the
   same pixel on every page of both properties, at every width, and it sits
   near Material's own edge-hugging header rather than floating inset above it.
   The page content below stays centred on its own grid, which is what a
   full-width chrome strip over inset content is supposed to look like. */
.fc-sitebar__inner {
  display: flex;
  align-items: center;
  gap: 24px;
  width: 100%;
}

/* The mark, matching the wordmark the rest of the property uses. */
.fc-sitebar__mark {
  display: flex;
  align-items: baseline;
  gap: 9px;
  text-decoration: none;
  border: 0;
  white-space: nowrap;
}

.fc-sitebar__glyph {
  font-family: "EB Garamond", Georgia, serif;
  font-size: 17px;
  line-height: 1;
  color: var(--fc-tan, #D0C090);
}

.fc-sitebar__word {
  font-weight: 500;
  letter-spacing: 0.22em;
  text-transform: uppercase;
  font-size: 11.5px;
  color: var(--fc-text-label, #DBDBE0);
}

/* The half of the product name a store browse card truncates away, so it is the
   part the site has to say for itself. Quieter than the name, and it drops out
   below the width where it would start competing with the links. */
.fc-sitebar__studio {
  font-weight: 400;
  letter-spacing: 0.18em;
  text-transform: uppercase;
  font-size: 10.5px;
  color: var(--fc-text-muted, #8A857F);
  padding-left: 9px;
  border-left: 1px solid var(--fc-section-border, #3A3836);
}

.fc-sitebar__links {
  display: flex;
  align-items: center;
  gap: 22px;
  margin-left: auto;
}

.fc-sitebar__link {
  color: var(--fc-text-muted, #8A857F);
  text-decoration: none;
  border: 0;
  padding: 4px 0;
  border-bottom: 1px solid transparent;
  transition: color 0.15s ease, border-color 0.15s ease;
  white-space: nowrap;
}

.fc-sitebar__link:hover,
.fc-sitebar__link:focus-visible {
  color: var(--fc-tan-bright, #E6D8A8);
  border-bottom-color: var(--fc-hairline, #7A6A40);
}

/* The current section. Marked with aria-current so it is announced, not only
   seen. */
.fc-sitebar__link[aria-current] {
  color: var(--fc-tan, #D0C090);
  border-bottom-color: var(--fc-tan, #D0C090);
}

/* The one link that is a call to action rather than navigation, so it is a
   button rather than a fifth peer. */
.fc-sitebar__cta {
  color: var(--fc-tan-bright, #E6D8A8);
  text-decoration: none;
  border: 1px solid var(--fc-hairline, #7A6A40);
  border-radius: 2px;
  padding: 5px 14px;
  transition: background 0.15s ease, color 0.15s ease;
  white-space: nowrap;
}

.fc-sitebar__cta:hover,
.fc-sitebar__cta:focus-visible {
  background: var(--fc-olive, #6A5A4A);
  color: var(--fc-tan-bright, #E6D8A8);
}

/* Media-query lengths are safe as rem: inside a media query, rem resolves
   against the initial font size rather than the root element's, so these break
   at the same viewport width on both properties despite Material's 125% root. */
@media (max-width: 62rem) {
  .fc-sitebar__studio { display: none; }
}

/* Narrow screens: the mark keeps its place, the links wrap under it and the bar
   grows rather than scrolling sideways. A horizontally scrolling nav is the one
   thing worse than a tall one. */
@media (max-width: 46rem) {
  .fc-sitebar {
    height: auto;
    padding: 8px 16px 10px;
  }

  .fc-sitebar__inner {
    flex-wrap: wrap;
    gap: 8px 18px;
  }

  .fc-sitebar__links {
    margin-left: 0;
    width: 100%;
    flex-wrap: wrap;
    gap: 7px 18px;
  }
}

/* ---- Inside the documentation only ------------------------------------- */

/* Material puts a top offset on the main container to clear its own sticky
   header. The site bar is in normal flow above it, so nothing needs adjusting,
   but Material's header must not paint over the bar's bottom rule. */
.md-header {
  box-shadow: none;
}

/* Line Material's header up under the bar, so the two /a/ marks stack instead of
   reading as staggered.
   ⛔ The fix goes here, on Material's header, NOT on the bar. Nudging the bar in
   the documentation would put its mark on a different pixel from the site's and
   reintroduce exactly the cross-property jump this file exists to prevent. The
   bar is the fixed thing; the header moves to meet it.
   ⛔ Three offsets stack, and missing any of them moves the mark the wrong way.
   The documentation's /a/ is not a logo element, it is a ::before on
   `.md-header__topic` (see facecue.css), so it starts wherever the TITLE starts,
   not where the header does. The title sits inside `.md-header__title`, which
   has its own left offset, inside `.md-header__inner`, which has both a 6.5px
   margin and 4.4px of padding. Setting the inner's padding alone pushed the mark
   from 33px out to 48px, further from the bar rather than nearer. All three have
   to be zeroed and replaced by the bar's own 20px.
   The right edge is left alone: Material's search field carries internal padding
   of its own, so its box edge sits 13px inboard of the bar's button. Different
   content, and not worth chasing. */
.md-header__inner {
  margin-left: 0;
  margin-right: 0;
  padding-left: 20px;
  padding-right: 20px;
}

/* ⛔ Two classes, not one. Material sets `margin-left` on `.md-header__title`
   itself, and a single-class rule here ties on specificity and loses on source
   order, silently: the mark stayed 22px out with no error anywhere. This theme
   has lost that same argument to Material several times, always the same way. */
.md-header__inner .md-header__title {
  margin-left: 0;
  padding-left: 0;
}

/* Material's light scheme would leave the bar dark against a cream page. Keep
   the bar readable in both schemes by letting the tokens do the work: the
   light scheme redefines --fc-panel and the text colours, and the bar follows.
   ⛔ Do not hardcode the dark values here, the fallbacks above are for the
   Eleventy site, which has exactly one scheme. */
[data-md-color-scheme="facecue-light"] .fc-sitebar {
  background: var(--fc-panel);
  border-bottom-color: var(--fc-section-border);
}