/* Hizashikan — the only stylesheet additions since the approved build
 *
 * styles.css is frozen and byte-identical to hizashikan-site/assets/css/styles.css.
 * Anything genuinely new therefore lives here, loaded after it, so the original file
 * stays diffable against the design hand-off forever.
 *
 * Keep this file small. If it starts growing, that is a sign the design is changing and
 * the change belongs in a conversation, not in a stylesheet.
 */

/* ------------------------------------------------------------------
   Footer legal row

   A quieter third row, between the 13-link footer nav and the base line carrying
   the copyright. Sized between the two — smaller and dimmer than .site-footer__nav,
   a touch more present than .site-footer__base — so the policies are findable
   without competing with the real navigation.

   Values are taken from the existing footer rules rather than invented: the same
   rgba washi tints, the same hover treatment, the same flex-wrap behaviour.
   ------------------------------------------------------------------ */
.site-footer__legal {
  display: flex;
  gap: 22px;
  flex-wrap: wrap;
  margin-bottom: 26px;
  font-size: 12.5px;
}

.site-footer__legal a {
  color: rgba(246, 240, 227, .5);
  text-decoration: none;
  transition: color .2s;
}

.site-footer__legal a:hover,
.site-footer__legal a:focus-visible {
  color: rgba(246, 240, 227, .85);
}

/* ------------------------------------------------------------------
   Friends of Hizashikan  (縁)

   Reuses the testimonial card wholesale — .letter already provides the washi
   surface, border, radius, padding and shadow — and only changes what a card
   about a dojo needs that a card about a quotation does not:

     - .letter::before injects a 「 opening quote mark. A club's name is not a
       quotation, so it is suppressed here and replaced by the name itself.
     - A name needs to lead the card, in the label register the design uses for
       .letter__who, but at the top and in ink rather than stone.
     - Logos are optional and constrained. The design system has no logo-wall
       pattern; a friend is a name and a sentence, and any mark is incidental.

   Every value below is an existing token or copied from the rule it sits beside.
   ------------------------------------------------------------------ */
.friends .letter::before {
  content: none;
}

.friends .friend__name {
  font-family: var(--font-display);
  font-size: 19px;
  line-height: 1.3;
  color: var(--sumi);
  margin-bottom: 12px;
}

.friends .friend p {
  font-family: var(--font-body);
  font-size: 15.5px;
  line-height: 1.75;
  color: var(--sumi-soft);
}

.friends .friend .textlink {
  margin-top: 18px;
}

/* Phase 10 kept these at 40px to avoid a logo wall. That was the right instinct and the
   wrong size: at 40px a club's mark was decoration nobody could read. 72px is legible
   while the name still leads the card. See DECISIONS #71.

   The wall is held off by *uniformity*, not by smallness. Third-party logos arrive in
   whatever shape their owner chose — a wide wordmark, a round crest, a tall stack — and
   left alone they make a ragged row of different visual weights. So:

     - a fixed-height band, not a bare max-height, so every card's name starts on the
       same line whether the logo is square, wide or absent-but-present;
     - the logo centred inside it and constrained on both axes, so a wide wordmark and a
       round crest occupy a similar amount of ink rather than a similar height;
     - `object-fit: contain`, so nothing is ever cropped to fit the band.

   The rendition in friend_card.html is max-288x144 — exactly 2x the band — so the marks
   stay crisp on a retina screen. Raising the CSS without raising the rendition would
   have upscaled an 80px-tall image to 72 CSS pixels and made every logo soft. */
.friends .friend__logo {
  height: 72px;
  display: flex;
  align-items: center;
  justify-content: flex-start;
  margin-bottom: 18px;
}

.friends .friend__logo-img {
  max-height: 72px;
  max-width: min(100%, 200px);
  width: auto;
  border-radius: 0;
  box-shadow: none;
  background: none;
  object-fit: contain;
}

/* The association section is prose, not cards — hold it to the same measure as
   the rest of the site's body copy. */
.friends .friends__prose {
  margin-top: 18px;
  max-width: var(--measure);
}

.friends .friends__prose > * + * {
  margin-top: 1.1em;
}

.friends .friends__grid {
  margin-top: clamp(28px, 4vw, 44px);
}

/* One friend should not be stretched across three columns. */
.friends .friends__grid--single {
  grid-template-columns: minmax(0, 420px);
}

/* ------------------------------------------------------------------
   Stacked FAQ groups

   `section{ padding-block: var(--section-y) }` gives every section top *and* bottom
   padding, so two stacked FAQBlocks put 2 × --section-y between them — a measured
   300px at 1920px, 168px at 390px. Nothing else contributes: the `*{margin:0}` reset
   zeroes the heading, and .wrap sets padding-inline only.

   That is correct between different sections and wrong between four of the same
   component. On /faq/ it read as the end of the page, so a reader who did not know
   more questions existed would not scroll.

   Collapsed to roughly 3× the 28px within-group rhythm: enough that the groups stay
   distinct, little enough that the page reads as continuing.

   Inert anywhere a single FAQBlock appears — the homepage, /contact/ and /dojo/ —
   because the selector requires two *adjacent* FAQ sections and no such pair exists
   there. See docs/DECISIONS.md #88.

   `:has()` may be chained but not nested: `:has(...):has(...)` is valid, while
   `:has(+ section:has(...))` is rejected by the parser outright. Do not "tidy" the
   two chained pseudo-classes below into a nested one.
   ------------------------------------------------------------------ */
section:has(> .wrap > .faq):has(+ section .faq) {
  padding-bottom: clamp(28px, 3.5vw, 48px);
}

section:has(> .wrap > .faq) + section:has(> .wrap > .faq) {
  padding-top: clamp(28px, 3.5vw, 48px);
}

/* ------------------------------------------------------------------
   Form field errors

   The approved build has no error style, because it has no server-side validation
   to display: every form in hizashikan-site/ is inert markup. When rejection arrived
   (the link rule, DECISIONS #92) the template borrowed `.form-note` - the same 13px
   stone as the guidance line above the fields and the Privacy Notice line below the
   button. A rejected submission therefore looked like advice, and the strongest
   signal that anything had failed was that the page did not advance.

   For a spammer that does not matter. For a parent who pasted a link by accident it
   does: they need to see that the form did not go through, and what to change.

   The tint and the left rule are not decoration. WCAG 1.4.1 asks that colour not be
   the only carrier of meaning, so the block has to read as an error to someone who
   does not perceive the red. Colouring the text alone was the obvious fix and the
   wrong one. `role="alert"` on the element covers screen readers.

   Values are borrowed rather than invented: --shu is the brush red already used for
   .btn focus rings and ::selection, and the tint mirrors .form-success, which is the
   other "something happened" box on this same form.

   Measured with core.contrast.contrast_ratio, the function the gate itself uses:
   --shu-deep on --washi is 8.15:1 and on the tint 7.34:1, against a 4.5:1 bar - and
   better than the 4.94:1 of the --stone it replaces. Pinned by
   FormErrorContrastTests, because CONTROL_SELECTORS is (.btn, .textlink) and will
   not pick this class up on its own.
   ------------------------------------------------------------------ */
.form-error {
  font-size: 13px;
  margin-top: 12px;
  color: var(--shu-deep);
  background: rgba(163, 31, 31, .06);
  border-left: 2px solid var(--shu);
  border-radius: 2px;
  padding: 8px 12px;
}