/* Theme-owned rules — NOT vendored from salamcendekia-design.

   Every other stylesheet under assets/css/ is copied byte-for-byte from
   `systems/blog` and is verified as such by tests/test-salcen-theme.php. A
   hand-edit there is a silent fork: the design repo bumps its VERSION, the
   copy does not change, and nothing detects the drift.

   So rules the theme needs and the system does not yet ship live HERE, in a
   file the design repo has no opinion about. Loaded after `components.css`, so
   it can build on the system's tokens without patching the system's files.

   When `systems/blog` grows a related-articles component, these rules should be
   deleted in favour of it rather than kept alongside. */

/* "Baca juga" — related articles, between the article header and its body.

   Sits OUTSIDE `.prose`, so it inherits none of the article type scale and
   must set its own, the same reason `.post-card-standfirst` does. Uses
   `--text-chrome`: this is navigation around the article, not article body. */
.related-inline {
  /* SHARES THE ARTICLE'S COLUMN, and it has to be said here.

     `components.css` centres the column with
     `.content-main > .article-header, .content-main > .prose { margin-inline:
     auto; }` -- a rule that names its children explicitly. This `<aside>` is a
     third child of `.content-main`, so it matched neither selector, had no
     measure of its own, and stretched the full width of the padding box: the
     label started hard against the page gutter while the title and body began
     further in. Shipped that way in #41 and #44 because nothing renders the
     three siblings together in a test, so the misalignment was only ever
     visible to someone looking at the page.

     THE MEASURE IS RESOLVED IN THE PROSE'S TYPE CONTEXT, not this block's,
     and that distinction is the whole fix.

     `--text-measure` is `68ch` -- deliberately, so the column tracks the type
     scale rather than freezing a pixel width. But `ch` resolves against the
     ELEMENT'S OWN font-size, and this aside sets `--text-chrome` (16px) while
     `.prose` sets `--text-article-body` (19px). Writing `max-width:
     var(--text-measure)` here therefore produced 653px against the prose's
     775px: the same token, a different column, and the block aligned with the
     `.article-header` (which is also 16px) instead of the body it introduces.
     Measured in a browser -- the first fix looked right in the stylesheet and
     was 62px out on the page.

     So the width is computed at the body size explicitly. `em` is this
     element's font-size, so `--text-article-body / --text-chrome` scales the
     measure by exactly the ratio between the two contexts, and the result
     moves with the type scale the way the token intends.

     `box-sizing: border-box` keeps the border and padding below INSIDE that
     measure. Without it the block would measure the full column plus its own
     inline padding and sit wider than the prose, which is the same
     misalignment a few pixels smaller. */
  box-sizing: border-box;
  max-width: calc(
    var(--text-measure) * (var(--text-article-body) / var(--text-chrome))
  );
  margin-block: var(--space-card);
  margin-inline: auto;
  padding-inline-start: var(--space-card);
  /* A rule rather than a filled box: the block interrupts the article, and a
     tinted panel at this position reads as an ad to a reader scanning past. */
  border-inline-start: var(--border-hairline) solid var(--color-border);
}

.related-inline-label {
  margin-block: 0 calc(var(--space-card) / 3);
  font-family: var(--text-family-heading);
  font-size: var(--text-chrome);
  font-weight: var(--text-heading-weight);
  line-height: var(--text-chrome-leading);
  color: var(--color-heading);
}

.related-inline-list {
  margin-block: 0;
  padding-inline-start: 0;
  list-style: none;
}

.related-inline-list li + li {
  margin-block-start: calc(var(--space-card) / 4);
}

.related-inline-list a {
  font-size: var(--text-chrome);
  line-height: var(--text-chrome-leading);
  color: var(--color-link);
  text-decoration: none;
}

.related-inline-list a:hover,
.related-inline-list a:focus-visible {
  color: var(--color-link-hover);
  text-decoration: underline;
}

/* The collapsible header — theme-owned, and deliberately not upstreamed.

   `systems/blog` ships `collapsed` and `open` as SEPARATE DOCUMENTS, because a
   static design renders one width at a time and `_app-shell`'s rule is that
   "the state decides which control exists". That is right for a design: a
   single document mounting both controls and letting CSS pick is the
   `hidden md:flex` pattern the rule rejects, and `keyboard.mjs` failed exactly
   that when it was tried in design#132.

   A SERVER-RENDERED PAGE IS DIFFERENT IN ONE RESPECT, and it is the respect
   that matters: it is one document that must be correct at every width, and it
   can carry a script. So the page emits both structures and this file decides
   which is live at each width -- but neither is `display: none` at EVERY
   width, which is the condition the rule actually names. The button is
   reachable below 48rem; the inline links are reachable above it.

   The hinge is the system's own `--bp-chrome-inline`, written as the literal
   `48rem` because a custom property cannot appear in an `@media` condition.
   `foundation/semantic/breakpoints.css` is the record of what it means. */

/* ABOVE THE HINGE: the inline row, no button, no panel.
   Declared first so the query below overrides it -- same specificity, so the
   later rule wins, which is the way round a width query has to work. */
.site-menu-toggle,
.site-menu-panel {
  display: none;
}

@media (width < 48rem) {
  /* BELOW THE HINGE: the button replaces the links and the inline CTA.

     The panel stays `hidden` until the toggle opens it -- that attribute is
     the closed state, and it is honest to assistive technology without any
     CSS. This rule only says that when it is NOT hidden, it lays out. */
  .site-links,
  .site-cta-inline {
    display: none;
  }

  .site-menu-toggle {
    display: inline-flex;
  }

  /* NO MENU, NO TOGGLE -- SO THE CTA STAYS INLINE.
     `header.php` renders the button and the panel together or not at all, so a
     site with no menu assigned to `primary` has neither. Without this rule the
     inline CTA would still be hidden by the block above and a phone reader
     would see NO call to action at all -- the blog's one conversion link,
     invisible at the width most readers use. Reproduced in review of #44.
     `:has()` asks the question directly: hide the inline pill only when
     something exists to replace it. */
  .site-header:not(:has(.site-menu-toggle)) .site-cta-inline {
    display: inline-flex;
  }

  .site-menu-panel:not([hidden]) {
    display: block;
  }
}