/* ============================================================
   Picture mosaic — the grid. Ported from the mockup's `.proof__strip`
   (styles/lithography.css).

   SPLIT OF OWNERSHIP, and it is worth knowing before editing either half:

     core  →  grid-template-columns, and each tile's `grid-column/row: span N`
              (from `layout.columnCount` and the tiles' `style.layout`)
     here  →  the row height, the gap, the look, and every fold

   Core emits its rules on generated `.wp-container-*` / `.wp-container-content-*`
   classes, all of them (0,1,0), and whether they land before or after this sheet
   is not something a block can rely on. So specificity is used to make the
   outcome ORDER-INDEPENDENT in both directions:

     · the column fallback below is wrapped in `:where()` — (0,0,0) — so core
       ALWAYS wins when it is generating tracks, and the fallback only paints
       where core is not in the layout pipeline at all;
     · the folds are written `.vt-section .vt-mosaic` — (0,2,0) — so they always
       beat core, which is the point of a fold.

   Same trap-2 discipline the section skeleton follows, applied to a second
   source of truth rather than to load order alone.
   ============================================================ */
.vt-mosaic {
  list-style: none;
  margin: 0;
  padding: 0;
  /* Stated even though core's grid layout also sets it — see the fallback note
     above: a mosaic has to be a grid even where core is not generating one. */
  display: grid;
  /* Core never sets grid-auto-rows, so this is ours alone and needs no
     defending. It is what makes a mosaic a mosaic: every tile on shared tracks. */
  grid-auto-rows: var(--vt-mosaic-row, 210px);
  /* The row spans its column. Not optional: a section's content stack is a flex
     column with `align-items: flex-start`, so without this the grid collapses to
     a single min-content track. BLOCKS.md trap 9, and it has caught every
     full-width child of a section stack so far. */
  width: 100%;
}

/* (0,0,0): the tracks core would generate anyway, for the cases where it is not
   in the pipeline. Never fights core's own value. */
:where(.vt-mosaic) {
  grid-template-columns: repeat(var(--vt-mosaic-cols, 4), minmax(0, 1fr));
}

/* THE GAP NEEDS TWO SELECTORS, and it is the one thing here that cost a
   measurement to find. `gap: 14px` on `.vt-mosaic` (0,1,0) rendered as 24px:
   core applies `gap: var(--wp--style--block-gap)` to a grid layout, that
   variable resolves to the theme's 24px, and the rule doing it ties with ours on
   specificity — so which one wins depends on stylesheet order, which a block
   cannot rely on (BLOCKS.md trap 2, in its nastiest form: the loser is silent
   and the number is merely wrong rather than broken).

   `.vt-section .vt-mosaic` is (0,2,0) and covers every placement that exists
   today, since both blocks that allow a mosaic ARE sections.
   `.vt-mosaic.vt-mosaic` is the same specificity by repetition and covers a
   mosaic with no section ancestor. Nothing renders one that way right now — the
   print view skips section containers, but its handler does not pick this section
   up as a part — so the second selector is a cheap guard rather than a fix for an
   observed bug. Keep it: the alternative is this number being silently wrong the
   first time a mosaic renders outside a section. */
.vt-section .vt-mosaic,
.vt-mosaic.vt-mosaic {
  gap: 14px;
}

/* Three row heights rather than a free number: a mosaic is tiles lining up on
   shared tracks, and an arbitrary pixel value is how that alignment gets lost
   one page at a time. `m` is the mockup's 210px. */
.vt-mosaic--rows-s { --vt-mosaic-row: 160px; }
.vt-mosaic--rows-m { --vt-mosaic-row: 210px; }
.vt-mosaic--rows-l { --vt-mosaic-row: 280px; }

/* THE DECLARED GRID (the slot model). A mosaic with a fixed row count states
   its rows up front, so a cell nothing occupies still EXISTS — as a droppable
   slot in the editor and as a deliberate hole on the page. The count arrives
   as a custom property (render.php / the canvas), the same two-selector
   discipline as the gap above. Without the class, rows stay implicit
   (grid-auto-rows) and the grid grows with its content — every mosaic saved
   before the slot model renders exactly as it always did. */
.vt-section .vt-mosaic--fixed,
.vt-mosaic--fixed.vt-mosaic {
  grid-template-rows: repeat(var(--vt-mosaic-rowcount, 2), var(--vt-mosaic-row, 210px));
}

/* ------------------------------------------------------------
   The folds — the mockup's own two steps, as container queries so the editor
   canvas gets them too. `@container vt-section` also guarantees the `.vt-section`
   ancestor these selectors name: a container query only matches inside a named
   container, and `.vt-section` is the only thing that declares this one.
   ------------------------------------------------------------ */
@container vt-section (max-width: 860px) {
  .vt-section .vt-mosaic {
    --vt-mosaic-row: 180px;
    grid-template-columns: repeat(2, minmax(0, 1fr));
    /* a declared row count is a four-column composition; at the folds the
       grid goes back to growing with its content */
    grid-template-rows: none;
  }
  /* The fold discards PLACEMENT entirely — an explicit slot is meaningless at
     two columns — and re-flows the tiles in DOM order, which the editor keeps
     equal to reading order (row-major; see index.js). Spans are then re-stated
     from the mirrored data-vt-cols, clamped to two: the mockup's own call (the
     big tile keeps reading as the big one), and nothing may be two ROWS tall
     any more or the band simply doubles in height. (0,2,0)+ so core's emitted
     placement — (0,1,0) — always loses, whatever the sheet order. */
  .vt-section .vt-mosaic > .vt-mosaic__tile {
    grid-column: auto;
    grid-row: auto;
  }
  .vt-section .vt-mosaic > .vt-mosaic__tile[data-vt-cols="2"],
  .vt-section .vt-mosaic > .vt-mosaic__tile[data-vt-cols="3"],
  .vt-section .vt-mosaic > .vt-mosaic__tile[data-vt-cols="4"],
  .vt-section .vt-mosaic > .vt-mosaic__tile[data-vt-cols="5"],
  .vt-section .vt-mosaic > .vt-mosaic__tile[data-vt-cols="6"] {
    grid-column: span 2;
  }
  .vt-section .vt-mosaic > .vt-mosaic__tile[data-vt-rows="2"] .vt-mosaic__value,
  .vt-section .vt-mosaic > .vt-mosaic__tile[data-vt-rows="3"] .vt-mosaic__value {
    font-size: 20px;
  }
}

@container vt-section (max-width: 600px) {
  .vt-section .vt-mosaic { grid-template-columns: minmax(0, 1fr); }
  /* One column: every tile is one cell, whatever it was asked to span. A tile
     told to cover two of one column overflows the band. The [data-vt-cols]
     variant is not decoration: the 860 fold's span clamp is (0,3,0), so this
     block needs the same weight to take the span back — measured as a `span 2`
     leaking through and forcing a phantom 0px second column on a phone. */
  .vt-section .vt-mosaic > .vt-mosaic__tile,
  .vt-section .vt-mosaic > .vt-mosaic__tile[data-vt-cols] {
    grid-column: auto;
    grid-row: auto;
  }
}