/* ==========================================================================
   theme.css - the CSS that CANNOT be kept in `custom.css`.

   `custom.css` is a copy of the HTML build. The client hands over a new build,
   we merge it, and that file gets replaced wholesale - anything written in it
   is lost. So the theme's own rules live here.

   Two kinds of things:

     1. LINK STATES  - class rules that are losing to the specificity of the
                       build's `a:link / a:visited` rule
     2. SECTIONS     - ones that came from the client's written requirement
                       and do not exist in the build's design at all
                       (R3 Judging Panel, R2 Award Updates)

   The form CSS is separate, in `forms.css` - that is for Contact Form 7's
   markup, a different matter from this.
   ========================================================================== */

/* ============================ 0 - BASE ==================================== */

/*
   The `_s` starter theme (style.css:405) gives this on every page:

       body, button, input, select, optgroup, textarea {
         color: #404040;
         font-family: -apple-system, …;
         font-size: 1rem;
         line-height: 1.5;
       }

   In the HTML build `line-height` on body is `normal`. Any element that does
   not set its own line-height picks up 1.5 on WordPress and ends up taller
   than in the build. Measured effect: every FAQ `.faq-qa` 6px taller, the
   three together making the whole section 19px taller.

   This was not a one-spot bug - everywhere on the site where the build did
   not write a line-height, there was a difference. So the fix is at the root
   as well.

   `color` and `font-family` also differ from the build, but the build's own
   CSS sets those everywhere, so they make no difference.
*/
body { line-height: normal; }

/* ============================ 1 - LINK STATES ============================= */

/*
   The build's CSS has this at line 63:

       a, a:link, a:visited { color: inherit; text-decoration: none; }

   Its intent was fine - the footer's visited links were going to the
   browser's own purple. But `a:visited` has specificity (0,1,1) and `.btn`
   has (0,1,0). So this rule beats EVERY button's own colour - not just when
   visited, but FROM THE VERY FIRST VISIT.

   Measured result (live homepage, getComputedStyle):

       a.btn         rgb(49,27,119)   <- purple, should have been #fff
       a.btn-red     rgb(49,27,119)   <- purple
       a.btn-violet  rgb(49,27,119)   <- purple
       a.btn-white   rgb(255,255,255) <- white, should have been red (inverted!)
       a.pill        rgb(49,27,119)   <- purple

   The form submits looked white because they are now <button>, not <a> -
   `a:link` does not apply to them at all. That is exactly why it was hard to
   catch.

   The whole stylesheet has 24 single-class `color` rules; of those only these
   FIVE apply to an `<a>` (found by scanning all five pages). Each gets its
   own colour back, together with `:link`/`:visited` - specificity (0,2,0),
   which beats (0,1,1).

   NOTE: these same five lines should also be in the HTML BUILD's
   `custom.css`, otherwise the static build keeps the same breakage.
*/

.btn:link,
.btn:visited                { color: #fff; }

.btn-white:link,
.btn-white:visited          { color: var(--red); }

.pill:link,
.pill:visited               { color: #fff; }

.link-caret:link,
.link-caret:visited         { color: #000; }

.link-caret-purple:link,
.link-caret-purple:visited  { color: var(--purple); }

/* ------------------------------------------------------- hero letterspacing */

/*
   The homepage hero - "Ireland's Benchmark for Governance Excellence".

   In the build this heading had very light tightening - roughly -0.72px:

       .sec-hero h1 { letter-spacing: max(-0.96px, -0.05vw); }

   CAUTION: never write "slash-star ... star-slash" at the end of the line
   above. CSS comments DO NOT NEST - the first `star-slash` inside closes the
   OUTER comment, and all the prose after it becomes CSS. That is exactly what
   happened: the `-6px` rule below silently vanished and it took hours to work
   out why a rule that is written down was not applying.

   -6px was requested.

   `-6px` CANNOT be written directly: `--h1` itself runs on a clamp (38px to
   101px). At 1920 on a 101px font, -6px sits fine (-0.0594em, equal to the
   site's `-0.06em` scale), but on mobile that same value on a 38px font
   becomes -0.158em - the letters climb on top of each other.

   So the same form the build itself uses, just with the new value: exactly
   -6px at 1920 (design width), and proportionally less on smaller screens.
   0.3125vw x 1920 = 6px.

   NOTE: this same line should also go into the HTML build's `custom.css`.
*/
.sec-hero h1 {
  letter-spacing: -6px;
}

/* -6px gets far too tight on small screens - there `--h1` drops to 38px and
   -6px means -0.158em, the letters practically stick together. So below
   tablet, the site's own heading tracking (-0.06em). */
@media (max-width: 900px) {
  .sec-hero h1 { letter-spacing: -0.06em; }
}

/* ------------------------------------------------------------ search form */

/*
   The Search and 404 pages are WordPress's own pages - they do not exist in
   the build at all, so there is no CSS for `.search-form` either. Unstyled it
   showed as the browser's default box: a thin grey line, a tiny button.

   The site's own field design is in `.ct-form` - a hairline underneath, large
   text above. The same look here, just at a smaller size (this is a toolbar,
   not a form).
*/
.search-form {
  display: flex;
  align-items: flex-end;
  gap: clamp(12px, 1.0417vw, 20px);
  flex-wrap: wrap;
  max-width: clamp(280px, 44vw, 720px);
}

.search-form input[type="search"] {
  flex: 1 1 14rem;
  min-width: 0;
  padding: 0 0 clamp(6px, 0.5208vw, 10px);
  font-family: inherit;
  font-size: clamp(18px, 1.4583vw, 28px);
  font-weight: 600;
  line-height: normal;
  letter-spacing: -0.06em;
  color: var(--purple);
  background: none;
  border: 0;
  border-bottom: var(--rule-w) solid var(--rule);
  border-radius: 0;
  -webkit-appearance: none;
  appearance: none;
}

.search-form input[type="search"]::placeholder { color: rgba(49, 27, 119, .49); }
.search-form input[type="search"]:focus { outline: 0; border-bottom-color: var(--violet); }

/* The button on its own line - otherwise, sitting next to the field, its
   slanted slab cuts through the hairline. */
.search-form .btn { flex: 0 0 auto; margin-bottom: 2px; }

/* --------------------------------------------------------- 404 hero space */

/*
   On 404 the heading looked stuck to the top, and on scroll it slid behind
   the sticky top bar - of the two-line h1 only "page" stayed visible.

   The cause is not spacing but a missing block. `.sec-gh-hero`'s
   `padding-top: clamp(40px, 6.6854vw, 128.36px)` was measured for the
   Governance Hub, and on that page the mega nav sits ABOVE the hero. On 404
   the mega nav is deliberately hidden (header.php's `is_404()` check), so
   that 128px is left on its own - roughly 180px less than every other page.

   Those 180px are added back here, so the 404 heading sits optically on the
   same line where the Governance Hub and Latest News headings sit:

       full height of the mega nav @1920px
         margin-top   16.1
         border       0.8 + 0.8
         padding      19 + 25
         2 lines text 49.147px x ~1.2 x 2  =  ~118
         --------------------------------------
                                          ~179.7px

   The vw was added by the same calculation: 6.6854 + 9.3594 = 16.0448vw. On
   mobile the mega nav is shorter, so the min value stops at 64px - that much
   empty space at the top would look excessive there.

   `.sec-404` and `.sec-gh-hero` are both (0,1,0); this file loads AFTER
   `gga-custom`, so this one wins.
*/
.sec-404 { padding-top: clamp(64px, 16.0448vw, 308.06px); }

/*
   20px between the search block and "Try one of these".

   Before, there was an empty band of ~121px there, built from two places:

       .sec-gh-ideas       padding-top   clamp(28px, 3.7396vw, 71.8px)
       .sec-gh-ideas .gh-sub  margin-top clamp(20px, 2.5635vw, 49.22px)

   Both need reining in - removing only the padding would leave the h3's
   margin behind. So padding 20px, margin 0.

   Scoped to `body.error404`, NOT directly on `.sec-gh-ideas`: the same class
   is also used by the Governance Hub's "Ideas & Suggestions" section
   (hub_categories.php's `sec-gh-ideas`), and there this size comes from the
   design. Without the scope that page would shrink along with it.

   Specificity: body.error404 .sec-gh-ideas (0,2,1) > .sec-gh-ideas (0,1,0).
*/
body.error404 .sec-gh-ideas { padding-top: 20px; }
body.error404 .sec-gh-ideas .gh-sub { margin-top: 0; }

/* --------------------------------------------------------- CMS page space */

/*
   Privacy Policy, Terms, Cookie Policy - after the hero the body copy dropped
   far too low (@1920px roughly 177px of empty space).

   That gap is built from two places:

       .sec-why        padding-top  clamp(44px, 6.6990vw, 128.62px)
       .sec-why .copy  margin-top   clamp(18px, 2.5182vw, 48.35px)

   The measurement is not wrong - in the build there is always a full section
   ABOVE `.sec-why` (the countdown on Home, hero + intro on Previous Winners),
   and that much breathing room is needed there. On these pages there is only
   a two-line hero above it, and on these pages the rich_text heading is also
   empty - so the whole 128px becomes nothing but empty space.

   `body.gga-cms-page` comes from template-functions.php: the pages whose
   builder is only hero + rich_text. Scoping to a page ID instead of the class
   would miss the client's next legal page.

   NOT directly on `.sec-why` - the same class is also used by Home's "Why the
   Awards Matter", the Governance Hub's intro and Previous Winners' "About the
   Winner".

   Specificity: body.gga-cms-page .sec-why (0,2,1) > .sec-why (0,1,0).
*/
body.gga-cms-page .sec-why { padding-top: 44px; }

/* ---------------------------------------------------- CMS page typography */

/*
   This became necessary once the real content of the policy pages arrived.
   In `.copy` the build had only sized `<p>`:

       .copy p { font-size: var(--fs-body); line-height: normal; }
       .copy p + p { margin-top: 1.5em; }

   Everything else was left to the global reset, and that looks very bad
   here:

       h2   gets `--h2` - 34px to 85px. That is a display heading's size, not
            a policy section title's. On screen "What is a cookie?" looked as
            big as the page title.
       h3   same story, `--h3` 26-49px.
       ul   because of the `ul, ol { padding: 0; list-style: none }` reset, no
       ol   bullets and no numbers - the whole Acceptable Use list on Terms
            looked like one run-on paragraph.

   Below is only as much as these pages need. The sizes are taken from the
   design's own scale - `--h4` for h2, h3 between that and body - so the
   hierarchy stays clear but the headings do not overpower the content.

   Everything is inside `body.gga-cms-page`. `.copy` runs across the whole
   site - Home, Governance Hub, Previous Winners, hub cards - and none of
   those have headings or lists at all; applying these rules there would have
   nothing to do with the design.
*/

body.gga-cms-page .copy h2,
body.gga-cms-page .copy h3 {
  color: var(--purple);
  font-weight: 600;
  line-height: 1.25;
  /* Display headings have -0.06em. Tracking that tight is uncomfortable to
     read at a small size, so lighter here. */
  letter-spacing: -0.03em;
  max-width: 48.07em;
}

body.gga-cms-page .copy h2 {
  /* Half of `--h4` (21-36px). Kept in calc so the 50% relationship stays
     visible - if the scale changes, this follows along by itself. */
  font-size: calc(var(--h4) / 1);
  margin-top: clamp(30px, 3.2292vw, 62px);
  margin-bottom: clamp(10px, 0.9375vw, 18px);
}

body.gga-cms-page .copy h3 {
  font-size: clamp(18px, 1.4583vw, 28px);
  margin-top: clamp(22px, 2.0833vw, 40px);
  margin-bottom: clamp(6px, 0.625vw, 12px);
}

/* The section's own padding already sits above the first heading. */
body.gga-cms-page .copy > :first-child { margin-top: 0; }

body.gga-cms-page .copy ul,
body.gga-cms-page .copy ol {
  font-size: var(--fs-body);
  line-height: normal;
  max-width: 48.07em;
  margin-top: 1.2em;
  /* The global reset strips both of these - both restored. */
  padding-left: 1.35em;
  list-style: disc outside;
}

body.gga-cms-page .copy ol { list-style: decimal outside; }

body.gga-cms-page .copy li { padding-left: 0.35em; }
body.gga-cms-page .copy li + li { margin-top: 0.7em; }
body.gga-cms-page .copy li::marker { color: var(--purple); }

/* Returning to a paragraph after a list gets the same room as p + p. */
body.gga-cms-page .copy :is(ul, ol) + p { margin-top: 1.5em; }

/* ------------------------------------------- Stay Connected submit button */

/*
   The SUBMIT of the Governance Hub's "Stay Connected" form.

   The build's design has no button on this form at all - only a label and an
   email field. So no rule for it was ever written in `.connect-form`. But in
   WordPress the form runs on Contact Form 7, and CF7 does not build a form
   without a submit. That button, unsized, was stuck inline BESIDE the input.

   The field is made block so the button drops onto its own line - the rest
   of the markup is CF7's and cannot be touched.

   The size is kept close to the footer's `.ft-news-btn` (10-20.6px) so both
   newsletter forms look alike. The button is aligned to the input's LEFT
   edge; the footer one is on the right because there the field takes the
   full width and the right edge is the only edge it has.
*/
.connect-form .wpcf7-form-control-wrap[data-name="your-email"] { display: block; }

.connect-form .wpcf7-submit { margin-top: clamp(12px, 1.25vw, 24px); }

/* -------------------------------------------------- topic list caret nudge */

/*
   The caret down by 4px. In the build it sits slightly above the text's
   optical line - `align-items: center` centres the circle's bounding box, but
   visually the caret drifts upward.

   vw instead of px: 4px @1920 = 0.2083vw. The rest of the file is measured
   the same way, so on smaller screens this shrinks along with it. The clamp's
   min is 2px - below that the nudge simply stops being visible.

   `position: relative` is required with this. `top` does nothing on a static
   element, and CSS does not complain about it either - the rule just sits
   there silently doing nothing.

   Where it shows: the Governance Hub's topic lists (Ideas & Suggestions, Best
   Practices) and the 404 page's "Try one of these".
*/
.topic-list a img {
  position: relative;
  top: clamp(2px, 0.2083vw, 4px);
}

/* ================= 1b - DESIGN REVIEW, 6 Aug 2026 (HOME) ================= */

/*
   The rules below came from the client's design review. Each one also notes
   the Figma node the measurement was taken from, so next time nobody takes
   it for "someone changed this by eye".
*/

/* ---------------------------------------------- Previous Winners divider */

/*
   BETWEEN the heading ("Previous Winners" + lead) and the intro paragraph on
   the right there is a vertical line. In Figma it is `Line 20` (772:984) -
   x=819, y=5895, height=185 - and in the build it was never created.

   How it was missed: in the dump this line sits inside the "09 - Awards
   Timeline" frame (in Figma the layer is grouped there), and in the spec-map
   it was taken for a "timeline column divider" and waived. The timeline's
   real dividers are `Line 14/15/16` - x=340/747/1292, y=5505, height=148.
   This one is 390px lower and 37px taller; that is how you can tell it is a
   different thing. Because it was waived, no check ever asked for it.

   Measurements:
     left    819 - 65.6 (container's left edge) = 753.4 -> 42.12% of .wn-head
     top     the line starts 15px ABOVE the heading         -> -0.625vw
     height  185px @1920                                   -> 9.6354vw

   Colour and thickness like the rest of the site's dividers - `--rule` /
   `--rule-w` (the countdown and timeline dividers are the same).

   On mobile the two columns stack one below the other (custom.css:1536), and
   a vertical line makes no sense there - so off below 900px.
*/
.wn-head { position: relative; }

.wn-head::before {
  content: "";
  position: absolute;
  left: 42.12%;
  top: clamp(-12px, -0.625vw, 0px);
  width: var(--rule-w);
  height: clamp(80px, 9.6354vw, 185px);
  background: var(--rule);
}

@media (max-width: 900px) {
  .wn-head::before { display: none; }
}

/* ------------------------------------------------ partner list caret gap */

/*
   The space between a partner's name and its caret. In the build the gap was
   15px @1920 and the caret looked stuck to the name.

   In Figma the caret's x leaves ~25-37px after the name in every row
   (772:989 Board Effect x=294, 772:990 Chartered Accountants x=579,
   772:992 DAVY x=195, 772:993 Ecclesiastical x=318 - the name starts at x=74
   in all of them). That 24px here.

   Scoped to `.sec-partners`, NOT directly on `.acc-head`: the same class
   also applies to the Award Entry FAQ and the Judging Process steps, and
   there the caret has its own separate layout (`.step-mark img` is
   absolute). Without the scope both of those pages would shift along with it.
*/
.sec-partners .acc-head { gap: clamp(10px, 1.25vw, 24px); }

/* ------------------------------------------- Why Governance Matters bars */

/*
   The coloured slabs were ending ~30px before their text.

   In Figma each slab's right edge (worked out with the rotation removed - the
   node's w/h is the AABB of the rotated rectangle):

     Rectangle 35  orange   72.4 .. 743.7      build  65.6 .. 713.7
     Rectangle 36  violet   73.8 .. 1078.2     build  65.6 .. 1045.3
     Rectangle 37  teal     72.0 .. 880.0      build  65.6 ..  849.9
     Rectangle 38  red      72.0 .. 1280.0     build  65.6 .. 1242.9
     Rectangle 39  amber    73.0 .. 1080.0     build  65.6 .. 1045.3

   The shortfall is roughly equal in all five (25-37px), and the cause is the
   same: in the build the padding on both sides is 64.9px, whereas in the
   design LEFT is ~63px and RIGHT is ~96px. The slab breathes more after the
   text.

   Only the right padding changed - left as it was, otherwise the text would
   shift out of place (and its position already matches Figma: 772:1104-1112).

   The sixth slab (772:807, "Benchmark governance practices") has its own
   right padding of ~60px in Figma - a hand-made slab with its own slant. It
   gets the same 96px too; looking uniform matters more here.
*/
.ab-bars .bar { padding-right: clamp(20px, 5vw, 96px); }

/* ------------------------------------------------- footer address */

/*
   The address should not be underlined - in the design it is plain text.

   theme.css already had `.ft-map { text-decoration: none }` (the "map link"
   block below), but it was LOSING:

       .ft-col-address a   (0,1,1)   custom.css:1424   underline
       .ft-map             (0,1,0)   theme.css         none

   Email and phone ARE underlined in the design, so `.ft-col-address a` stays
   as it is - only the address link gets the exemption. (0,2,1).
*/
.ft-col-address .ft-map { text-decoration: none; }

/* ============ 1c - DESIGN REVIEW, 6 Aug 2026 (AWARD ENTRY) ============== */

/* --------------------------------------------- Judging Process heading */

/*
   "A Rigorous and Independent / Judging Process" sat ~10px ABOVE its place.
   The verify report (reports/award-entry.txt) had that very number:

       05 - Judging Process   772:1440   dy -10.21   .sec-ae-judging h2

   With the section's own drift (+52.18) already subtracted - i.e. this is the
   real difference inside that section, not the whole section shifting. The
   teal slab (Rectangle 69, y=3352) gives the same ~9px.

   `margin-top` instead of changing `padding-top` - the section's pinwheel
   (`.ae-pinwheel-2`, absolute) rests on the padding, and its background
   would shift down along with the heading.
*/
.sec-ae-judging h2 { margin-top: clamp(4px, 0.5208vw, 10px); }

/* -------------------------------------------------- step accordion arrow */

/*
   The open step's arrow was FLIPPED.

   custom.css:2216 has `rotate(-2.37deg) rotate(180deg)` on
   `.step.is-open .step-mark img` - i.e. 180 more on top of the slab's slant.
   The design has no such thing: in Figma the third step is OPEN (Independent
   Assessment) and its arrow (772:1642 "Group 8", x=122 y=4390) keeps exactly
   the same shape and the same position as the arrows of the closed steps
   (772:1632 y=3811, 772:1617 y=4109) - pointing downward.

   Only the 180 was removed; the slab's -2.37deg stays, otherwise the arrow
   would stop looking slanted along with the slab.
*/
.steps .step.is-open .step-mark img { transform: rotate(-2.37deg); }

/* --------------------------------------------------- "Submit Entry" space */

/*
   Two words looked like one - "SubmitEntry".

   The cause is `letter-spacing: -0.06em`, which also applies to the space
   glyph: at 39px that is -2.34px between every letter, and the space shrinks
   by just as much. In the other headings that tightening is not noticeable,
   but on a small two-word button it is clearly caught.

   `word-spacing` only opens the space back up; the letter tightening stays
   exactly as it is.

   Why font 39 to 38: the button's width comes from the design (Rectangle 103,
   227.6px) and the full calculation at forms.css:519 says 215.3px is left
   for the text. At 39px the text was 212.6px - only 2.7px to spare, and
   word-spacing would eat more than that. At 38px the text is 207.1px, plus
   0.12em (4.6px) word-spacing = 211.7px. Still inside, and the gap shows.
*/
.btn-submit {
  font-size: clamp(20px, 1.9792vw, 38px);
  word-spacing: 0.12em;
}

/* --------------------------------------------------- upload drop zone */

/*
   Dropping a file on the zone now works (see custom.js). This is its visible
   part - during the drag the zone signals that a file can be released here.
   Without this cue the user has no way of knowing that the zone accepts
   drops, and goes back to Select Files.

   The colour is the site's own teal, lightened - the box has no border of
   its own in the design, so only the background is changed.
*/
.up-zone .up-drop.is-dragover {
  background: color-mix(in srgb, var(--teal) 12%, transparent);
}

/* ========= 1d - DESIGN REVIEW, 6 Aug 2026 (GOVERNANCE HUB) ============== */

/* ------------------------------------------------ "Read more.." one line */

/*
   In the Case Studies card the excerpt and "Read more.." are in the same
   `<p>`, so the link's two words were breaking onto separate lines:

       ... and foster continuous improvement. Read
       more..

   The link is a control, not a sentence - part of it moving to the next line
   looks broken. `nowrap` is only on the LINK, not the paragraph: the copy
   must wrap fully.

   `.case-grid p > a` - inside `.case-grid` the h3 also has a link, and that
   one must wrap (the titles are long). So only the paragraph one.
*/
.case-grid p > a { white-space: nowrap; }

/* ===== 1e - DESIGN REVIEW, 6 Aug 2026 (HIGHLIGHT SPAN - WHOLE SITE) ===== */

/*
   The space BEFORE the highlighted word in a heading.

   The same complaint came from three different places - "Latest News &
   Insights", "Organisation Snapshot", "By The Numbers" - that the plain word
   and the coloured slab are stuck to each other.

   The cause is the same. The heading has `letter-spacing: -0.06em` and that
   also applies to the SPACE glyph; on top of that the slab (`::before`,
   `inset: 0 -0.02em`) and the span's own `padding-inline: 0.055em` together
   start 0.075em before the word. On an 85px heading the remaining distance
   is ~10px - so little that the two words look like one.

   The fix is `word-spacing`, NOT `margin`. It was this 0.06em tracking that
   took it away from the SPACE, and `word-spacing` gives it back to the space
   only - the letter tightening (which is the design's own) stays exactly as
   it is.

   A margin on the span was the first thought, but it does not work:
   `:not(:first-child)` is useless because `:first-child` only counts
   ELEMENTS - in "Latest <span>News</span> & Insights" that span is the first
   (and only) element, so the rule would hit exactly the one it was meant to
   skip. And without that guard, headings whose FIRST word is the highlight
   ("Awards Timeline", "Key Dates", "Inspired by These Stories?") would have
   the whole heading shift 5px to the right - when there is nothing to their
   left.

   With `word-spacing` the question never arises: there is no space at the
   start of a heading, so a leading span stays where it is.

   Comparison with Figma (slab's LEFT edge, rotation removed):

                            before   now     Figma
     Latest News            345.1   351.2    355.3
     Organisation Snapshot  545.7   550.8    548.3
     By The Numbers         312.3   322.5    311.8

   The right edge is ~45px short of Figma in all three - that is a separate
   matter, and it did not come up in the review, so it is left alone.

   `:where()` so the specificity stays 0 - any page's own heading rule sits
   above this without a second thought.
*/
:where(h1, h2, h3, h4, h5) { word-spacing: 0.06em; }

/* ---------------------------------------------- highlight slab padding */

/*
   How far the coloured slab extends before and after the word - 0.055em to
   0.2em. Client review, 6 Aug. Across the WHOLE site, at every heading size.

   Being in `em` it stays correct at every size by itself: on h2 (85px) ~12px
   each side, on h1 (101px) ~15px.

   This rule overrides `custom.css:102`. Going there to change it would be
   WRONG - that file is a straight copy of the client's HTML build and gets
   replaced wholesale as soon as the next build is merged (functions.php:668),
   meaning this value would silently go back to 0.055em and nobody would
   notice. Written here it survives the merge; this file loads AFTER
   `gga-custom`, so it wins even at the same specificity.

   One effect of this is worth keeping in mind: the padding grows on both
   sides, so the text AFTER the span also shifts 0.29em to the right. 30
   headings (five pages) were measured - none changed its line count and the
   page does not overflow sideways at any width.

   By Figma's account this is an improvement: the slab's RIGHT edge was
   previously ~45px short of the design (in all three of Latest News hero,
   Organisation Snapshot, By The Numbers), now that difference is halved.
*/
:is(.h1, .h2, .h3, .h4, .h5) { padding-inline: 0.2em; }

/* ========== 1f - DESIGN REVIEW, 6 Aug 2026 (LATEST NEWS) ================ */

/* --------------------------------------------------- "Read full story" */

/*
   The Featured Story button was smaller than the design:

       Figma  Component 2 (772:1995)   249 x 57
       build  .feature-btn             207 x 52

   `.btn`'s own padding is 21px and min-height 52px - that size is for ALL
   buttons and matches Figma across the whole site, so the base was left
   alone. Only this one button is larger in the design.

   42px padding -> 165.3 (text) + 84 = 249.3, and height 57. Both on Figma.
*/
.feature-btn {
  padding-inline: clamp(18px, 2.1875vw, 42px);
  min-height: clamp(44px, 2.9688vw, 57px);
}

/* ---------------------------------------- "Read more.." on its own line */

/*
   In the More Stories card "Read more.." was stuck to the paragraph's last
   sentence, and underlined.

   On this same site this link exists in two more places and in neither does
   it look like that - `.case-grid p a` (custom.css:3395) and
   `.art-col .art p.story-body a` (1943) both have light purple and no
   underline. Only More Stories was left on
   `.story-body a { text-decoration: underline }` (1809).

   Now that third instance matches the other two: its own line, light purple,
   no underline. The size (font-size) stays the copy's own - in Figma this
   link is in the same text node AS the body, i.e. its size is the body's.
*/
.story-grid .story-body a {
  display: block;
  margin-top: 0.6em;
  color: rgba(49, 27, 119, .4);
  text-decoration: none;
}

.story-grid .story-body a:hover { color: var(--violet); }

/* ------------------------------------------------ "Latest Announcements" */

/*
   Two things - the size and the space below it.

   In Figma (772:2060) this heading's text box is 78px; in the build it was
   62px (font 49.15). 78 / 1.2616 (Plus Jakarta Sans's normal line box) =
   61.83px - that is what is here.

   Scoped to `.sec-ln-campaign`. `.ln-sub-2` is also on Governance News and
   there its own size is already written (custom.css:1900, 85px) - without
   the scope that would change too.

   The space below: in Figma from the heading's bottom (5484) to the list's
   first line (5576) is 92px; in the build it was 109px.

   6 Aug, after the review: the client asked for 60px - even less than
   Figma's 92. Deliberately differs from the design, which is why it is
   written down.

   Not a flat `60px`: the whole build is measured in `clamp(min, XXvw, max)`,
   and a flat value is only right at 1920 - on smaller screens it would fall
   out of proportion. 60 / 1920 x 100 = 3.125vw, and the min in the same
   ratio (26 x 60/92 = 17).
*/
.sec-ln-campaign .ln-sub-2 { font-size: clamp(26px, 3.2203vw, 61.83px); }

.sec-ln-campaign .ann-list { margin-top: clamp(17px, 3.125vw, 60px); }

/* --------------------------------------- "View All Campaign News" button */

/*
   The slab was stuck to the text - no breathing room above or below at all.

       Figma  Rectangle 123 (772:2071)   h 72
       build  .ann-btn                   h 52

   Width unchanged. `.ann-btn`'s `min-width` (425px) comes from Figma itself,
   but this button's label at 40px is wider than that and stretches it;
   reducing the width would clip the text.
*/
.ann-btn { min-height: clamp(48px, 3.75vw, 72px); }

/* ------------------------------- space after Campaign Announcements */

/*
   After the button it was far too empty up to the Governance News band:

       Figma  button's bottom 6484  ->  band 6611   = 127px
       build                  6361  ->       6536   = 174px

   That whole distance comes from `.sec-ln-gov`'s `padding-top` (174.53px,
   custom.css:1896) - measured, the gap came out equal to the padding. So
   straight to Figma's 127px.
*/
.sec-ln-gov { padding-top: clamp(30px, 6.6146vw, 127px); }

/* ----------------------------------- "Inspired by These Stories?" button */

/*
   The space between the copy and the "Submit Your Entry" button - 132.66px
   to 100px. Requested by the client on 6 Aug.

   Scoped to `.sec-ln-cta`, NOT directly on `.cta-btn`. Right now that class
   is only on this one button (measured across the whole site) - but the
   other two CTA buttons carry their own separate classes with their own
   sizes:

       .pw-cta-btn    79.83px    Previous Winners / winner detail
       .art-cta-btn              article

   So today nothing would break even without the scope. The scope is there so
   that if someone reuses `.cta-btn` in another section tomorrow, this size
   does not travel with it - that bug would arrive silently and be hard to
   catch.

   Not a flat `100px`: the whole build is measured in `clamp(min, XXvw, max)`.
   100 / 1920 x 100 = 5.2083vw, and the min in the same ratio
   (20 x 100/132.66 = 15).

   custom.css:1959 has the old value on both `.cta-btn` and
   `.sec-ln-cta .cta-btn`; this file loads AFTER it, so even at equal
   specificity (0,2,0) this one wins.
*/
.sec-ln-cta .cta-btn { margin-top: clamp(15px, 5.2083vw, 100px); }

/* ------------------------------------------------------------- map link */

/*
   The address now links to Google Maps. In the build it was plain text, so
   it should keep looking the same - otherwise a new underline suddenly
   appears in the footer that is not in the design.

   Only on hover does it reveal that it can be clicked.
*/
.ct-map,
.ft-map { color: inherit; text-decoration: none; }

.ct-map:hover,
.ft-map:hover { text-decoration: underline; text-underline-offset: 3px; }

/* --------------------------------------------------------- accordion caret */

/*
   The caret stays RIGHT AFTER the title, vertically centred with the text -
   as in the build.
   At one point it was pushed to the row's right edge with `margin-left:auto`.
   That strayed from the design: measured, the caret is at `left=113px` in
   both the build and live. That rule was removed - `.acc-head` itself is
   `display:flex; align-items:center`, so the caret lands in the right place
   and centred on the line by itself.
*/

/*
   No border on the steps accordion.

   `custom.css` has `.acc-item { border-bottom }` - that rule was written for
   the Partners and FAQ accordions, where each item is a list row and is set
   apart by the line.

   In Steps each `<li>` is a large slab in its own colour and the distance
   between them comes from the `nth-child` margins. There that line looked
   completely out of place - and it showed ONLY on the step that has a
   criteria panel (because the `acc-item` class is only on that one). So one
   lone line under one of six steps - looks like a bug.

   The override is here, not in `custom.css`: that file is a copy of the HTML
   build and gets replaced wholesale as soon as the client's new build
   arrives.
*/
.steps .acc-item { border-bottom: 0; }

/* --------------------------------------------- article without sidebar */

/*
   The hub resource / judge / award category detail pages have no sidebar
   (`$gga_solo` in single.php). Without it the two-column grid looks wrong:
   the second column stays empty and the `.art-layout::after` divider line
   stands to the right of the article - a line with nothing beyond it.

   So one column here, and the whole block centred on the page.

   The width is `.art-hero`'s (1218px @1920) - it is the widest element in
   this layout, so a narrower column would crop the image. Everything else
   fits inside it by itself.

   These rules CANNOT go into custom.css - that is a copy of the HTML build
   and gets replaced wholesale as soon as the client's new build arrives.
*/
.art-layout-solo {
  grid-template-columns: 1fr;
  max-width: clamp(280px, 63.4375vw, 1218px);
  margin-inline: auto;
}

/* divider line - there is no second column, so no need for it either */
.art-layout-solo::after { content: none; }

/*
   The divider line should end with the article, not run down to the footer.

   In custom.css its height is FIXED:

       .art-layout::after { height: clamp(400px, 131.3421vw, 2521.768px) }

   That measurement came from the ONE article in the build whose content was
   that long. On every other article it is wrong - and the error only goes
   one way:

       layout's actual height    1698px
       line's height             2521px
       past the layout's bottom  +884px
       into the footer           +752px

   So on a short article a long line keeps running after the content and
   reaches up over the purple footer.

   `bottom: 0` makes the line always end with the layout - long article or
   short. `top` stays the build's, so the start is exactly as before.

   `height: auto` must be written: when `top` + `bottom` + `height` are all
   set, the browser lets `height` win and `bottom` goes to waste.
*/
.art-layout::after {
  height: auto;
  bottom: 0;
}

/*
   The build's negative margins work against us here.

   `.art-hero` has `margin-left: clamp(-36.88px, -1.9208vw, 0px)` and
   `.sec-article h1` is negative too - that was to push the image slightly
   out past the left column's grid line. In a centred column that same margin
   shifts the whole block left and the centring looks broken.
*/
.art-layout-solo .art-hero {
  width: 100%;
  margin-left: 0;
}

.art-layout-solo .sec-article h1,
.art-layout-solo .art-meta,
.art-layout-solo .art-byline,
.art-layout-solo .art-body {
  margin-left: 0;
  max-width: 100%;
}

/* text stays left-aligned - only the block is centred, reading is unchanged */

/* -------------------------------------------- governance hub sliders */

/*
   Guidance & Reports and Expert Opinions now run on Swiper.

   The build's markup is `<ul class="report-grid">` / `<ul class="expert-grid">`
   and ALL of its sizes are written on that class. Swiper needs
   `.swiper-wrapper`. So the class was NOT changed - both sit on the same
   element, and only `display` is switched here from grid to flex.

   This override is necessary. `.report-grid` (0,1,0) and `.swiper-wrapper`
   (0,1,0) have equal specificity, so the winner is decided by load order -
   and that cannot be relied on: swiper.css can come after `gga-custom` or
   before it. If grid wins even once, all the cards cram into a single column.
*/
.report-grid.swiper-wrapper,
.expert-grid.swiper-wrapper {
  display: flex;
  grid-template-columns: none;
  width: auto;
  max-width: none;

  /*
     `margin-left` must also be ZEROED.

     In the build both grids have a small nudge - +6.35px on
     `.report-grid`, -1.78px on `.expert-grid` - so the grid sits exactly
     in place.

     Inside the slider that same nudge ruins everything. Swiper measures
     the slide width from the CONTAINER (1774/4 = 443.5px), but the
     wrapper starts 6.35px in - so the total width of four slides ends up
     6.35px more than the container and the last card is clipped by that
     much. On the second page a card even starts peeking in from the
     left: 3 full + 2 partial.

     A 6px nudge, and the whole paging is wrong.
  */
  margin-left: 0;
}

/*
   Swiper sets the slide width via inline style (from slidesPerView).
   `.report-grid li` has the build's own `display:grid` - that builds the
   two-column image-and-body layout INSIDE the card, and must stay as it is.
*/
.gh-swiper { overflow: hidden; }

/*
   The expert card's amber slab comes from `::before` and it is rotated
   (-1.52deg / -2.89deg). Inside `overflow:hidden` the corner of the tilt was
   being clipped, so the slider is given a little room and that room is taken
   back with margin - the layout stays in place.
*/
.gh-swiper[data-gh-slider="expert"] {
  padding-block: 12px;
  margin-block: -12px;
}

/* Everything fits on one screen - Swiper did not run at all (gh-slider.js).
   Then `.swiper-wrapper`'s flex is not wanted, the build's grid is right. */
.gh-swiper-static .report-grid.swiper-wrapper { display: grid; grid-template-columns: 449.25fr 446.84fr 451.95fr 448.96fr; }
.gh-swiper-static .expert-grid.swiper-wrapper { display: grid; grid-template-columns: repeat(2, minmax(0, 1fr)); }

/*
   The card's own layout must be PROTECTED from Swiper.

   swiper-bundle.css has:

       .swiper-slide { display: block; ... }

   `.expert` and `.swiper-slide` are both (0,1,0) - EQUAL specificity. And
   swiper.css is enqueued mid-render by `gga_slider_assets()`, so it prints
   AFTER `custom.css`. At equal specificity the later one wins, so
   `.expert { display: grid }` lost:

       the photo column (178px) was gone
       `.expert-who img { width: 100% }` got the whole card's width
       the photo showed three times too large

   `.report-grid li` escaped this because it is (0,1,1) - element + class -
   and sits above `.swiper-slide` (0,1,0). Only `.expert` was affected.

   Writing the two classes together makes it (0,2,0) - now it wins whichever
   order the files come in. `grid-template-columns` stays untouched on
   `.expert`, Swiper does not interfere with it at all.
*/
.expert.swiper-slide { display: grid; }

/* The dots are real controls now - the cursor should say so too. */
.gh-dots button { border: 0; }
.gh-dots .gh-dot { cursor: pointer; }

/* ============================== 2 - SECTIONS ============================== */

/* ------------------------------------------------------- judging panel */

/*
   The `.expert` card was built for the Governance Hub's Expert Opinions:

       grid-template-columns: 178px 1fr;   <- photo left, article body right
       .expert-body p { max-width: 505px }

   There the right column holds the article's long excerpt. In the judging
   panel there is only a name, title and organisation - so that 500px+
   column sat EMPTY and the card looked three times too tall.

   On top of that `.expert-grid` has no `row-gap` at all (the build had only
   two cards, a single row), and because of the tilt on `.expert::before`
   (-1.52deg / -2.89deg) the amber slabs of two rows ran into each other's
   corners.

   Compact card: photo ON TOP, name below, three per row, and row-gap.
*/

.people-grid-compact {
  grid-template-columns: repeat(3, minmax(0, 1fr));
  /* the corners stick out because of the tilt - the gap must be larger than
     that, otherwise two rows touch */
  column-gap: clamp(16px, 2.0833vw, 40px);
  row-gap: clamp(28px, 2.9167vw, 56px);
  max-width: none;
}

.people-grid-compact .expert {
  display: block;
  padding: clamp(18px, 1.6667vw, 32px) clamp(16px, 1.4583vw, 28px)
           clamp(20px, 1.8750vw, 36px);
}

/* `.expert-b` takes its own separate padding (because of the larger tilt in
   the build) - in the compact card both are the same. */
.people-grid-compact .expert-b {
  padding-left: clamp(16px, 1.4583vw, 28px);
  column-gap: 0;
}

/* Photo on the LEFT, name-title-organisation BESIDE it - the card uses its
   full width and stays short.
   With the name underneath, 300px of amber sat empty on the right; and
   giving the photo the full width made the card 440px tall, which is too
   much for the homepage teaser. */
.people-grid-compact .expert-who {
  display: grid;
  grid-template-columns: clamp(84px, 6.6667vw, 128px) minmax(0, 1fr);
  column-gap: clamp(12px, 1.0417vw, 20px);
  align-items: center;
}

.people-grid-compact .expert-who img {
  margin-top: 0;
  width: 100%;
}

.people-grid-compact .expert-name {
  margin-top: 0;
  font-size: clamp(14px, 1.0417vw, 20px);
  line-height: 1.35;
}

/* The teaser has no bio - if one ever appears, the card should not burst. */
.people-grid-compact .expert-body {
  margin-top: clamp(10px, 0.8333vw, 16px);
}

@media (max-width: 900px) {
  .people-grid-compact { grid-template-columns: repeat(2, minmax(0, 1fr)); }
}

@media (max-width: 560px) {
  .people-grid-compact { grid-template-columns: minmax(0, 1fr); }
}

/* --------------------------------------------------- full panel (with bio) */

/*
   meet-the-judges has bios, so two per row is fine. But here too there was
   no `row-gap` - three rows of slanted slabs were climbing onto each other.
*/
.people-grid {
  row-gap: clamp(24px, 2.5000vw, 48px);
}

/* The build's bottom padding is sized for a long article excerpt. On a one-
   or two-line bio it leaves a large empty area at the bottom of the card. */
.people-grid .expert {
  padding-bottom: clamp(20px, 2.0833vw, 40px);
}

/* ------------------------------------------------------------ section end */

/*
   The `.rule-btn` button is made to sit ON TOP of a rule (Previous Winners
   has that very design). Below the judging panel comes `.sec-timeline`, and
   the button was intruding into its own padding-top - the button and the
   timeline's hairline were overlapping each other.

   Give the section its own bottom padding.
*/
.sec-gh-experts .rule-btn {
  margin-top: clamp(28px, 3.1250vw, 60px);
}

body.home .sec-gh-experts,
.sec-gh-experts:has(+ .sec-timeline) {
  padding-bottom: clamp(32px, 3.3333vw, 64px);
}

/* -------------------------------------------------------- award updates */

/*
   Award Updates is not in the build either. It reuses `sec-ln-more`, and that
   class is already on the page for "More Stories". With the same
   `padding-top` applied twice, the distance between the two sections looked
   doubled. The one that comes second gets the smaller padding.
*/
.sec-ln-more ~ .sec-ln-more {
  padding-top: clamp(28px, 3.1250vw, 60px);
}

/* ---------------------------------------------------------- checkbox tick */

/*
   In the build a checked checkbox only fills red - no tick mark at all. The
   client wants a tick to show when checked, so this is not in the build but
   here.

   ::before/::after are not reliable on an `appearance: none` input, so the
   tick is an inline SVG as a background-image. custom.css's
   `:checked { background: var(--red) }` shorthand resets background-image
   too - but this file loads AFTER it (gga-theme's dependency is gga-custom),
   so the background-image here wins and the red fill stays exactly as it
   was.
*/
.ae-form input[type="checkbox"]:checked {
  background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24'%3E%3Cpath fill='none' stroke='%23fff' stroke-width='3.2' stroke-linecap='round' stroke-linejoin='round' d='M5 12.5l5 5.5L19 6.5'/%3E%3C/svg%3E");
  background-repeat: no-repeat;
  background-position: center;
  background-size: 68% 68%;
}

/* ------------------------------------------ base margin on the build's lists */

/*
   `style.css:487` (the underscores base) gives every list
   `margin: 0 0 1.5em 3em`. 3em = 48px. The static build never had such a
   base, so custom.css never set its lists' left margin anywhere - there was
   no need. On WordPress that 48px silently landed in front of every classed
   list.

   In the Judging Process the whole steps block was 48px to the right of
   Figma - all six steps, every label and every description. Figma says
   `.step-desc` should be at x=225.68; the comment at award-entry.css:191
   shows the build measured the same, yet on the page it was at 273.67. The
   CSS was not wrong - there was a hidden 48px in front of it.

   The specificity is deliberately kept at 0,0,1. `:where()` adds nothing, so
   this rule is EQUAL to the base `ul, ol` and wins only because theme.css
   loads later. Meaning any class rule in custom.css (0,1,0) stays above it -
   `.crit-list`'s `margin-left: -151.77px` applies exactly as before. Writing
   `ul[class]` would make it 0,1,1 and crit-list's own offset would be lost.

   Classed lists only - the editor's plain <ul> keeps its indent. Classes
   starting `wp-` are left out: the block editor's `wp-block-list` is
   content, not a build component.
*/
ul:where([class]:not([class*="wp-"])),
ol:where([class]:not([class*="wp-"])) {
  margin-left: 0;
}

/* ---------------------------------------------------- article sidebar CTA */

/*
   The article page's "Inspired by These Stories?" block. All three things
   are at the right x, only the two gaps between them were too large.
   Measured (1920, headless):

                       Figma          build         diff
     title -> copy     181.3px        189.1px       +7.8
     copy  -> button   211.1px        213.1px       +2.0

   In custom.css `.art-cta-copy`'s margin-top is 46.91px and `.art-cta-btn`'s
   is 57.13px. Those values were measured against the title/copy height that
   Figma's TEXT BOX reports - but Figma's text box is taller than the
   rendered text (the title's box 156px, in the browser 142.3px). So the gap
   came out larger by that much.

   The new numbers are based on rendered height: 181.3 - 142.3 = 39.0, and
   211.1 - 156.0 = 55.1.

   The clamp() form is kept as in the build - vw = px / 1920 * 100 -
   otherwise this would only look right at 1920 and break at every other
   width.
*/
.art-cta-copy { margin-top: clamp(20px, 2.0313vw, 39px); }
.art-cta-btn  { margin-top: clamp(20px, 2.8698vw, 55.1px); }


.ft-top span.wpcf7-form-control-wrap + a{display:none}

/* ========= 1e - RESPONSIVE FIXES, 7 Aug 2026 ============================ */

/* ------------------------------------------ upload zone breaks at 768-990 */

/*
   The upload zone is a grid of three cells:

       .up-zone { grid-template-columns: 530.06fr 646fr 600.03fr }

   custom.css collapses it to one column ONLY at 767px (custom.css:2733). In
   the band between - 768 to 990 - it stays three columns, and there all
   three cells are too narrow for their text. On iPad Mini (768):

       "Drop Files Here"                  two lines
       "Annual Report & Financial ..."    two lines
       "Accepted: pdf, doc, docx"         two lines

   and the "Select Files" button spills out of its cell and hangs below. The
   cell uses the `--h3` font (the clamp's max only drops below 767px), so
   there is even less room.

   Why 990: the site's other breakpoints are there (custom.css:2028, 2676) -
   the mega nav and header take their mobile form at that width. The upload
   zone stopping at 767 was an oversight, not a considered decision.

   The rules are an EXACT copy of the 767 block. Below 767 both apply and
   theme.css loads later, so this one wins - but the result is identical, so
   nothing visibly changes anywhere.

   `!important` comes from custom.css and is needed here too: `.up-drop`,
   `.up-count` and `.up-see` (custom.css:2571-2573) have specificity EQUAL to
   `.up-cell` (0,1,0) and are written later. Without it their own clamp()
   padding-left would remain and the cells would shift right in the stack.
*/
@media (max-width: 990px) {
  .up-zone {
    grid-template-columns: 1fr;
    min-height: 0;
    row-gap: 18px;
    padding: 20px 0;
  }
  .up-cell { padding: 0 !important; }
  .up-cell + .up-cell { border-left: 0; }
  .btn-files { margin-left: 0; }
}

/* ------------------------------- zone layout blows apart on file selection */

/*
   As soon as a file is chosen, custom.js writes its NAME into the third cell
   (custom.js:313, `.up-see p`). A real file name looks like this:

       EAadhaar_081107929071912025010415511 9_1002.pdf

   - one long word, no space in the middle. And that cell is on `--h3` (~50px
   at 1920), so on a single line it runs out past the whole section and the
   page gets a horizontal scroll.

   At the root is CSS Grid's own default, not the font. A grid item's
   `min-width` is `auto`, i.e. it can never get smaller than its MIN-CONTENT.
   For an unbreakable word the min-content is its full width, so the third
   track grows that wide and the `530.06fr 646fr 600.03fr` ratio becomes
   worthless - the other two cells get squeezed. That is also why "Drop Files
   Here" turns into two lines.

   `min-width: 0` brings the track back to its fr, and `overflow-wrap:
   anywhere` lets the name break. `anywhere`, not `break-word` -
   `break-word` does NOT change the min-content calculation, so the grid
   would stay just as wide and all that happens is the text breaks inside it.

   Capped at two lines: however long the name, the zone's height stays the
   same. Without this a 50px name would take five lines and the zone would
   become three times as tall - no overflow, but it would still look broken.

   Only on `.up-see p` - the text of the other cells is our own and never
   gets that long.
*/
.up-cell { min-width: 0; }

.up-see p {
  overflow-wrap: anywhere;
  display: -webkit-box;
  -webkit-box-orient: vertical;
  -webkit-line-clamp: 2;
  line-clamp: 2;
  overflow: hidden;
}

/*
   Breathing room between a cell's text and the next divider line.

   `.up-cell + .up-cell` has `border-left` (custom.css:2564), but the padding
   is only on the LEFT (custom.css:2571-2573) - nothing on the right. So two
   lines of text set at `--h3` run straight into the next cell's line, and
   all three cells look jammed into each other.

   On `max-width` - not on `padding-right`. The padding comes from a separate
   clamp() in each of those three rules; writing a fourth value on top would
   mean re-reading that calculation in three places. A width limit derives
   from the cell's own width, so a single line for all three is enough.

   Not in `custom.css` - that is a copy of the build, and gets replaced
   wholesale as soon as the client's new build arrives (see
   functions.php:675). Here `.up-cell p` has the same specificity (0,2,0),
   but this file loads AFTER `gga-custom` - so no need for `!important`.
*/
.up-cell p { max-width: 95%; }

/* --------------- Judging Process: arrow's coloured block breaks on mobile */

/*
   In the design, BELOW each step's slab there is a coloured strip and INSIDE
   it a white arrow - together they form the "read on" cue. The strip is
   `.step-mark::after` (custom.css:2256), the arrow `.step-mark img`
   (custom.css:2289). Both are absolute, both have their own clamp(), and
   both are measured from the TOP edge of `.step-mark`.

   Below 767 that pair falls apart - all three clamps reach their FLOOR, and
   the floors do not agree with each other:

       mark's height    ~45px   (24px font + 8px/8px padding)
       ::after          top 6px  + height 70px    ->  ends at 76px
       img              top 58px + ~26.7px        ->  ends at 84.7px
       .step-desc       starts 20px below the mark (margin-top's floor)

   Two separate harms:

     - the arrow pokes ~9px BELOW the strip. The colour behind it ends and
       it looks like it is dangling in empty space.
     - the strip itself goes 31px below the mark but the description starts
       at 20px, so the colour lands behind its first line. `z-index: -2`
       keeps it behind the text, and `.step-desc` has no background of its
       own - so the letters simply cannot be read.

   Neither problem occurs on desktop. There the clamps are on their vw values
   (strip 218px, arrow 125-184px - the arrow fully inside), and
   `.step-mark`'s `margin-left: -184.48px` (custom.css:2244) puts the whole
   pair OUTSIDE the content column in the left gutter, so it never meets any
   text.

   The position of both stays the BASE one - strip at the slab's
   bottom-left, arrow inside it, exactly as on desktop. Only two measurements
   are corrected:

   1. The strip's floor 92px. That fully covers the arrow's 84.7px, and goes
      below the mark in the same proportion as on desktop (desktop: 126px
      below, mark 106px tall = 1.19x; here 53px below, mark 45px tall). The
      clamp's upper vw value is untouched - above 767 everything is as it
      was.

   2. The description starts BELOW the strip. On desktop it sits to the RIGHT
      of the strip, but at 430px there is no room left for it - the text
      would be down to 330px. So here it goes below the strip, at full width.

   The strip runs from 6px to 98px, the mark is 45px - i.e. 53px below. 64px
   is above that, with 11px of breathing room.

   NOT a margin on `.acc-panel` - despite the closed accordion's
   `max-height: 0` the margin would remain outside and every closed step
   would show an empty 64px box beneath it. So on the first line INSIDE the
   panel, which is hidden by `overflow: hidden` when closed.
*/
@media (max-width: 767px) {
  .step-mark::after { height: clamp(92px, 11.3583vw, 218.08px); }

  .step-mark + .step-desc,
  .step-mark + .acc-panel .crit-lead { margin-top: 64px; }

  /*
     All slabs the same width.

     The base has `width: fit-content` (custom.css:2242) - a slab is only as
     wide as its text. On desktop that looks fine because at the large font
     every slab gets fairly long and they all look roughly equal. On mobile
     the text is small, so each step ends up with its own different width:

         1. Entries Open        short
         2. Eligibility Review  long
         3. Shortlisting        shorter still

     Six coloured slabs of different lengths stacked one below the other -
     the list does not look straight, it looks broken.

     With `width: auto` the `h3` takes the full space like a block, so they
     all become equal. `min-width` does nothing here - custom.css:2706 has
     already set it to 0.

     `::before` (`inset: 0`) grows along with it by itself, so the coloured
     slab is full width too. `::after` and the arrow are measured from the
     left edge - they are unaffected.
  */
  .step-mark { width: auto; }
}