/* =====================================================================
   SITE CHROME
   The fixed top bar, the menu panel and the footer, for EVERY page.
   Extracted from home.css on 2026-09-19 when the inner pages took the new
   chrome, so there is exactly ONE definition of the nav and the footer on
   the site rather than one per stylesheet. The homepage loads this file too.

   ⚠️ LOAD ORDER MATTERS on the 21 pages that also load site.css. This file
   must come SECOND. site.css still carries the old `.foot` and `.foot__grid`
   rules, and the new footer reuses both class names, so several selectors
   collide at exactly equal specificity ((0,1,1) against (0,1,1)) and the
   later file is the only thing deciding. The old `.nav*` rules in site.css
   are now dead, because no page has a `.nav` element any more; they are left
   in place rather than cut out of a 133-version stylesheet in the same pass
   that changed every page.

   ⚠️ Nothing here may define a bare `.btn`, `:focus-visible` or `.skip-link`.
   site.css owns those on the inner pages and home.css owns them on the
   homepage; a global rule here would repaint every button on 21 pages. The
   menu's buttons are scoped to `.menu` and `.topbar` at the end of this file.
   ===================================================================== */

/* ⚠️ Two radius tokens the inner pages do not otherwise have. site.css
   carries `--radius` and `--radius-stadium`; the chrome is built on the
   study's scale, where the largest COMPONENT corner is 10px and a SECTION
   corner is 40px. Declared here so a page on site.css can paint this chrome
   without them resolving to nothing. home.css re-declares the same values
   and loads later, so the homepage is unaffected. */
:root {
  --radius-sm: 6px;
  --radius-section: 40px;
}

/* ⚠️ THE CHROME IS FULL WIDTH ON EVERY PAGE, and this rule is what keeps it
   that way. `.wrap` means two different things in the two stylesheets: 1140px
   centred in site.css, full width at a gutter in home.css. Without this the
   bar's logo would sit at x=184 on an inner page and x=40 on the homepage,
   which is the 110px jump between pages that Owen caught once before by
   laying guides on a screenshot. The chrome opts out of the page's measure;
   the page's own content keeps whichever measure its stylesheet gives it. */
.topbar .wrap, .menu .wrap, .foot .wrap {
  width: 100%; max-width: none; margin: 0;
  padding-inline: var(--gutter);
}

/* The structural label, used by the footer and the menu panel. Not defined
   in site.css, so this one is safe to declare globally. */
.label {
  margin: 0 0 14px;
  font-size: 0.875rem;
  font-weight: 500;
  letter-spacing: 0.2em;
  text-transform: uppercase;
  color: var(--text-muted);
}
.label--onaccent { color: rgba(255,255,255,0.82); }

/* =====================================================================
   9. FOOTER, with the oversized wordmark the reference closes on
   ===================================================================== */
/* No background of its own. It IS the body's accent ground.
   ⚠️ Everything here is solid white, and that is a measured constraint rather
   than a style choice: on #2764EC, white at 0.95 alpha measures 4.75:1 and at
   0.90 it is already 4.45:1, under the floor for small text. There is no
   usable "muted white" on this ground, so the hierarchy comes from size and
   spacing. The reference does the same, solid black throughout on its yellow. */
.foot { background: transparent; color: #fff; padding: clamp(56px, 7vw, 96px) 0 28px; }
/* The reference puts its address block hard left and its link columns hard
   right, with the whole width between them. Both groups were sitting on the
   left here with an empty two-thirds beside them, which is what made the
   footer read as unresolved rather than composed. */
.foot__grid {
  display: flex; flex-wrap: wrap;
  justify-content: space-between; align-items: flex-start;
  gap: 28px 64px;
  /* ⚠️ Doubled 2026-09-19 (Owen: "more space between the Quietwork wordmark in
     the footer and the options above it, can potentially double that space").
     This padding is the ONLY thing separating the link columns from a wordmark
     that is 1420px wide and reads as a piece of artwork rather than as type:
     at the old 88px the links looked like a caption sitting on top of it.
     40 to 80 on a phone and 88 to 173 at 1440, so it doubles at both ends
     rather than only where it was measured. */
  padding-bottom: clamp(80px, 12vw, 180px);
}
.foot__grid > * { min-width: 0; }
.foot__links { display: flex; gap: clamp(40px, 6vw, 96px); }
.foot__links ul { margin: 0; padding: 0; list-style: none; }
.foot__links li + li { margin-top: 10px; }
.foot__links a { text-decoration: none; }
.foot__links a:hover { text-decoration: underline; }
@media (max-width: 760px) { .foot__links { gap: 40px; } }
.foot a { color: #fff; }
/* The footer's labels sit on the accent, where --text-muted is nowhere near
   legible. Solid white, like everything else down here. */
.foot .label { color: #fff; }
/* ⚠️ The real logo, not typeset letters. Owen: "the QUIETWORK wordmark right
   at the bottom isn't working. Can we try the logo? Making the logo all white,
   including the SVG dot."

   It needed a new file. `logo/quietwork_logo_white.svg` has nine white paths
   and ONE filled #4a5eda: the dot, still carrying the RETIRED indigo accent.
   On the slate palette that is simply the wrong blue, and on this accent
   ground it reads as a smudge. `assets/quietwork-logo-allwhite.svg` is that
   file with the dot recoloured to #fff.
   ⚠️ Written as a NEW asset rather than edited in place, because `logo/` here
   is a symlink into the live repo and editing through it would have changed
   the live site's logo.

   Sized by width with height auto: the viewBox is 1350.78 x 168.12, an 8.03:1
   ratio, so the intrinsic width/height on the img reserves the right box and
   nothing reflows when it loads. */
.foot__mark {
  display: block;
  width: 100%; height: auto;
  margin: 0; padding-top: 12px;
}

.foot__legal { margin-top: clamp(20px, 3vw, 36px); font-size: 0.8125rem; color: #fff; }   /* solid: see the note above */

/* =====================================================================
   FIXED TOP BAR + PROGRESSIVE BLUR + MENU
   ===================================================================== */
.topbar {
  position: fixed; inset: 0 0 auto 0; z-index: 90;
  pointer-events: none;
}
/* ⚠️ `env(safe-area-inset-top)` and `viewport-fit=cover` go together, and the
   pair is the fix for content appearing ABOVE the bar on iOS. Owen, from a
   phone: "the site appears above the top menu on scroll with no blur."

   Without `viewport-fit=cover` the page's layout viewport starts below the
   status bar, so a bar at `top: 0` never owns the strip behind it and the page
   scrolls through that strip un-blurred. With cover, the viewport runs to the
   physical top of the screen, the bar starts there, and its glass covers
   everything above the logo. The inset is then added back as padding so the
   mark does not sit under the clock.

   ⚠️ On a desktop `env(safe-area-inset-top)` resolves to 0px, so every value
   here is unchanged there. That is the reason it is safe to ship without an
   iOS device to test on: the change cannot move anything that has no inset. */
.topbar__in {
  position: relative; z-index: 2;
  display: flex; align-items: center; justify-content: space-between; gap: 24px;
  padding-block: 22px;
  padding-top: calc(22px + env(safe-area-inset-top, 0px));
  pointer-events: auto;
}
/* 22px of padding either side of a 14px-tall mark makes an 85px bar, which is
   9% of a phone screen permanently spent on chrome. 16px takes it to 72. */
@media (max-width: 620px) {
  .topbar__in { padding-block: 16px; padding-top: calc(16px + env(safe-area-inset-top, 0px)); }
}
/* ⚠️ A PHONE-ONLY SCRIM UNDER THE BLUR, and it is a deliberate belt and
   braces. Eight stacked backdrop-filter layers each carrying a mask is the
   part of this bar most likely to fail on iOS, and when it fails it fails
   silently: text scrolls under the wordmark at full contrast and the bar
   reads as broken. A scrim does not depend on any of that compositing, so
   the bar stays legible whether or not the blur ever paints.
   Tinted from the SAME luminance class the script already sets, so it matches
   the accent hero and the light pages rather than greying both.
   Phone only: the desktop bar is approved as pure glass and is untouched. */
@media (max-width: 760px) {
  .topbar__glass {
    background: linear-gradient(to bottom,
      rgba(39, 100, 236, 0.92) 0%,
      rgba(39, 100, 236, 0.62) 42%,
      rgba(39, 100, 236, 0) 100%);
  }
  .topbar--onlight .topbar__glass {
    background: linear-gradient(to bottom,
      rgba(255, 255, 255, 0.94) 0%,
      rgba(255, 255, 255, 0.66) 42%,
      rgba(255, 255, 255, 0) 100%);
  }
}
.topbar__logo { display: block; line-height: 0; }
.topbar__logo img { width: clamp(112px, 9vw, 140px); height: auto; display: block; }
.topbar__logo .is-dark { display: none; }

/* ⚠️ PROGRESSIVE blur, not one pane: eight layers, blur halving downward
   (24 / 12 / 6 / 3 / 1.5 / 0.75 / 0.375 / 0.1875px). Each is opaque FROM 0%
   and fades out at its own stop, so the blurs COMPOUND at the very top and
   ramp to almost nothing at the bottom edge.

   ⚠️ The direction was wrong first time and it mattered. The layers sampled
   off the reference came from inside its course CARDS, where the blur ramps
   DOWNWARD, and those masks were copied as-is. On a top bar the ramp has to
   run the other way, and worse, the weakest layer's mask began
   `transparent 0%`, so the very top of the page carried NO blur at all.
   Content went sharp, then blurred, then sharp again on the way up. Owen:
   "it doesn't go all the way to the top of the page, so things suddenly come
   back into focus." A single flat backdrop-filter would leave a hard line
   instead; the band stack is what makes it read as glass. */
.topbar__glass {
  position: absolute; inset: 0; z-index: 1;
  /* the inset is added so the blurred band still reaches past the bar's own
     row on a notched phone rather than stopping level with it */
  height: calc(clamp(88px, 11vh, 132px) + env(safe-area-inset-top, 0px));
  pointer-events: none;
}
.topbar__glass i {
  position: absolute; inset: 0; display: block;
  /* ⚠️ A background, however faint, is not decoration here. On iOS an element
     carrying only `-webkit-backdrop-filter` and a mask, with no background at
     all, frequently composites nothing: the filter is declared, reports as
     applied, and paints no blur. One thousandth of an alpha is invisible on
     every engine and is enough to give iOS a layer to work with. */
  background: rgba(255, 255, 255, 0.001);
}
.topbar__glass i:nth-child(1) { backdrop-filter: blur(24px); -webkit-backdrop-filter: blur(24px);
  -webkit-mask-image: linear-gradient(#000 0%, #000 12.5%, transparent 25%);
          mask-image: linear-gradient(#000 0%, #000 12.5%, transparent 25%); }
.topbar__glass i:nth-child(2) { backdrop-filter: blur(12px); -webkit-backdrop-filter: blur(12px);
  -webkit-mask-image: linear-gradient(#000 0%, #000 25%, transparent 37.5%);
          mask-image: linear-gradient(#000 0%, #000 25%, transparent 37.5%); }
.topbar__glass i:nth-child(3) { backdrop-filter: blur(6px); -webkit-backdrop-filter: blur(6px);
  -webkit-mask-image: linear-gradient(#000 0%, #000 37.5%, transparent 50%);
          mask-image: linear-gradient(#000 0%, #000 37.5%, transparent 50%); }
.topbar__glass i:nth-child(4) { backdrop-filter: blur(3px); -webkit-backdrop-filter: blur(3px);
  -webkit-mask-image: linear-gradient(#000 0%, #000 50%, transparent 62.5%);
          mask-image: linear-gradient(#000 0%, #000 50%, transparent 62.5%); }
.topbar__glass i:nth-child(5) { backdrop-filter: blur(1.5px); -webkit-backdrop-filter: blur(1.5px);
  -webkit-mask-image: linear-gradient(#000 0%, #000 62.5%, transparent 75%);
          mask-image: linear-gradient(#000 0%, #000 62.5%, transparent 75%); }
.topbar__glass i:nth-child(6) { backdrop-filter: blur(0.75px); -webkit-backdrop-filter: blur(0.75px);
  -webkit-mask-image: linear-gradient(#000 0%, #000 75%, transparent 87.5%);
          mask-image: linear-gradient(#000 0%, #000 75%, transparent 87.5%); }
.topbar__glass i:nth-child(7) { backdrop-filter: blur(0.375px); -webkit-backdrop-filter: blur(0.375px);
  -webkit-mask-image: linear-gradient(#000 0%, #000 87.5%, transparent 100%);
          mask-image: linear-gradient(#000 0%, #000 87.5%, transparent 100%); }
.topbar__glass i:nth-child(8) { backdrop-filter: blur(0.1875px); -webkit-backdrop-filter: blur(0.1875px);
  -webkit-mask-image: linear-gradient(#000 0%, #000 100%);
          mask-image: linear-gradient(#000 0%, #000 100%); }

/* ⚠️ The white mark is invisible over the light sections, and the reference
   does not have this problem because its page is light and its logo is dark.
   A scroll handler reads what is actually behind the bar and swaps the mark
   and the button to ink. Tinting the glass instead would have killed the
   effect Owen asked for. */
.topbar--onlight .topbar__logo .is-light { display: none; }
.topbar--onlight .topbar__logo .is-dark  { display: block; }
.topbar--onlight .menu-btn { color: var(--text); border-color: var(--text); }
.topbar--onlight .menu-btn__i::before,
.topbar--onlight .menu-btn__i::after { background: var(--text); }

.menu-btn {
  display: inline-flex; align-items: center; gap: 14px;
  padding: 11px 16px;
  border: 1px solid #fff; border-radius: var(--radius-sm);
  background: transparent; color: #fff;
  font: inherit; font-size: 0.6875rem; font-weight: 600;
  letter-spacing: 0.14em; text-transform: uppercase;
  cursor: pointer;
  transition: background .15s ease, color .15s ease, border-color .15s ease;
}
.menu-btn:hover { background: #fff; color: var(--accent); }
.topbar--onlight .menu-btn:hover { background: var(--text); color: var(--bg); }
.menu-btn__i { position: relative; width: 13px; height: 13px; flex: none; }
.menu-btn__i::before, .menu-btn__i::after {
  content: ""; position: absolute; left: 0; top: 6px;
  width: 13px; height: 1.5px; background: #fff;
  transition: transform .28s cubic-bezier(.4,0,.2,1);
}
.menu-btn__i::after { transform: rotate(90deg); }
.menu-btn:hover .menu-btn__i::before, .menu-btn:hover .menu-btn__i::after { background: currentColor; }
[aria-expanded="true"] .menu-btn__i::before { transform: rotate(135deg); }
[aria-expanded="true"] .menu-btn__i::after  { transform: rotate(45deg); }

/* The panel. Closed by default with no height, so it cannot trap focus or
   cover the page if the script never runs. */
.menu {
  position: fixed; inset: 0 0 auto 0; z-index: 80;
  background: var(--bg-ink); color: #fff;
  padding: clamp(112px, 13vh, 160px) 0 clamp(48px, 7vh, 88px);
  padding-top: calc(clamp(112px, 13vh, 160px) + env(safe-area-inset-top, 0px));
  border-radius: 0 0 var(--radius-section) var(--radius-section);
  transform: translateY(-100%);
  opacity: 0;
  visibility: hidden;
  transition: transform .42s cubic-bezier(.22,1,.36,1), opacity .28s ease, visibility 0s .42s;
}
.menu.is-open { transform: none; opacity: 1; visibility: visible; transition-delay: 0s; }
.menu__in { display: grid; grid-template-columns: 65fr 35fr; gap: 48px; align-items: start; }
@media (max-width: 820px) { .menu__in { grid-template-columns: 1fr; gap: 28px; } }
.menu__list { margin: 0; padding: 0; list-style: none; }
.menu__list li + li { margin-top: 6px; }
.menu__list a {
  display: block; text-decoration: none;
  font-size: clamp(1.75rem, 4.2vw, 3.25rem);
  font-weight: 400; letter-spacing: -0.035em; line-height: 1.12;
  opacity: 0; transform: translateY(14px);
  transition: opacity .3s ease, transform .3s cubic-bezier(.22,1,.36,1);
}
.menu.is-open .menu__list a { opacity: 1; transform: none; }
/* Staggered, so the list arrives rather than appearing all at once. */
.menu.is-open .menu__list li:nth-child(1) a { transition-delay: .06s; }
.menu.is-open .menu__list li:nth-child(2) a { transition-delay: .10s; }
.menu.is-open .menu__list li:nth-child(3) a { transition-delay: .14s; }
.menu.is-open .menu__list li:nth-child(4) a { transition-delay: .18s; }
.menu.is-open .menu__list li:nth-child(5) a { transition-delay: .22s; }
.menu.is-open .menu__list li:nth-child(6) a { transition-delay: .26s; }
.menu__list a:hover { color: var(--link-onink); }
/* ⚠️ The colour is DECLARED, not inherited. On the homepage these links are
   white because home.css sets `a { color: inherit }` and the panel is ink. An
   inner page carries site.css instead, whose `a { color: var(--accent) }` at
   (0,0,1) beats inheritance outright, so the menu painted its links accent on
   ink: measured 3.50:1, a nav that reads as disabled. Nothing in the chrome
   may rely on inheriting a colour, because the chrome sits on two different
   stylesheets. */
.menu__list a { color: var(--text-onink); }
.topbar__logo, .topbar__logo:hover { color: inherit; }
.menu__side .label { color: rgba(255,255,255,0.72); }
/* ⚠️ :not(.btn) is load-bearing. `.menu__side a` is (0,2,0) and beats
   `.btn--light` at (0,1,0), so it repainted the button's label white on a
   white ground: invisible. Ninth recurrence of the specificity trap on this
   project, and the rule is always the same, a container that styles its links
   must opt its buttons out. */
.menu__side a:not(.btn) { color: #fff; }
/* ⚠️ TENTH RECURRENCE of the specificity trap, and the second on this exact
   button. The resting state was fixed with the `:not(.btn)` above; the HOVER
   state was not, and it fails for a different reason.

   `.btn--light:hover` paints `var(--bg-ink)`, which is correct everywhere else
   on the site: on the accent hero and on the accent plan panel, an ink fill is
   the strongest thing the button can do. On the MENU it is the panel's own
   colour, so on hover the button's white fill became the background it was
   sitting on and the control vanished, leaving a floating label. Owen: "when I
   hover over the Book a Call button, it disappears."

   The lesson is not about weight this time: the selector that lost was not
   outranked, it was simply written for a light ground and then used on a dark
   one. **A hover that names a colour has to be checked against every ground
   the component is placed on**, and this component sits on three.

   The accent is the right answer here rather than a dimmer white: it is what
   every other button on the page does on hover, and it separates from the ink
   panel instead of dissolving into it. White on accent is 5.10:1. */
.menu .btn--light:hover { background: var(--accent); color: #fff; }
.menu .btn--light:hover .btn__a { border-left-color: rgba(255,255,255,0.28); }
body.menu-open { overflow: hidden; }

/* ---- The chrome's own buttons ----------------------------------------
   ⚠️ SCOPED, deliberately. The homepage gets these shapes from home.css as a
   global `.btn`, because every button on that page is this component. Here a
   global rule would repaint all 21 inner pages, whose buttons are site.css's
   and have no `.btn__t` or `.btn__a` children to hang the arrow cell on.
   ---------------------------------------------------------------------- */
.topbar .btn, .menu .btn {
  display: inline-flex; align-items: stretch;
  border-radius: var(--radius-sm);
  background: var(--text); color: var(--bg);
  font-size: 0.6875rem; font-weight: 600; letter-spacing: 0.14em;
  text-transform: uppercase; text-decoration: none;
  overflow: hidden; min-height: 0;
  transition: background .15s ease, color .15s ease;
}
.topbar .btn__t, .menu .btn__t { padding: 14px 18px; }
.topbar .btn__a, .menu .btn__a {
  display: grid; place-items: center;
  width: 40px; flex: none;
  border-left: 1px solid rgba(255,255,255,0.28);
}
.topbar .btn__a svg, .menu .btn__a svg { width: 14px; height: 14px; }
.menu .btn--light { background: var(--bg); color: var(--text); }
.menu .btn--light .btn__a { border-left-color: rgba(0,0,0,0.22); }
/* ⚠️ The accent, not `--bg-ink`. On the ink menu panel an ink fill is the
   panel's own colour, so the button disappeared on hover and left a floating
   label. White on accent is 5.10:1 and the fill separates from the panel at
   3.50:1. */
/* (the hover pair above is the single definition; the duplicate that the
   extraction left here has been removed) */

/* Focus rings inside the chrome only: site.css owns the site-wide ring and
   its own is a different offset. */
.topbar :focus-visible, .menu :focus-visible, .foot :focus-visible {
  outline: 2px solid #fff; outline-offset: 2px;
}
.topbar--onlight :focus-visible { outline-color: var(--text); }

/* ---- Page start ------------------------------------------------------ */
/* The bar is fixed now, so a page that used to open under an in-flow nav has
   to start below it. On the homepage the hero does this itself. */
.has-bar { padding-top: clamp(84px, 9vh, 104px); }

/* ---- Type, flowing through ------------------------------------------- */
/* ⚠️ WEIGHT, not family. Both systems already run Archivo; what made the
   homepage and the inner pages read as different typography was 700 against
   400. It is the single biggest texture difference and it was measured on
   the reference this design came from: every heading there is weight 400 and
   the SIZE carries the hierarchy, not the weight.
   Declared here rather than edited into site.css so it is one line to undo,
   and so site.css's own ramp stays the record of the sizes. */
h1, h2, h3, h4 { font-weight: 400; }
h2, h3, h4 { letter-spacing: -0.03em; }

/* ---- Neutralising site.css's old footer --------------------------------
   ⚠️ MEASURED, not guessed. The new footer reuses `.foot` and `.foot__grid`,
   and site.css still styles both, so the inner pages inherited three things
   that do not belong to this footer. Each line below closes one, and each was
   found by comparing the computed styles of an inner footer against the
   homepage's rather than by reading the old stylesheet:

   1. `.foot` had no ground at all. The homepage's footer is transparent ON
      PURPOSE because the body there IS the accent and the footer is the page's
      own ground revealed. An inner page's body is white, so the same rule left
      white text on white. It paints the accent itself here; home.css declares
      `transparent` again later, so the homepage is unchanged.
   2. `.foot__grid` kept a top hairline, 30px of padding and a 36px bottom
      margin from site.css's version of the same class.
   3. `.foot__grid a` (0,1,1) set `display: block` and 15px on links that the
      new footer sizes from the body. `.foot__links a` is the same specificity,
      so only source order was deciding, and it was only half declared.
   ---------------------------------------------------------------------- */
.foot { background: var(--accent); }
.foot .foot__grid { margin-bottom: 0; border-top: 0; padding-top: 0; }
.foot .foot__links a { display: inline; font-size: inherit; padding: 0; }
.foot .foot__links li + li { margin-top: 10px; }

/* ---- The last two leaks, found by diffing the chrome ---------------------
   Every element inside the bar, the menu and the footer was fingerprinted on
   the homepage and compared against the same element on an inner page. After
   the fixes above, two differences were left that were not the deliberate
   light/dark logo swap:

   1. site.css's `.btn` put 14px 24px of padding on the menu's Book a call
      button. In this component the padding belongs to `.btn__t`, so the
      button was bigger in the menu than on the homepage.
   2. site.css's `.foot__grid a` made the footer's email link a 15px block with
      5px of padding and no underline, against 17px inline and underlined on
      the homepage.

   Both are the same fault as the rest of this file: two stylesheets owning one
   class name. The diff is the only reason either was found, and it is worth
   re-running after any change here. */
.menu .btn, .topbar .btn { padding: 0; border: 0; }
.foot .foot__grid a { display: inline; font-size: inherit; padding: 0; text-decoration: underline; }
.foot .foot__links a { text-decoration: none; }
.foot .foot__links a:hover { text-decoration: underline; }


/* ---- Hover states, which the resting-state diff did not cover ------------
   ⚠️ ELEVENTH recurrence of the specificity trap, and a NEW variant of it:
   the winning selector was not heavier because of a class, it was heavier
   because of a PSEUDO-CLASS. site.css has

       .foot__grid a:hover { color: var(--accent); }      (0,2,1)

   and the strongest thing chrome.css had for a footer link was

       .foot a { color: #fff; }                           (0,1,1)

   so on hover the links painted the accent ON the accent footer: **1:1, gone**.
   Owen: "footer links invisible on hover."

   ⚠️ The method failure is worth more than the fix. The computed-style diff
   that found the other three leaks compared RESTING states only, so it could
   never have caught this. A hover, a focus and an open state are each a
   different set of matched rules, and a chrome that sits on two stylesheets
   has to be diffed in all of them.
   ---------------------------------------------------------------------- */
.foot .foot__grid a:hover,
.foot .foot__links a:hover { color: #fff; text-decoration: underline; }

/* ---- The ink block's join with the footer --------------------------------
   Owen: "you've not followed the same style for the dark blue bit before the
   footer." He is right, and the homepage version is not a decoration: the FAQ
   block is rounded at the BOTTOM so the accent shows through its corners, and
   the footer is the page's own ground revealed rather than a block of colour.

   The 10 inner pages that end on a `.section--ink` were running that block
   square, edge to edge, so it butted into the accent footer with a hard line.

   ⚠️ The rounding alone would NOT have worked here, and this is the part worth
   recording. On the homepage the body IS the accent, so the corners reveal it
   for free. An inner page's body is white, so rounding the corners there would
   have cut two WHITE notches between the ink block and the accent footer:
   worse than the square join it replaced. The footer is therefore pulled up by
   exactly the radius, so its accent sits behind the corners, and the ink block
   is given a stacking position so it paints over the part that now overlaps.
   The footer gets that 40px back as padding, so its content does not move.

   `:last-child` is doing real work: `y-bark.html` also has an ink section but
   it is NOT last, and rounding a mid-page block would be meaningless.
   ---------------------------------------------------------------------- */
main > .section--ink:last-child {
  border-radius: 0 0 var(--radius-section) var(--radius-section);
  margin-bottom: calc(-1 * var(--radius-section));
  position: relative;
  z-index: 1;
}
main:has(> .section--ink:last-child) ~ .foot {
  padding-top: calc(clamp(56px, 7vw, 96px) + var(--radius-section));
}