/* The Services mega menu. Phil, 2026-09-03: "You gonna have a mega menu dropdown under
   'Services' so that you can select em? On mobile.. a click will drop it down... so maybe
   rollover on desktop."

   Shared file on purpose. Every page carries its own inlined <style>, which is how the base
   stylesheet forked into divergent copies; adding 22 more copies of this would make that worse.

   Desktop: hover or keyboard focus opens. Clicking the word still goes to services.html.
   Mobile:  tapping the word opens the panel instead of navigating (the panel's first row is
            the overview page, so nothing becomes unreachable). */
nav .navdrop{position:relative;display:inline-flex;align-items:center}
nav .navdrop > a{display:inline-flex;align-items:center;gap:6px}
nav .navdrop > a::after{content:"";width:0;height:0;border-left:4px solid transparent;
  border-right:4px solid transparent;border-top:5px solid currentColor;opacity:.55;
  transform:translateY(1px);transition:transform .18s ease,opacity .18s ease}
nav .navdrop[data-open="1"] > a::after{transform:rotate(180deg) translateY(1px);opacity:1}

/* The panel hangs off the NAV, not off the word — so it meets the bottom of the bar flush
   instead of floating below it. Phil, 2026-09-03: "can it align to the bottom of the menu bar?
   not floating over?" That needs nav to be the containing block, hence position:static on the
   drop and relative on the nav; the horizontal offset is then set from the trigger in JS.
   PURPLE: THE MAIN ONE, #8151ee, the Contact us button's. Phil, 2026-09-24: "I want it to be the
   same purple... the main we use." (It was #4a2ea8 for contrast.) White on #8151ee is 4.83:1,
   which passes AA only at FULL white, so every word in the panel is #fff now, not a translucent
   white, and the hover darkens the row instead of lightening it (white on it: 6.57:1; the old
   lighten-hover would have dropped to 3.73:1). The phone burger panel keeps #4a2ea8: the Contact
   us button sits INSIDE it in #8151ee and would vanish on its own colour. */
nav{position:relative}
nav .navdrop{position:static}
nav .navdropmenu{position:absolute;top:100%;left:0;z-index:80;
  min-width:330px;padding:8px;border-radius:0 0 12px 12px;
  background:#8151ee;border:1px solid rgba(255,255,255,.13);border-top:none;
  box-shadow:0 22px 48px -14px rgba(0,0,0,.55);
  opacity:0;visibility:hidden;transform:translateY(-6px);
  transition:opacity .16s ease,transform .16s ease,visibility .16s}
nav .navdrop[data-open="1"] .navdropmenu{opacity:1;visibility:visible;transform:none}

nav .links .navdropmenu a{display:block;padding:9px 12px;border-radius:8px;
  font-size:var(--t-s);line-height:1.25;text-decoration:none;color:#fff}
nav .links .navdropmenu a small{display:block;margin-top:3px;font-family:var(--f-body,inherit);
  font-weight:400;font-size:12px;color:#fff;letter-spacing:0}
nav .links .navdropmenu a:hover,nav .links .navdropmenu a:focus-visible{
  background:rgba(13,10,22,.2);color:#fff}
nav .links .navdropmenu a:hover small{color:#fff}
/* No rule under "All services". Phil, 2026-09-03: "The white text looks clearly linkable- and
   the rollovers work." The divider was doing a job the hover already does. */
nav .navdropmenu .navdropall{border-radius:8px}
nav .navdropmenu .num{display:inline-block;min-width:22px;color:#fff;
  font-family:var(--f-mono,monospace);font-size:11px;letter-spacing:.08em}


/* Services was hidden on a phone; it is the way in to five pages, so it is shown now. */
@media(max-width:720px){
  nav .navdrop.m-hide{display:inline-flex}
  /* On a phone the panel spans the page rather than hanging off the trigger, because the
     trigger sits in the middle of the nav row and a panel anchored to it ran 162px past the
     right edge. Its exact top and sides are set from the nav's measured box in navmenu.js —
     positioning it in CSS alone meant either overflowing the viewport or landing on top of the
     word it drops from, and both happened before this. */
  nav .navdropmenu{min-width:0;left:0;right:0;max-height:min(58vh,460px);overflow:auto;
    -webkit-overflow-scrolling:touch;border-radius:0 0 12px 12px}
}
@media (prefers-reduced-motion: reduce){
  nav .navdropmenu{transition:none}
  nav .navdrop > a::after{transition:none}
}

/* ---------------------------------------------------------------------------
   THE BURGER, AND WHY THE ROW STOPPED WRAPPING.

   Phil, 2026-09-04, with a screenshot of the nav on two lines: "I think when it
   gets smaller and the menu don't hold up, you drop it to a hamburger menu icon
   that drops down the menu, right? So the top looks right?" That reverses his
   own earlier "no hamburger" call, which is his to reverse, and it is the right
   answer: a wrapped nav is the header admitting it did not fit.

   WHERE IT ENGAGES IS MEASURED, NOT PICKED. The single row needs
   mark 286 + gap 16 + links 551 = 853px, inside a shell of min(1024,vw) - 56.
   That fits only from vw 909 up, which is why his screenshot at ~850 was on two
   lines and why the nav was 82px tall at 1000 and 140px at 900. So: 900 and
   below is burger, above it is the row, and the row never wraps again.

   This replaces an earlier fix of mine that let the row wrap below 460. Wrapping
   cured the overflow and produced exactly the two-line header he then objected
   to; the burger cures both, and keeps the wordmark he would otherwise have had
   to trade away.

   The panel is the mega menu's own treatment — same #4a2ea8, same rows — because
   it is the same thing, opened from a different handle. The five services come
   with it rather than hiding behind a second tap. --------------------------- */
.navburger{display:none;background:none;border:0;cursor:pointer;color:var(--ink);
  padding:10px;line-height:0;border-radius:8px}
.navburger:hover{color:var(--signal)}
.navburger svg{display:block;width:22px;height:22px}
.navburger .bar{transform-origin:center;transition:transform .2s ease,opacity .16s ease}
nav[data-navopen="1"] .navburger .b1{transform:translateY(5px) rotate(45deg)}
nav[data-navopen="1"] .navburger .b2{opacity:0}
nav[data-navopen="1"] .navburger .b3{transform:translateY(-5px) rotate(-45deg)}

/* the handle group: burger + theme toggle, moved out of .links by the script so
   the bar keeps a control when the menu itself is behind the burger */
.navhandles{display:none;align-items:center;gap:2px;margin-left:auto}

/* ── THE BAR STAYS ON ONE LINE (Phil, 2026-09-15) ───────────────────────────
   "you can't have the menu fall onto the second line like this. less space
   between the buttons.. smaller things... make it fit to the right."

   Two text links became padded buttons, the links block went 481 -> 716px, and
   at a 968px wrap it no longer fit beside the 245px mark, so it dropped to its
   own row and the bar grew 82 -> 139px.

   These numbers are measured across the WHOLE desktop range, not one width.
   The wrap is fixed at 968 down to 1024, then goes fluid: 904 at 960, 845 at
   901. A gentler setting (gap 18, 8px 14px, 13px) looks fine at 1440 with 97px
   spare and WRAPS AT 901 at -26. This one holds every width:

     1440..1024  spare 146   |   960  spare 82   |   901  spare 23
   NOTE ON THE MEASUREMENT: spare = navW - markW - linksW OMITS the nav's own
   flex gap (16px). The bar wraps when spare < 16, not when spare < 0 - which is
   why a "+13px spare" still dropped to two rows at 901. Fit condition is
   spare >= 16.
     nav height a constant 82px, which is what it was before the doors.

   Sits with the base rules ABOVE the narrow-viewport block on purpose: the
   burger panel re-sets gap and padding and must keep winning by source order.
   And because each page's inline <style> loads BEFORE this file, this overrides
   the per-page .navbtn padding without touching 25 pages. */
nav .links{gap:14px}
nav .links a.navbtn{padding:7px 11px;font-size:12.5px}

/* ── OUTLINED NAV DOORS (Phil's ruling, 2026-09-15) ──────────────────────────
   Two offer-doors outlined, catalog and company plain text, one filled primary.
   Four weights in the bar.

   COLOUR. Free Assessment takes the filled button's own purple (#8151ee) so the
   bar carries ONE purple rather than two — the .navbtn background is hardcoded
   #8151ee, not the #8a5cf6 token. Hire an AI Employee takes currentColor, which
   resolves near-white on dark and near-ink on light.

   WHY NOT LITERAL WHITE. Phil ruled "white outline". Measured against the
   painted nav ground (nav::before composites to the page base in both themes):
     white #f2effc ....... 17.28:1 dark  ·   1.13:1 LIGHT
     currentColor ........ 17.28:1 dark  ·  19.12:1 light
     purple #8151ee ......  4.05:1 dark  ·   4.83:1 light
   A literal white outline on the light theme is not a quiet button, it is an
   absent one, and it fails WCAG 1.4.11 (3:1 for a non-text UI component).
   currentColor keeps what he ruled — the loud one, distinct from the purple
   one — without vanishing when someone hits the theme toggle.

   Padding matches .navbtn exactly so all three doors share one silhouette. */
nav .links a.navout{
  display:inline-block;
  padding:7px 11px;          /* tightened 2026-09-15 so the bar holds one line */
  font-size:12.5px;          /* measured: see THE BAR STAYS ON ONE LINE above  */
  border-radius:8px;
  border:1px solid currentColor;
  text-decoration:none;
}
nav .links a.navout-purple{ color:#8151ee }
nav .links a.navout-purple:hover{ background:#8151ee; color:#fff }
nav .links a.navout-ink{ color:var(--ink) }
nav .links a.navout-ink:hover{ background:var(--ink); color:var(--paper) }

/* ── SERVICES / WORK / ABOUT LIVE IN THE BURGER (Phil, 2026-09-15) ──────────
   They leave the bar at every width; the bar keeps the three doors and the
   burger. .navcat is ONE positioned panel, so nothing depends on guessed
   offsets. Below 900 it goes display:contents and the existing mobile block
   owns the phone exactly as before. */
/* burger AND theme toggle live in .navhandles - both were hidden at desktop */
nav .navhandles,nav .navburger{display:inline-flex}
/* Phil 2026-09-17: doors sit right, beside the burger, not beside the logo */
nav .links{margin-left:auto;margin-right:8px}
/* .navhandles also carries margin-left:auto; two autos split the space and
   centre the doors. Desktop only - the phone still needs it on the handles. */
@media(min-width:1080px){nav .navhandles{margin-left:0}}

/* Phil 2026-09-15: the two left doors match in white/ink; Contact us becomes a
   purple OUTLINE rather than filled. Measured earlier tonight against the nav
   ground - ink 17.28:1 dark / 19.12:1 light, purple #8151ee 4.05 / 4.83. All
   clear of WCAG 1.4.11's 3:1 for a non-text component, both themes. */
nav .links a.navout-purple{color:var(--ink)}
nav .links a.navout-purple:hover{background:var(--ink);color:var(--paper)}
nav .links a.navbtn{background:none;border:1px solid #8151ee;color:#8151ee}
nav .links a.navbtn:hover{background:#8151ee;color:#fff;opacity:1}
nav .navcat{display:none}
nav[data-navopen="1"] .navcat{
  display:block;position:absolute;top:100%;right:0;z-index:80;
  width:100%;max-width:300px;padding:8px;border-radius:0 0 12px 12px;
  background:#4a2ea8;border:1px solid rgba(255,255,255,.13);border-top:none;
  box-shadow:0 22px 48px -14px rgba(0,0,0,.55)}
nav[data-navopen="1"] .navcat > a,
nav[data-navopen="1"] .navcat .navdrop > a{
  display:block;padding:11px 12px;border-radius:8px;
  font-size:15px;color:#fff;text-decoration:none}
nav[data-navopen="1"] .navcat > a:hover,
nav[data-navopen="1"] .navcat .navdrop > a:hover{background:rgba(255,255,255,.15)}
nav[data-navopen="1"] .navcat .navdrop{display:block;position:static}
nav[data-navopen="1"] .navcat .navdrop > a::after{display:none}
nav[data-navopen="1"] .navcat .navdropmenu{
  position:static;opacity:1;visibility:visible;transform:none;min-width:0;
  padding:0 0 4px 10px;background:none;border:0;box-shadow:none;
  border-left:1px solid rgba(255,255,255,.18);margin:0 0 4px 12px}
nav[data-navopen="1"] .navcat .navdropmenu a{padding:8px 10px;color:#fff}

@media(max-width:1079px){
  /* one row, always. NEVER wrap — a wrapped header is the bug he photographed. */
  nav{flex-wrap:nowrap}
  .navburger,.navhandles{display:inline-flex}

  /* .links stops being a row and becomes the panel */
  /* THE PANEL HANGS UNDER THE HANDLE, IT DOES NOT SPAN THE BAR. At 820 a
     full-width panel is two thirds empty purple, because the rows are as long as
     their words and no longer. Capped and pushed right, it sits under the burger
     that opened it, which is also where the thumb already is. On a phone the cap
     is wider than the viewport, so nothing changes there. */
  nav .links{position:absolute;top:100%;right:0;left:auto;
    width:100%;max-width:430px;z-index:80;
    display:none;flex-direction:column;align-items:stretch;gap:0;
    padding:8px;border-radius:0 0 12px 12px;
    background:#4a2ea8;border:1px solid rgba(255,255,255,.13);border-top:none;
    box-shadow:0 22px 48px -14px rgba(0,0,0,.55);
    max-height:calc(100vh - 100%);max-height:calc(100dvh - 100%);overflow:auto;overscroll-behavior:contain}
  /* 2026-09-23: 100dvh, not only 100vh. On iPhone Safari 100vh is the height with the toolbars
     HIDDEN, so with the bottom bar showing, the last item (Contact us) sat under it until the
     menu was scrolled. dvh is the height actually visible; 100vh stays as the fallback. */
  nav[data-navopen="1"] .links{display:flex}

  /* everything the narrow row used to hide is visible in here — there is room */
  nav .links a.m-hide,nav .links .navdrop.m-hide{display:block}
  nav .navcat{display:contents}
  /* 2026-09-23: the desktop OPEN-panel rule (nav[data-navopen="1"] .navcat,
     absolute, 0,2,1) outranked the line above (0,1,1), so on a phone the links
     became a second floating box clipped inside the burger panel: only the
     three buttons showed. Same specificity, later in the file, so it wins. */
  nav[data-navopen="1"] .navcat{display:contents}
  /* equal side gaps (Phil 01:57): the panel bled 8px left but kept the bar's
     8px right margin, so it sat 12px from one edge and 28px from the other */
  #navpanel{gap:6px;margin-right:0;left:-8px;right:-8px;width:auto}
  nav .links > a,nav .links .navcat > a,nav .links .navdrop > a{display:block;padding:11px 12px;border-radius:8px;
    font-size:15px;color:#fff;text-decoration:none}
  nav .links > a:hover,nav .links .navdrop > a:hover{background:rgba(255,255,255,.15)}
  nav .links .navdrop{display:block;position:static}
  nav .links .navdrop > a::after{display:none}   /* no caret: nothing to expand */

  /* the five services come WITH the panel rather than behind a second tap */
  nav .links .navdropmenu{position:static;opacity:1;visibility:visible;transform:none;
    min-width:0;padding:0 0 4px 10px;background:none;border:0;box-shadow:none;
    border-left:1px solid rgba(255,255,255,.18);margin:0 0 4px 12px}
  nav .links .navdropmenu a{padding:8px 10px}

  /* the button keeps being a button, not a menu row */
  nav .links a.navbtn{display:block;margin:6px 2px 2px;text-align:center;color:#fff}

  /* ── THE OUTLINED DOORS INSIDE THE PANEL (Iris, 2026-09-15) ───────────────
     The panel paints #4a2ea8. My desktop rules (nav .links a.navout, 0,2,2)
     outrank the panel's own nav .links > a (0,1,2), so they were dragging the
     page-context colours in here: purple-on-purple measured 1.93:1 and ink
     2.05:1, both failing WCAG 1.4.11's 3:1 for a non-text component. Caught in
     a screenshot, not in the numbers — every contrast figure I took was against
     nav::before, and the panel is a different background entirely.
     In here the doors follow the panel's existing law like everything else:
     white ink, white-ish rule, the same hover wash as the other rows. */
  nav .links a.navout{color:#fff;border-color:rgba(255,255,255,.62)}
  nav .links a.navout:hover{background:rgba(255,255,255,.15);color:#fff}
}

/* ============================================================================
   THE HEADER BUTTONS ARE SOLID, ALWAYS. Phil, 2026-09-22:
   "I want the buttons solid on the header... always. white/white/purple.
    handled like the other buttons. No underline on selected. Not for the
    buttons."

   THE THREE, left to right, and their classes have DRIFTED from what they
   paint, which is the actual reason they were taking page context:
     Free Assessment      .navout.navout-purple   (painted ink, not purple)
     Hire an AI Employee  .navout.navout-ink
     Contact us           .navbtn
   `navout-purple` was declared purple at one point in this file and overridden
   to ink further down. Two rules, different colours, the second winning. This
   block supersedes BOTH rather than stacking a third on top - do not reopen
   those earlier pairs, they are dead.

   WHITE IS LITERAL, and it is his word. It is also the one thing here I could
   not verify against a ruling, so it is checked in both themes rather than
   assumed: see the light-theme rule below.

   NO UNDERLINE ON THESE THREE. This NARROWS his 2026-08-11 ruling rather than
   reversing it: the active-page purple underline is state, not decoration, and
   it STAYS on the plain nav links. On a filled button it reads as damage. The
   underline itself is declared in each page's INLINE css (0,2,2), not here, so
   this exclusion is written at (0,3,2) to outrank it from a shared file rather
   than editing the same rule on twenty-six pages.
   ============================================================================ */

nav .links a.navout,
nav .links a.navout-purple,
nav .links a.navout-ink{
  background:#fff;
  color:#14121c;                 /* ink, stated flat so the bar's glass cannot tint it */
  border:1px solid #fff;
}
nav .links a.navout:hover,
nav .links a.navout-purple:hover,
nav .links a.navout-ink:hover{
  background:#e7e2f5;
  color:#14121c;
  border-color:#e7e2f5;
}

nav a.navbtn{
  background:#8151ee;
  color:#fff;
  border:1px solid #8151ee;
}
nav a.navbtn:hover{
  background:#6d3fd8;
  color:#fff;
  border-color:#6d3fd8;
}

/* the page-you-are-on underline in the menu's own purple. Phil, 2026-09-24: "the underline
   purple of the menu needs to be the same background purple." The pages set it inline at
   (0,2,2) from --accent (#8a5cf6); this is (0,2,3) so it wins without touching 27 pages. */
html nav .links a[aria-current="page"]{text-decoration-color:#8151ee}

/* the exclusion, at (0,3,2) so it beats the pages' own inline (0,2,2) */
nav .links a.navout[aria-current="page"],
nav a.navbtn[aria-current="page"]{
  text-decoration:none;
}

/* LIGHT THEME: a white button on a pale bar disappears. His "white" is what he
   sees on the dark theme; here the same button has to keep the same WEIGHT, so
   it takes the ink fill and pale text. Same solidity, same hierarchy, legible. */
html[data-theme="light"] nav .links a.navout,
html[data-theme="light"] nav .links a.navout-purple,
html[data-theme="light"] nav .links a.navout-ink,
html[data-theme="light"] #navpanel a.navout{
  /* THE !important IS GONE, 2026-09-22 evening. It was never the pages' inline
     css. navmenu.js gives .links id="navpanel" AT EVERY WIDTH (line ~88), so
     the "#navpanel a.navout-*" rules below, meant for the open burger, apply on
     desktop too, and an ID (1,1,1) outranks any class chain (0,4,2). The
     #navpanel selector in this list (1,2,2) is what actually wins; the force
     was covering for the hover rules, which had no #navpanel variant and so
     lost to the panel's plain rest colours. Verified on 27 pages x 2 widths
     (156 buttons) that dropping the force changes no resting colour. */
  background:#14121c;
  color:#fff;
  border-color:#14121c;
}
html[data-theme="light"] nav .links a.navout:hover,
html[data-theme="light"] #navpanel a.navout:hover{
  background:#2b2740;
  border-color:#2b2740;
}

/* THE OPEN BURGER PANEL paints #4a2ea8 and has its own specificity fight with
   the desktop rules (see the note further up this file). The buttons stay solid
   in there too, or the panel is the one place his "always" is not true. */
#navpanel a.navout,
#navpanel a.navout-purple,
#navpanel a.navout-ink{
  background:#fff;color:#14121c;border-color:#fff;
}
#navpanel a.navbtn{
  background:#8151ee;color:#fff;border-color:#8151ee;
}
/* the hovers need the ID too, or the rest colours above hold through hover:
   .links carries id="navpanel" at every width, not only in the burger */
#navpanel a.navout:hover{
  background:#e7e2f5;color:#14121c;border-color:#e7e2f5;
}
#navpanel a.navbtn:hover{
  background:#6d3fd8;color:#fff;border-color:#6d3fd8;
}

/* ── THE MENU ROW AND SQUARE HANGING TABS, desktop only (Phil, 2026-09-23) ──
   Evolved from the 00:50 band build through six previews; he picked the last:
   "That could work.... apply that to the website."
   Row: logo left; Services ▾ · Work · About and the theme toggle right.
   The three buttons hang off the header's bottom hairline as SQUARE tabs (the
   rounded ones were killed: "the tabs don't fit the style of the site... with
   the blocks"). White/black fills per the 2026-09-22 button ruling (white on
   dark, ink on light), Contact us purple.
   OPTICAL CENTRE: links + toggle sit 3px below the logo box's centre. The
   tagline under the wordmark weights the lockup low; centred on the box they
   read top-heavy (Phil, 01:33).
   Nav padding 12px: pages pin `padding:var(--s-2) 0 !important`, so this needs
   !important at higher specificity. From 1080 up only: below that the three
   links plus three tabs don't fit (measured: 26px of sideways scroll at 901),
   so 901-1079 keeps the previous row (buttons + burger), <=900 the phone burger.
   The desktop burger stays hidden (links are on the bar). */
@media(min-width:1080px){
  html body div.wrap > nav{padding:12px 0 !important}
  html nav{display:grid;grid-template-columns:1fr auto auto auto;
       grid-template-rows:auto 0;column-gap:12px;row-gap:0;align-items:center;
       /* row-gap:0: the pages give nav a 16px flex gap, which a grid reads as a
          row gap - that was the extra space under the logo (Phil 01:44) */
       position:relative;border-bottom:1px solid var(--hairline)}
  html nav > .mark{grid-row:1;grid-column:1}
  html nav .links{display:contents;margin:0}
  html nav .links .navcat{display:flex;position:static;grid-row:1;grid-column:2 / -1;
       justify-self:end;gap:24px;align-items:center;
       width:auto;max-width:none;background:none;border:0;box-shadow:none;
       padding:0 calc(var(--toggle-w,44px) + 22px) 0 0;
       /* margin, NOT transform: a transform makes this box the containing block
          for the Services menu and throws its JS-set offset off-screen */
       margin-top:6px}
  html nav .links .navcat > a,
  html nav .links .navcat .navdrop > a{font-size:15px;padding:2px 0;background:none;border:0}
  html nav > .navhandles{grid-row:1;grid-column:4;justify-self:end;gap:0;margin-top:6px}
  html nav .navburger{display:none}
  html nav .links > a.navout,
  html nav .links > a.navbtn{grid-row:2;align-self:start;margin:0;
       transform:translateY(13px);border-top:none;border-radius:0;
       padding:8px 16px;font-size:13.5px;font-weight:600}
  html nav .links > a.navout-purple{grid-column:2}
  html nav .links > a.navout-ink{grid-column:3}
  html nav .links > a.navbtn{grid-column:4;background:#8151ee;border-color:#8151ee;color:#fff}
  /* the Services menu hangs from the bar's bottom edge. The open menu carries a bridge up to
     its trigger so the pointer can reach it — and the bridge IS the purple block round
     "Services" (Phil, 2026-09-24: "when I roll over Services I think we need a purple block
     around Services also"), sized to the trigger by navmenu.js.
     BUG IT REPLACES: the old bridge was invisible, 60px tall and as wide as the whole panel,
     so an open menu covered Work, About and Services itself — none of them could be clicked
     (Phil: "I can't click any of the other menu items when I have the menu open"). */
  html nav .navdropmenu{z-index:90}
  html nav .links > a.navout, html nav .links > a.navbtn{position:relative;z-index:1}
  html nav .navdropmenu::before{content:'';position:absolute;bottom:100%;
       left:var(--tabx,0);width:var(--tabw,0);height:var(--tabh,0);background:#8151ee}
  html nav .navdrop[data-open="1"] > a{position:relative;z-index:91;color:#fff}
  /* the five sit under "All services" as its children. Phil, 2026-09-24: "can the 01-05 menu
     items in the purple menu have a little bit of an indent?" Desktop only; the phone panel
     already indents them behind its own rule line. */
  html nav .links .navdropmenu a:not(.navdropall){margin-left:14px}
  /* ...and the indent must not cost a line: the longest description wrapped once the rows
     got 14px narrower, so the panel grows to fit instead (edge checked 1080-1440). */
  html nav .links .navdropmenu a small{white-space:nowrap}
}

/* THUMB-SIZED TARGETS — Iris, 2026-09-23, from the phone sweep (27 pages x 3 phones x 2 themes).
   Several links painted a 17-23px-tall box: the footer row, the service-card titles and LEARN MORE,
   the stair titles, the case pages' back link, the NDA checkbox line. Nothing here changes what
   anything LOOKS like; it only grows the area a finger can land on, and only on touch screens.
   - A .ucell has one destination (every link in it shares one href, checked on index + work),
     so its title link stretches over the whole card: tap anywhere on the card.
   - Everywhere else the hit area grows by an invisible pseudo-element, sized to at most half the
     gap to the neighbouring target so two targets never overlap.
   Lives here because navmenu.css is the one stylesheet every page loads. */
@media (pointer:coarse){
  .footclean .footlinks a,.stair .t a,.pagehead .backlink,.ndacheck label{position:relative}
  .footclean .footlinks a::after{content:'';position:absolute;inset:-5px -12px}
  .stair .t a::after{content:'';position:absolute;inset:-6px -6px}
  .pagehead .backlink::after{content:'';position:absolute;inset:-13px -10px}
  .ndacheck label::after{content:'';position:absolute;inset:-10px 0}
  .footlegal a{position:relative}
  .footlegal a::after{content:'';position:absolute;inset:-14px -10px}
  /* LAST, on purpose: on the homepage the cells sit inside a .stair, so the stair rule above
     also matches their titles. Same specificity, so source order decides — these must win. */
  .ucell:has(.t a){position:relative}
  .ucell .t a{position:static}
  .ucell .t a::after{content:'';position:absolute;inset:0}
}