/* ══════════════════════════════════════════════════════════════════════
 *  CFIN TRADING EXCELLENCE · Project Amber                       © 2026 CFIN
 *  Proprietary & confidential — see repository NOTICE.           www.cfin.be
 * ══════════════════════════════════════════════════════════════════════
 *
 * public-subpages.css — corrections for the PUBLIC SUBPAGES: the four legal
 * documents linked from the landing-page footer (/disclaimer, /privacy,
 * /cookies, /acceptable-use — plus /terms, which is an alias serving the
 * disclaimer) and /performance.
 *
 * Loaded LAST, after legal.min.css / perf-page.css, so it overrides without
 * editing those files. Two reasons that matters here:
 *
 *   1. legal.min.css is a BUILT artifact. `scripts/minify-assets.sh` records
 *      that static/css/legal.css once had 178 lines living ONLY inside
 *      legal.css.br — a blind rebuild deletes published CSS from a legally
 *      binding page. Adding a new file needs no rebuild of either.
 *   2. These pages are shared with five other agents' work. One file with one
 *      owner is reviewable and revertable on its own.
 *
 * ⚠ LAYOUT ONLY. Nothing here changes a word, a date or a version string.
 * The legal documents' consent records key on `content_hash`, so
 * disclaimer.html's "Last Updated" stamp, `legal_updated_iso` and
 * core/legal_versions.TERMS_VERSION must always move together. Typography,
 * spacing and responsiveness are safe to change; text is not.
 *
 * Every rule below is a MEASURED defect. Measurements were taken against
 * production (www.cfin.be), real viewports, both colour schemes, at
 * 320/390/414/768/1024/1180/1280/1440/1920.
 * ────────────────────────────────────────────────────────────────────── */


/* ── 1 · THE BACK-TO-TOP BUTTON WAS TRANSLUCENT OVER RUNNING LEGAL TEXT ─────
 *
 * `.legal-back-top` (legal.css) is a 48x48 fixed FAB pinned bottom-right —
 * `bottom: 72px` below 600px, `clamp(16px,3vw,28px)` above it. It is painted
 * with the GLASS token plus a second alpha on top:
 *
 *     background: var(--glass-bg);   /· rgba(255,255,255,.80) light
 *                                       rgba(44,44,46,.72)   dark   ·/
 *     opacity: .92;
 *
 * so the effective alpha over whatever is behind it is ~0.74 (light) / ~0.66
 * (dark). The legal container is nearly full-bleed on a phone, and the FAB
 * sits inside the text column, so body copy renders THROUGH it.
 *
 * MEASURED on production, /cookies at 390x844 dark, scrolled to y=2500: the
 * FAB's box intersects the .legal-tldr paragraph "In brief — essential cookies
 * always run so the site works…" by 31 x 48 px, and the sentence is legible
 * through the button. Same on /disclaimer at 390x844 light (31 x 48 px, over
 * "Power outages, hardware failures, or infrastructure…").
 *
 * On a disclaimer this is not cosmetic: the words underneath are the risk
 * disclosures the page exists to deliver.
 *
 * The fix is the one legal.css ALREADY reached for two elements down, for the
 * identical reason — `.legal-tocbar` carries the comment "OPAQUE on purpose.
 * The glass token is ~5% alpha plus a blur, and content scrolling underneath
 * ghosted straight through the bar". `--bg-panel` is that opaque token. The
 * blur is kept for the rounded edge, and the button still reads as floating
 * because of its border and shadow — it simply stops being see-through.
 *
 * NOT MOVED, deliberately: reserving a gutter for the FAB would indent every
 * line of every legal page at every width to buy back 48px in one corner. An
 * opaque control that occludes cleanly is the normal mobile pattern; a
 * translucent one that half-shows the text is the defect. */
.legal-back-top {
    background: var(--bg-panel);
    opacity: 1;
}
.legal-back-top:hover {
    /* legal.css hovers to rgba(52,199,89,.12) — translucent again, and hover
       is a real state on tablets/desktop. Keep the accent tint but composite
       it over the opaque panel rather than over the prose. */
    background:
        linear-gradient(rgba(52, 199, 89, 0.12), rgba(52, 199, 89, 0.12)),
        var(--bg-panel);
    opacity: 1;
}


/* ── 2 · A WIDER SCREEN MADE THE LEGAL TEXT NARROWER ────────────────────────
 *
 * `.legal-container` is `max-width: min(900px, 100%)` at EVERY width. At
 * >=1180px `.legal-cols` becomes a grid and the sticky TOC rail
 * (`minmax(220px,260px)`) plus its gap (`clamp(24px,3vw,40px)`) are taken OUT
 * of that same 900px — so the rail is paid for by the prose.
 *
 * MEASURED on production, /disclaimer, first body paragraph, real character
 * advance (not the `ch` unit, which is the width of "0" and undercounts Inter
 * by ~11%):
 *
 *     viewport   paragraph   characters/line
 *     ────────────────────────────────────────
 *      390        324px       40
 *      768        648px       80   <- hits the 648px cap
 *     1024        648px       80
 *     1180        467px       58   <- rail appears, column collapses
 *     1440        462px       57
 *     1920        462px       57   <- 1458px of viewport unused
 *
 * Crossing 1180px costs the reader 29% of their line length, and it never
 * comes back: the document is exactly as narrow on a 1920px monitor as on a
 * 1180px laptop. Dragging a window WIDER making the text column NARROWER is
 * the kind of thing that reads as unfinished even to someone who could not say
 * why.
 *
 * The fix does not touch the cap, the rail or the grid — it just stops the
 * rail being funded out of the text. 1080px of container leaves
 * 1080 - 48 (gutters) - 260 (rail) - 40 (gap) - 72 (section padding) = 660px
 * for the paragraph, which the EXISTING 648px max-width then caps. So >=1180px
 * now renders the same 648px / 80-character line as 768-1179px does, and the
 * rail is drawn in space that was previously empty margin.
 *
 * Why not simply widen to fill 1920: because 648px is already at the top of
 * the comfortable measure range. The goal is to stop the REGRESSION, not to
 * re-typeset a legal document. */
@media (min-width: 1180px) {
    .legal-container {
        max-width: min(1080px, 100%);
    }
}


/* ── 3 · FIND-A-CLAUSE SEARCH ───────────────────────────────────────────────
 *
 * Styling for the UI that static/js/legal-search.js injects at the top of
 * `#legal-toc` on the four legal documents and on /faq. Nothing here has a
 * counterpart in any template: if the script does not run, none of these
 * selectors ever match and the table of contents renders exactly as before.
 *
 * WHY THE SEARCH LIVES INSIDE THE TOC CARD. The rail is `position: sticky` at
 * >=1180px and a plain block below it, and the TOC is the one element on the
 * page whose job is already "get me to a clause". Putting search anywhere else
 * would create a second navigation affordance competing with the first at
 * every width; putting it inside means it inherits the rail's stickiness for
 * free on desktop and sits exactly where the reader already looks on mobile.
 *
 * The results REPLACE `.legal-toc-list` rather than stacking above it (the
 * script sets `hidden` on the list). Stacked, a 6-result list plus a 19-entry
 * TOC is ~1,100px inside a 260px-wide sticky rail — the results the visitor
 * asked for would open below the fold while the list they did not ask for
 * holds the top of the card.
 *
 * ⚠ LAYOUT ONLY, like the rest of this file. Search changes how the documents
 * are NAVIGATED. It does not add, remove or restate a single word of them, and
 * the index it queries is read out of the rendered page at runtime, so it
 * cannot describe text the page does not contain. */

.legal-search {
    margin-bottom: 16px;
}

/* The label is visible, not a screen-reader-only string. On a legal page the
   input has to say what it searches BEFORE it is used — a bare magnifier in a
   document set this size reads as "search this page", which is exactly the
   wrong expectation given it searches all five. */
.legal-search-label {
    display: block;
    font-size: 14px;
    font-weight: 600;
    color: var(--text-dim);
    text-transform: uppercase;
    letter-spacing: 1px;
    margin-bottom: 10px;
}

.legal-search-field {
    position: relative;
    display: flex;
    align-items: center;
}

.legal-search-icon {
    position: absolute;
    left: 12px;
    width: 18px;
    height: 18px;
    color: var(--text-dim);
    pointer-events: none;   /* the icon must never eat a tap meant for the field */
}

/* 44px minimum. `min-height` rather than a fixed height so a locale whose
   placeholder wraps grows the control instead of clipping it — the previous
   pass took these pages from 268 sub-44px targets to 0 and nothing added here
   may reopen that. `font-size: 16px` is load-bearing on iOS Safari, which
   zooms the whole viewport on focus for anything smaller and leaves the reader
   in a horizontally scrolled legal document. */
.legal-search-input {
    width: 100%;
    min-height: 44px;
    /* 34px each side, trimmed from 38/40 (2026-08-24). The icon is 18px at
       left:12px so it ends at 30px, and the clear button needs ~28px — 34
       clears both and returns 10px to a content box that was 53px short. */
    padding: 10px 34px 10px 34px;
    font-family: inherit;
    font-size: 16px;
    color: var(--text-main, var(--text-sub));
    background: var(--bg-panel);
    border: 1px solid var(--glass-border);
    border-radius: var(--radius-sm);
    transition: border-color var(--transition), box-shadow var(--transition);
}

/* ⚠ THE PLACEHOLDER GETS ITS OWN SMALLER SIZE, AND THE INPUT KEEPS 16px.
   MEASURED 2026-08-24 at 1440 AND 2560 (identical, because `.legal-toc` is a
   fixed 260px rail — a wider viewport buys nothing): input 202px, padding
   38+40=78px, so a 124px content box for a placeholder needing 177px at 16px.
   It rendered as "Search all docu" — 31% clipped, with no ellipsis.
   ⛔ Do NOT fix this by lowering `.legal-search-input`'s own `font-size`. 16px
   there is load-bearing on iOS Safari, which zooms the whole viewport on focus
   for anything smaller and leaves the reader in a horizontally scrolled legal
   document. Sizing `::placeholder` alone does not affect that behaviour, which
   keys off the input's computed size.
   ⛔ And not by `min-height` either: the note above reasons that a locale whose
   placeholder wraps grows the control instead of clipping — but an `<input>`
   placeholder NEVER wraps, so that guard cannot do anything for this. Fixed
   here, where the overflow actually is.
   `ellipsis` is the net for locales whose string is longer still (de/nl run
   long), so the worst case becomes a visible "…" rather than a hard cut. */
.legal-search-input::placeholder {
    color: var(--text-dim);
    opacity: 1;   /* Firefox dims placeholders a second time by default */
    font-size: 12px;
    text-overflow: ellipsis;
}

.legal-search-input:focus-visible,
.legal-search-input:focus {
    outline: none;                      /* replaced, not removed — see below */
    border-color: var(--profit);
    box-shadow: 0 0 0 3px rgba(52, 199, 89, 0.25);
}

/* The browser's own clear button, where it exists, plus ours. Chrome and
   Safari draw a decoration inside type=search that collides with the button
   below; suppressing it leaves exactly one clear affordance at every width. */
.legal-search-input::-webkit-search-decoration,
.legal-search-input::-webkit-search-cancel-button {
    -webkit-appearance: none;
    appearance: none;
}

.legal-search-clear {
    position: absolute;
    right: 0;
    /* 44x44 hit area, but the glyph inside is small — the target is the
       padding, not the character. */
    width: 44px;
    height: 44px;
    display: flex;
    align-items: center;
    justify-content: center;
    font-size: 20px;
    line-height: 1;
    color: var(--text-dim);
    background: none;
    border: none;
    border-radius: var(--radius-sm);
    cursor: pointer;
    transition: color var(--transition), background-color var(--transition);
}

.legal-search-clear:hover {
    color: var(--profit);
    background: rgba(52, 199, 89, 0.08);
}

.legal-search-status {
    margin: 10px 0 0;
    font-size: 13px;
    color: var(--text-dim);
    min-height: 0;
}
/* Empty status must not reserve a 13px strip above the TOC on every page load,
   so it collapses when the script has written nothing into it. */
.legal-search-status:empty {
    margin: 0;
}

.legal-search-group {
    margin: 14px 0 8px;
    font-size: 12px;
    font-weight: 600;
    color: var(--text-dim);
    text-transform: uppercase;
    letter-spacing: 1px;
}
.legal-search-group:first-child {
    margin-top: 4px;
}

.legal-search-list {
    list-style: none;
    padding: 0;
    margin: 0;
    display: grid;
    gap: 6px;
}

/* Mirrors `.legal-toc-list a` — same 44px floor, same radius, same hover — so
   the results read as the table of contents answering a question rather than
   as a different component that happens to be in the same box. Two lines of
   text put the real height around 70px; the floor is the guarantee for the
   single-line case. */
.legal-search-result {
    display: block;
    min-height: 44px;
    padding: 10px 12px;
    border-radius: var(--radius-sm);
    color: var(--text-sub);
    text-decoration: none;
    transition: color var(--transition), background-color var(--transition);
}

.legal-search-result:hover,
.legal-search-result:focus-visible {
    background: rgba(52, 199, 89, 0.08);
    color: var(--profit);
}

/* Focus must be VISIBLE here specifically: the arrow keys move focus through
   this list without moving the caret, so an invisible ring means a keyboard
   visitor cannot tell which result they are on. */
.legal-search-result:focus-visible {
    outline: 2px solid var(--profit);
    outline-offset: 2px;
}

.legal-search-result-title {
    display: block;
    font-size: 14px;
    font-weight: 600;
}

.legal-search-result-snippet {
    display: block;
    margin-top: 3px;
    font-size: 12.5px;
    line-height: 1.5;
    color: var(--text-dim);
}

/* The matched words. A tinted background rather than the browser default
   yellow-on-black, which fails contrast in dark mode and is the one colour on
   these pages that belongs to no token. */
.legal-search-hit {
    background: rgba(52, 199, 89, 0.22);
    color: inherit;
    border-radius: 3px;
    padding: 0 2px;
}

.legal-search-empty {
    margin: 4px 0 0;
    font-size: 14px;
    color: var(--text-dim);
}

/* At >=1180px the rail is sticky and its own height is the viewport. A long
   result list has to scroll inside the rail, not push the card past the bottom
   of the screen where the last results become unreachable while the page
   behind them is pinned. */
@media (min-width: 1180px) {
    .legal-search-results {
        max-height: min(52vh, 520px);
        overflow-y: auto;
        overscroll-behavior: contain;
    }
}


/* ── 4 · THE FAQ ACCORDION (/faq) ───────────────────────────────────────────
 *
 * templates/faq.html builds each Q&A as a native <details>/<summary>. The
 * landing page's accordion is a button + aria-expanded + a CSS-collapsed div,
 * and it shipped 3,996 characters of collapsed answer text still carrying
 * `visibility: visible` with no `aria-hidden` — announced to screen readers,
 * and a Tab walk stopped three times inside content nobody could see. A closed
 * <details> is removed from the accessibility tree AND from the tab order by
 * the browser, with no ARIA state to keep in sync.
 *
 * ⛔⛔ NEVER GIVE `.faq-entry-a` A `display` VALUE — NOT EVEN `display: block`.
 * The UA stylesheet hides the non-summary children of a closed <details>. Any
 * author `display` on that child WINS over the UA rule, and the answer becomes
 * permanently visible and permanently tabbable — the landing-page defect,
 * rebuilt by hand. Padding, margin, colour and border are all safe; `display`
 * is not. The same warning is in templates/faq.html's header comment.
 *
 * The categories reuse `.legal-section` for their card, and carry NO id — the
 * anchor sits on the <h2> instead. That is deliberate: legal-search.js indexes
 * `.legal-section[id]`, so an id here would index the whole category on top of
 * each of its questions and every result would appear twice. */

.faq-cat .legal-section-content > .faq-entry + .faq-entry {
    margin-top: 10px;
}

.faq-entry {
    border: 1px solid var(--glass-border);
    border-radius: var(--radius-sm);
    background: rgba(255, 255, 255, 0.02);
    transition: border-color var(--transition), background-color var(--transition);
}
:root.light .faq-entry {
    background: rgba(0, 0, 0, 0.02);
}

.faq-entry[open] {
    border-color: rgba(52, 199, 89, 0.35);
}

/* The question. 44px floor via padding + min-height, and `list-style: none`
   plus the ::-webkit-details-marker reset so the default triangle does not
   fight the chevron drawn below. `cursor: pointer` because a <summary> does
   not get one by default in every engine. */
.faq-entry-q {
    display: flex;
    align-items: center;
    gap: 12px;
    min-height: 44px;
    padding: 12px 14px;
    font-size: 15px;
    font-weight: 600;
    line-height: 1.45;
    color: var(--text-main, var(--text-sub));
    cursor: pointer;
    list-style: none;
    border-radius: var(--radius-sm);
}
.faq-entry-q::-webkit-details-marker { display: none; }
.faq-entry-q::marker { content: ''; }

.faq-entry-q:hover {
    color: var(--profit);
}

/* Focus must be visible on the SUMMARY specifically — it is the only focusable
   part of a closed entry, so an invisible ring means a keyboard visitor cannot
   tell which question they are on. */
.faq-entry-q:focus-visible {
    outline: 2px solid var(--profit);
    outline-offset: 2px;
}

/* The chevron, drawn as a pseudo-element on the summary so it needs no markup
   and cannot be tabbed to. Rotates when the entry opens. */
.faq-entry-q::after {
    content: '';
    flex: 0 0 auto;
    margin-left: auto;
    width: 9px;
    height: 9px;
    border-right: 2px solid currentColor;
    border-bottom: 2px solid currentColor;
    transform: rotate(45deg) translate(-2px, -2px);
    transition: transform var(--transition);
    opacity: 0.6;
}
.faq-entry[open] > .faq-entry-q::after {
    transform: rotate(-135deg) translate(-2px, -2px);
    opacity: 1;
}
@media (prefers-reduced-motion: reduce) {
    .faq-entry-q::after { transition: none; }
}

/* ⛔ NO `display` HERE. See the block comment above. */
.faq-entry-a {
    padding: 0 14px 14px;
    border-top: 1px solid var(--glass-border);
    margin-top: 2px;
    padding-top: 12px;
}

.faq-entry-a p {
    margin: 0 0 10px;
}
.faq-entry-a p:last-child {
    margin-bottom: 0;
}
.faq-entry-a ul {
    margin: 0 0 10px;
    padding-left: 20px;
}
.faq-entry-a li {
    margin-bottom: 6px;
}

/* The provenance line. Every answer carries one, and it is the thing that makes
   this page a summary rather than a second set of terms — it is styled to be
   quiet but never faint enough to fail contrast, which is why it uses the same
   --text-dim the TOC titles use rather than a one-off alpha. */
.faq-source {
    font-size: 12.5px;
    color: var(--text-dim);
    border-top: 1px dashed var(--glass-border);
    padding-top: 8px;
    margin-top: 12px !important;
}
.faq-source a {
    color: inherit;
    text-decoration: underline;
    text-underline-offset: 2px;
    /* 44px is impossible inline inside running text without breaking the line
       box, and these are supplementary provenance links sitting beside a
       full-size control set. Give them real padding so the target is bigger
       than the glyph without disturbing the line. */
    padding: 4px 2px;
}
.faq-source a:hover {
    color: var(--profit);
}

/* The precedence notice is the sentence that makes the page safe to publish.
   It must never read as decoration, so it gets the full highlight treatment
   and a little more breathing room than a normal callout. */
.faq-precedence {
    margin-bottom: 16px;
}

/* Anchors live on the <h2>, so the sticky section bar (~48px) plus a little
   air has to be reserved or a jump from the TOC lands with the heading hidden
   underneath the bar. Only below 1180px, where the bar exists. */
.faq-cat .legal-section-title[id] {
    scroll-margin-top: 76px;
}
@media (min-width: 1180px) {
    .faq-cat .legal-section-title[id] {
        scroll-margin-top: 24px;
    }
}

/* Arriving at a specific question from search or a shared link: mark it, so
   the reader's eye lands on the answer rather than somewhere in the card. */
.faq-entry:target {
    border-color: var(--profit);
    box-shadow: 0 0 0 3px rgba(52, 199, 89, 0.18);
}


/* ── 5 · [hidden] MUST BEAT display — THE BUG THE RENDER CAUGHT ─────────────
 *
 * legal-search.js hides two elements by setting the `hidden` PROPERTY: the ×
 * clear button while the field is empty, and `.legal-toc-list` while a query is
 * active (results take the slot; see §3).
 *
 * Neither worked, and the reasoning behind them was correct — the render was
 * not. The UA stylesheet's `[hidden] { display: none }` is specificity (0,1,0),
 * and so is a class selector. On a TIE the LATER stylesheet wins, and every
 * author stylesheet is later than the UA's. So:
 *
 *     .legal-toc-list   { display: grid }   (legal.css)  BEATS  [hidden]
 *     .legal-search-clear { display: flex } (this file)  BEATS  [hidden]
 *
 * MEASURED on the staging rig, /disclaimer at 1440x900 dark, before this block:
 * `clear_hidden_initially: false` — the × sat in an empty field on first paint;
 * and `toc_hidden_while_searching: false` — searching "refund" returned 26
 * results that rendered BELOW a still-visible 19-entry table of contents,
 * which is the exact stacking §3 says must not happen.
 *
 * `.legal-search-results` was never affected: nothing here gives it a
 * `display`, so `[hidden]` was unopposed — which is precisely why the other two
 * failed silently while the third worked. Setting `hidden` in JS is only as
 * reliable as the CSS lets it be.
 *
 * Fixed with an explicit attribute rule per element rather than a blanket
 * `[hidden] { display: none !important }`: this file is loaded on pages owned
 * by other agents' work, and a global !important on `hidden` would change the
 * behaviour of every element on five templates to fix two. */
.legal-search-clear[hidden] {
    display: none;
}
.legal-toc .legal-toc-list[hidden] {
    display: none;
}

/* Same tie-break as above: `.legal-toc-title` has no author `display`, so
   `[hidden]` would in fact win here — the rule is written anyway so that a
   future `display` on that class cannot silently resurrect a heading reading
   "Table of Contents" over a list of search results. */
.legal-toc .legal-toc-title[hidden] {
    display: none;
}


/* ── 6 · 44px HIT AREA FOR THE TOP-LEVEL NOTICES ON /faq ────────────────────
 *
 * legal.css §"44px HIT AREA FOR INLINE PROSE LINKS" already solves this, with
 * a measured `::after { position: absolute; inset: -13px -4px }` — 13px and not
 * 12px, derived from the SMALLEST line box on the page (18px + 2x13 = 44). But
 * it is scoped to `.legal-section-content a`, and /faq puts two callouts —
 * the precedence notice and the trading-risk notice — ABOVE the table of
 * contents, as direct children of `.legal-container`. Those are outside the
 * scope, so their links kept their raw 20px line box.
 *
 * MEASURED, /faq, run legal-after: 'Privacy Policy' 106x20 and
 * 'Acceptable Use Policy' 169x20 failed on HEIGHT in 8 and 4 of 16 cells
 * respectively, alongside 'Cookie Policy', 'Risk Disclosure' and
 * 'Disclaimer & Terms' at the narrow widths where those sentences wrap.
 *
 * This is the SAME technique with the SAME numbers, extended to the same kind
 * of link in a place the original selector could not reach. It is deliberately
 * NOT a new approach: two different hit-area recipes on one page is how the
 * 13px-vs-12px lesson gets re-learned.
 *
 * Scoped with the CHILD combinator so it touches only the two callouts that
 * sit outside a section. `.legal-highlight` blocks inside `.legal-section-content`
 * are already covered by legal.css, and matching them again here would stack a
 * second identical ::after on links across all five pages. */
.legal-container > .legal-highlight a {
    position: relative;
}
.legal-container > .legal-highlight a::after {
    content: "";
    position: absolute;
    inset: -13px -4px;
    /* No background, no border: a hit area, not a decoration. */
}


/* ── 8 · THE ACTIVE TOC LINK MISSED AA IN LIGHT MODE, BY 0.05 ───────────────
 *
 * `.legal-toc-list a.is-active` (legal.css:1188) paints `--profit` on a
 * `rgba(52, 199, 89, 0.12)` tint. MEASURED on production, /disclaimer, with a
 * routine self-validated against black-on-white = 21.00 and #767676-on-white =
 * 4.542:
 *
 *     light:  rgb(22,122,55) on a composited rgb(219,237,228)  ->  4.45 : 1
 *     dark:   rgb(82,202,116) on a composited rgb(45,63,51)    ->  5.40 : 1
 *
 * 14px at weight 600 is NOT "large text" under WCAG (that needs 18.66px bold or
 * 24px), so the bar is 4.5 and light misses it. Dark passes and is untouched.
 *
 * The fix lightens the TINT rather than darkening the text. `--profit` is the
 * product-wide sign token and is authoritative — a legal page's table of
 * contents is not the place to fork it, and forking it would create exactly the
 * kind of second copy of one fact that this codebase keeps being bitten by.
 * Lowering the wash raises the background luminance instead, which is the only
 * other term in the ratio.
 *
 * The active state stays legible as an affordance: it keeps its tint, its 600
 * weight and its accent-coloured number chip, so this trades a small amount of
 * fill density for a pass. */
:root.light .legal-toc-list a.is-active {
    background: rgba(52, 199, 89, 0.07);
}

/* ============================================================================
   MOBILE TAP TARGETS FOR INLINE PROSE LINKS (2026-08-29)
   ----------------------------------------------------------------------------
   MEASURED at 390x844 on the live pages, after scrolling each one fully:

       /faq              70 links at h=20   (mostly cross-references + mailto)
       /privacy          16 at h=15
       /disclaimer        5 at h=15
       /terms             5 at h=15
       /acceptable-use    5 at h=15
       /cookies           2 at h=15

   These are unclassed <a> in running prose — "Privacy Policy", "Cookie Policy",
   "Disclaimer & Terms", "support@cfin.be". WCAG 2.5.8 (AA) asks for 24px; a
   15px or 20px target fails it, and on the legal pages these links ARE the
   navigation between documents a reader is required to follow.

   ⚠ PADDING, NOT min-height. `min-height` does nothing on a non-replaced inline
     box, and `display:block`/`inline-flex` would break the sentence the link
     sits inside — these are mid-paragraph, unlike the landing page's CTAs which
     got inline-flex + 44px in landing.css. The negative margin keeps the line
     box from opening up, so paragraph rhythm is unchanged.
   ⚠ SCOPED TO PROSE CONTAINERS on purpose. A bare `a { padding-block }` would
     also hit the TOC list, the search hits and the category headers, all of
     which already size themselves and several of which are flex children where
     extra vertical padding shifts alignment.
   ⚠ 24px is the target, not 44px. AAA's 44px on an inline link would visibly
     loosen a legal document; AA is the right bar for text inside a paragraph,
     and the standalone CTAs on these pages already clear 44 on their own.
   ============================================================================ */
.legal-section-content p a,
.legal-section-content li a,
/* .legal-highlight holds the cross-document callouts on /faq — 4 links at h=20,
   the only ones on that page still under the AA floor. Its <p> is not inside
   .legal-section-content, so the selectors above did not reach it. */
.legal-highlight p a,
.legal-highlight a,
/* .legal-table cells on /privacy carry the contact addresses (6 links at h=20).
   A table cell is not prose, but the link inside it is still inline text and the
   same padding applies cleanly — a min-height here would fight the row height. */
.legal-table td a,
.legal-table th a,
.faq-entry-a a,
.faq-source a,
.beta-text-full a,
.cookie-policy-link a,
.cookie-policy-link {
    padding-block: 5px;
    margin-block: -5px;
}