/* scale.css — THE VIEWPORT-HEIGHT AXIS. Loaded LAST on every page.
   ============================================================================

   THE FAULT THIS FIXES
   The site scales on ONE axis: width. And it stops scaling early — 71% of the
   559 clamps in this codebase saturate between 1100px and 1400px, --maxw is a
   flat 1280px, and the header is a flat ~170px. Measured, every section below
   the hero is byte-identical in height at 1440 and at 2560.

   That is why one design reads three ways:

     viewport            header     "Our vision" photo    home page
     1440x609  (13")     27.8%      0.99 screenfuls       20.1 screens
     1512x826  (14")     20.5%      0.73 screenfuls       15.1 screens
     2560x1284 (27")     13.3%      0.47 screenfuls       10.0 screens

   A 13" laptop is not merely narrower than a 27" — it is HALF AS TALL. The
   stylesheet never knew that, so the client got the 27" layout in 47% of the
   space and had to scroll through a portrait photo to read one paragraph.

   THE IDIOM
   Every rule here is the same shape:

       <property>: min(<exactly what the site computes today>, <N>vh)

   which means: on a tall screen the existing value always wins and NOTHING
   changes; on a short screen the height ceiling takes over and the design
   scales down proportionally. It is continuous — no breakpoint to jump at —
   and it is provably a no-op above the crossover height noted on each rule.

   The ceilings are chosen so 1512x826 and 2560x1284 (George's two screens, and
   the approved rendering) stay untouched wherever that was achievable. Where it
   was not — the portrait media, which is 600px tall and cannot both stay 600px
   and fit a 609px screen — the 14" gives up a little and the comment says so.

   WHY A SEPARATE FILE
   Every change is here, nothing else was edited, so the whole behaviour reverts
   by deleting one file and one <link>. It also keeps this lane clear of the
   stylesheets other sessions are editing live.

   ⚠ MUST LOAD LAST. Several pages carry an inline <style> block after their
   <link>s, and an inline block beats an equal-specificity rule on document
   order. Where that happens the selector below is prefixed with `html` to win
   on specificity instead; those places are marked ⚠ SPECIFICITY.

   ⚠ Tune the ceilings here, not at the call sites.                            */

:root{
  /* A headline past ~13% of the screen has stopped being a headline and become
     a wall. 13.4vh crosses 110px at 821px tall, so the 14" (826) keeps its 110. */
  --cap-h1:13.4vh;
  /* Media gets a ceiling PER BLOCK, not one shared number: each block's ceiling is
     set just above its own current maximum divided by 826px, so the 14" lands
     exactly on today's value and only shorter screens scale. A single shared vh
     figure cannot do that, because the three blocks max out at 400 / 600 / 640px.
     Crossovers: 49vh→400px @816 · 73vh→600px @822 · 78vh→640px @821. */
  --cap-vision:49vh;
  --cap-split:73vh;
  --cap-splitlegacy:78vh;
  /* Section rhythm. --band is 92px today and crosses at 821px tall. */
  --cap-band:11.2vh;
}

/* ── 1 · SECTION RHYTHM ──────────────────────────────────────────────────────
   --band drives every section seam on the r7 service pages, /about, /team,
   /why-bulgaria and the /lp set (2x--band = one seam). One definition, so the
   continuous min() is safe here. No-op above 821px tall. */
:root{ --band:min(clamp(3.5rem,6.4vw,5.75rem), var(--cap-band)); }

/* --sec cannot take the same treatment: it is forked. v21.css pins it to a flat
   80px on 14 pages (George's seven-round homepage tuning) while the other 30
   inherit zara.css's clamp, which reaches 160px. A blanket min() would RAISE it
   to 160 on the pages he deliberately capped at 80.
   So it is stepped down only on short screens, and only ever downward: 5rem is
   already the v21 value, so those 14 pages do not move until the vh term bites.
   Above 820px tall this block does not exist. */
@media (min-width:1024px) and (max-height:820px){
  :root{ --sec:min(5rem, 11.5vh); }
}

/* ── 2 · THE HERO'S CLEARANCE UNDER THE FIXED HEADER ─────────────────────────
   --chrome-clear is the top padding all 17 heroes read. It reaches 248px, which
   on a 609px screen is 41% of the viewport spent before the H1 starts.
   The max() floor is load-bearing: the header is position:fixed, so dropping
   below its height puts the bar on top of the H1. Keeping --chrome-h + 1.5rem
   as the floor means the clearance can shrink but can never collide.
   31vh crosses 248px at 800px tall → 826 and 1284 keep the full 248px. */
:root{
  --chrome-clear:max(
    calc(var(--chrome-h) + 1.5rem),
    min(clamp(12rem,17vw,15.5rem), 31vh)
  );
}

/* ── 3 · MEDIA ───────────────────────────────────────────────────────────────
   Not one image or video on this site was constrained by viewport height, and
   only three of 559 clamps mention vh at all. These are the caps.

   ⚠ EACH RULE IS SCOPED TO ITS OWN BLOCK'S DESKTOP BREAKPOINT, and they differ:
   900px for .v21-vision, 901px for .p21-split, 861px for .split. Using one shared
   760px floor reaches DOWN into the separately-tuned single-column layouts — and
   for .p21-split that is not merely a change but an ENLARGEMENT, because its
   mobile rule caps min-height at 380px while the desktop clamp floors at 420px.
   The phone and tablet layouts are out of scope for this round and must not move. */
@media (min-width:900px){

  /* 3a · "OUR VISION" — the reported bug.
     v21.css:197-199 sizes .vimg by WIDTH only (clamp(280px,30vw,400px)) and
     leaves the <img> at height:auto, so the height is nothing but the file's
     own 2:3 ratio: 400px wide = 600px tall, frozen from 1333px of width upward.
     On the client's 1440x609 that is 0.99 screenfuls — the photo alone is her
     whole screen, so "Our vision" scrolls past above it and the text below it.
     It is also the ONLY portrait on the site with neither a crop nor a cap;
     every other one uses aspect-ratio + object-fit or is taken out of flow.

     Capping the WIDTH (not the height) is what keeps the photo undistorted and
     uncropped, which is how the client asked for it — height follows at x1.5.
     49vh of width => 73vh of picture, and it crosses 400px at 816px tall, so
     both approved screens keep the photo at exactly 400x600.
     ⚠ A lower ceiling buys nothing here: at 1440x609 the text column is ~519px,
     so once the photo drops under that the ROW is text-driven and the section
     stops shrinking. 49vh puts it at 298x447 — already below the text — so the
     block measures the same as it would at 44vh while leaving the 14" alone. */
  .v21-vision .vimg{ width:min(clamp(280px,30vw,400px), var(--cap-vision)); }
  /* Reserve the box before the file decodes — the width is now viewport-derived,
     so the intrinsic w/h attributes alone no longer settle the layout early. */
  .v21-vision .vimg img{ aspect-ratio:2/3; height:auto; }
}

/* 3b · SPLIT BANDS — the photo-beside-text rows on /about, /team, /services,
   /why-bulgaria, the 7 service pages and the 3 /lp pages.
   min-height:clamp(420px,44vw,600px) is a WIDTH clamp, so it sits at 600px from
   1364px wide upward with no idea how tall the screen is. The image is already
   position:absolute + object-fit:cover (fixed 2026-07-24), so a smaller band
   simply crops a little more — nothing distorts, nothing moves.
   73vh crosses 600px at 822px tall, so the 14" keeps the full 600.
   ⚠ 901px, matching p21.css's own max-width:900px mobile rule. Below that the
   band is capped at 380px and this clamp FLOORS at 420px, so reaching down there
   would enlarge it.
   ⚠ This ceiling only governs bands where MIN-HEIGHT sets the height. Where the
   text column is longer the band stays text-driven and this changes nothing —
   /about and /services are in that group, their copy is simply long. */
@media (min-width:901px){
  .p21-split .p21-media{ min-height:min(clamp(420px,44vw,600px), var(--cap-split)); }
}

/* 3c · The older .split band — the homepage tax section and the cities carousel.
   78vh crosses 640px at 821px tall. 861px matches lab.css's max-width:860px. */
@media (min-width:861px){
  .split .media{ min-height:min(clamp(360px,46vw,640px), var(--cap-splitlegacy)); }
}

/* 3d · BLOG ARTICLE FIGURES — the worst absolute offenders on the site.
   .p21-article-body is 1100px wide and media is explicitly opted OUT of the
   44rem prose measure, while .p21-article-img / figure img are width:100% +
   height:auto. A 534x800 portrait figure therefore renders 1100px wide and
   ~1647px TALL — 2.7 screenfuls of one photograph on a 13".

   width:auto is deliberate. Pairing max-height with width:100% would clamp the
   height while the width stayed 100%, i.e. stretch the picture. Letting the
   intrinsic width stand and capping BOTH axes keeps every ratio exact, and stops
   a 534px-wide file being blown up to 1100px, which is why those figures look
   soft today.

   ⚠ DELIBERATELY BEHIND A HEIGHT QUERY. Both effects change the blog at 826px
   and 1284px too, and this round's contract is that the approved screens render
   identically. So it engages only below 820px of viewport.
   ▶ If the upscaling should stop everywhere — it is a real defect, worth a
     separate decision — lift these four declarations out of the media query.
     Nothing else needs to change. */
@media (max-height:820px){
  .p21-article-img,
  .p21-article-body figure img{
    width:auto; height:auto;
    max-width:100%; max-height:78vh;
    margin-inline:auto;
  }
}

/* ── 4 · TYPE ────────────────────────────────────────────────────────────────
   The headline scale saturates at ~1310px and never moves again, so the same
   110px headline sits on a 609px screen and on a 1284px one — 18% of her
   viewport against 8.6% of his, for one line of text.

   ⚠ A CEILING MUST NEVER ENLARGE. CSS cannot express "min(whatever this element
   already computes, N vh)" — restating the property replaces the value outright.
   So a blanket `.p21-hero h1` rule would have RAISED /team and the three /lp
   heroes from their deliberate 80px to 110px. Every selector below is therefore
   matched to a rule that actually carries the 6.875rem/110px clamp, and nothing
   else is touched. Heroes already at or below 80px are left alone: 13.4vh does
   not cross 80px until the viewport is under 597px tall, which is off the map.

   ⚠ SPECIFICITY: the 7 service pages declare .cf21-hero h1 in an inline <style>
   that comes after every <link>, and c3.css uses a two-class selector. `html`
   adds an element to outrank both without inventing an ID or !important. */
@media (min-width:760px){
  /* zara.css:53 — the base h1, and the only rule on pages with no hero override. */
  html h1{ font-size:min(clamp(2.8rem,8.4vw,6.875rem), var(--cap-h1)); }
  /* The 7 r7 service pages (bpo carries a lower floor, same 6.875rem ceiling). */
  html .cf21-hero h1{ font-size:min(clamp(2.8rem,8.4vw,6.875rem), var(--cap-h1)); }
  /* /contact — c3.css:16, two classes, so it needs the extra element to lose. */
  html .p21-hero.c3-hero h1{ font-size:min(clamp(2.8rem,8.4vw,6.875rem), var(--cap-h1)); }
  /* /lp/freelancers — the one /lp hero still on the full 110px clamp.
     (/why-bulgaria needs no line of its own: it reuses .cf21-hero above.) */
  html .lpr21-hero h1{ font-size:min(clamp(2.8rem,8.4vw,6.875rem), var(--cap-h1)); }
}

/* ⚠ .display is NOT capped, on purpose. The verify gate caught it: a bare
   `html .display` rule outranks the `h2.display` variants that run at 54px on
   the homepage, so the ceiling flattened them to 52px on BOTH approved screens.
   The scale it governs (52px) was never the complaint — the 110px h1 was — so
   the rule was withdrawn rather than given a specificity arms race. */

/* ── 5 · THE FIXED HEADER ON A SHORT SCREEN ──────────────────────────────────
   RETIRED 2026-07-28 (client image round). This block used to step --brand-w down
   behind max-height walls (542→430/380, then 330→262/231 with the vector lockup)
   because chrome.css derived --nav-line1 — and so the whole bar — from the mark's
   height, and a fixed 150-170px bar is 28% of the client's 609px screen.
   chrome.css no longer derives anything from the mark: line 1 is a fixed 77px,
   the bar a fixed 143px, and the lockup hangs across both rows without pushing
   either (her 2026-07-28 mock draws it exactly so). Shrinking the mark on short
   screens now buys zero bar height and only makes the logo she asked to see
   bigger, smaller — so the overrides are gone, not walled. The bar is 10px
   SHORTER than the old short-screen floor (~153px) ever allowed. */